One of the things that surprised me the most when I started managing teams was how some people would just up and quit in their first days if they felt too much friction.
Looking into it, I’ve discovered as many as 10% of new developers quit before their third month, mainly because they don’t feel like they’ve been given the proper guidance and feel uncomfortable in their new position. With companies cutting costs in HR, the processes also become increasingly automated, making the new employee feel like a cog in the machine.
Some friction is good—you don’t want to have someone around who needs too much handholding—but given the effort and resources to find and hire software developers, I made it my job to reduce that % in my marketing team.
The results were pretty good: 0% three-month turnaround and one guy even offered to stick around and work for free when we hit a rough spot and needed to tighten our belts.
In this article, I’ll provide a checklist of tasks for onboarding developers and briefly explain each point. I will not explain basic concepts like “What is onboarding?” This is an advanced article. If any of the terms are unfamiliar, I hear Google still works!
Pre-Onboarding Aspects to Keep In Mind
1. Create a master onboarding list
Create a shared list of tasks for the new employee and everyone involved with their onboarding in your project management system.
If you don’t use a project management system, create a checklist in Google Docs or Word and share it. That list should include all the items discussed below.
2. Email and accounts
Set up the new employee’s company email at least 48 hours before.
Depending on your processes, they will either have to create their accounts on all the apps your team uses on day one or — preferably, if possible — someone in your team should do it for them before they start.
If the former, then it’s reasonable to assume that it will take the better part of their first day. Plan accordingly, and make one item per app on the checklist.
Whatever course you take, ensure the new team member has a document with a list of all the team’s tools and links to access them.
3. Share Relevant Resources
Share resources like:
- A digital employee handbook
- Presentations on company values and mission
- Videos from all-hands meetings
- Resources like an up-to-date internal wiki explaining tools and processes
- A recommended reading list of influential books
- Blog posts by company founders that share the company’s philosophy and values.
Stress that they aren’t supposed to go over it all before they officially start; you are only sending it so they can hit the ground running on the first week.
Day 1 of Onboarding A Remote Developer
Apart from the account creation outlined above, your new remote developer should accomplish a couple of extra tasks in the first day or two of arriving at work.
1. Critical Introductions
Who’s on the team? You don’t want to overwhelm your remote developer with calls on the first day, but they should at the very least meet with:
- Their direct manager
- Their mentor/code buddy (could be two different people, too)
- Their direct reports, if any
These main introductions are best handled with video; a good-quality webcam and mic should be mandatory. First impressions matter, and no matter how much your remote strategy revolves around asynchronous communication, you do want the first day to have a slightly more “on-site” feeling.
A general introduction to the main team channel is also in order. In a small company, this might even be in the general channel. However, in a larger business, consider keeping day-one interaction limited to the team the remote developer will be working with daily; they can meet the rest of the company at a slower pace.
The main goal of these introductions is that the new team member knows who to go to with any questions and who to report their work and task progress to.
2. Documentation
The most underrated and overlooked part of the onboarding process is providing a list of critical documentation for the new team member to review.
As a company grows, it becomes difficult—even impossible—to go through all of it on day one, so it’s the team manager’s responsibility to maintain a critical segment that provides the basis relevant only to his team.
In my case, the DistantJob Marketing Team’s “How We Work” document is less than ten pages long and includes everything from expected communication and reporting to links to the general assets and company style sheets. Anyone can go through it in 45 minutes.
Reading critical team docs should be a Day One activity. If it’s not accomplishable, your critical docs are too long and bloated.
2A. Introducing Key Software and Tools
Technically, this should be part of the documentation, but there are a couple of cases where you want to take a more hands-on approach. For instance:
- When onboarding a junior developer who might not be familiar with more common tools of the trade
- When their day-to-day workflow will rely on a piece of in-house or lesser-known software.
It’s worth carving out a piece of the direct manager, or mentor calls to deal specifically with this.
3. First Project, Goals, and Deadlines
This can happen on a call or the onboarding checklist. It’s better if it’s a combination of both.
Essentially, the employee should learn on day one what their first project will be and the expected time frame for accomplishing it. Adding milestones is also helpful, especially if the project is complex and lasts several weeks or sprints.
Your goal is that, at the end of the day, your new remote developer should know where their priorities lie and can begin to plan how to tackle their workload best.
4. Check in with your new remote developer
Your new remote developer’s day one of onboarding should end with a call between you and them. Get their feedback about all the previous points:
- Do they know who to go to with any questions?
- Do they have access to all the tools the team uses?
- Do they know what their responsibilities, goals, and first project are?
- Do they know when and how to communicate with the team, how to submit work, and how to report work done?
Issues that arise here should be troubleshooted on Day 2.
Week 1 of Onboarding A Remote Developer
A lot of what happens in Week one is basically an expansion of day one. The point is to go a bit deeper into all the critical elements introduced in the first day, making the developer feel guided and not overwhelmed. The focus should always be on creating an onboarding experience that does not take the onus off the actual development work which they hopefully love and feel at ease with.
1. Documentation, part 2
This is mostly a concern for bigger teams and companies where there’s a lot of documentation, wikis, etc., that are helpful but not critical for a new team member. These should be listed as granularly as possible for the new developer to read at their own pace over the first week.
If you haven’t yet crafted these documents and guides, you should. They will save you hundreds of hours in calls and from answering repetitive questions. When writing them, a good start is to think about things like:
- What hours is a developer expected to keep?
- Can they work flexibly, or are they expected to be online for core hours?
- How will performance be measured?
- What sort of jargon does your company use?
- What is the correct way to submit, complete, and juggle tasks in your project management system?
Have all of these documented so new developers can peruse the instructions over the first week. Their mentor can fill any gaps.
2. Get Them Started With The First Project
There’s nothing worse for someone who enjoys their job than spending time in adminland—reporting, talking about work, etc. — but not getting any actual work done.
The point of all the items above is to ensure the admin stuff gets out of the way as quickly as possible so the developer can hit the ground running and begin doing developer work as soon as their second day.
If they reach the end of week one and have spent more than 40% of their time onboarding tasks and less than 60% doing the actual job they were hired to do, you’ve failed.
And they will probably start not enjoying their job already.
3. Daily Check-ins
A daily poke should be part of every new hire onboarding roadmap.
Let them know it’s coming so they don’t feel like they are in trouble or stressed out, but do tap on their shoulder (in Slack) every day and ask how it’s going.
Ask them how they are enjoying the team and company if they have everything they need to do their job, and if they have any questions.
Overcommunicating is a valuable and important part of developer onboarding best practices when dealing with remote developers.
4. End The Week With 2-Way Feedback
This builds on the previous point. The questions you’ll want to ask are essentially the same, but this time, you want to block 30 to 45 minutes at the end of the week for a call.
This one is as much for you as for the developer you are onboarding, as you want to ask them about their first week’s experience.
Ask what they liked and disliked, what made sense to them and what confused them, etc.
This is how you improve your onboarding: by interviewing your new employees and relentlessly polishing the process.
The Biggest Secret There Is
The secret to flawless developer onboarding happens before the first day: hiring the right person.
That’s the secret.
Remote working is great, but even though 90% of modern developers want to work from home, only some are cut out for it.
When hiring for a remote-first environment, you want to be sure the remote programmer you’re interviewing is truly remote-ready.
So, ask questions to help you understand how much the candidate is used to remote communication and distributed teams.
Pay especially attention to the quality and clarity of their writing, as this is how they will be spending most of their time with you.
If your new developer is new to remote work, you want to spend more time showing around tools, daily reports, and internal communication strategies.
If they are old remote souls, you can put more effort into socializing, virtual water coolers, and team introductions. Or, better yet, leave them to work on their project—that’s what you hired them to do!
By now, you might be wondering how to hire the perfect remote developer among 7 billion people.
Guess what? You don’t need to go far to find someone who can give you a good answer. That’s because we at DistantJob are specialists in ensuring that the developers you hire are set up at your business.
We prescreen all applicants for technical skills, proven ability to work remotely, and cultural fit for your business. That’s why we are much faster than other recruitment options; our shortlist is all ideal candidates.
Need that awesome employee? Get in touch!
