Remote engineer onboarding is a vital step in empowering your new hires to become productive members of your team. Smart, functional onboarding cuts the average time-to-productivity by 70 percent and can reduce churn in engineering departments. In this guide, we will cover the challenges facing dev team managers who are tackling remote engineer onboarding, the best practices for planning a functional onboarding program, and solutions that you can put in place today.
As an engineering leader, you have high expectations for your team that reflect the deliverables you are responsible for. You need to ramp up new hires quickly and empower them to become a productive member of the team as soon as possible. That means you need consistency.
When growing your team, you should think about more than just the needs of the new hire. Your team dynamic and workflows are unique. What impact will the new hire have on the rest of the team? We have found that the velocity of the entire team dips when a new hire comes on. For multiple new hires, the impact is cumulative.
emote developer onboarding has special challenges. Communications need to be more deliberate and better planned, since you can’t rely on serendipitous hallway check-ins or the face of your new hire to judge their comfort level. The tech considerations of remote work are not simple for any worker (just think of all the provisioning and access issues!) and for engineers the complexity can compound to make onboarding a huge challenge.
While the COVID-19 pandemic sped the growth of remote uptake for software companies across the world, it’s clear that many companies are committed to a hybrid or completely remote workforce into the future. If you can get remote engineer onboarding programs in place now, you and your company will be at a competitive advantage now and into an increasingly distributed future.
The problem with traditional onboarding
Onboarding has a reputation for being something HR does. We imagine getting a keypass and a folder with our benefits information. That's corporate onboarding, and as important as it is, it doesn't go far enough.
So in most dev teams, the engineering manager supplements that with their own onboarding program. Perhaps you have a checklist of links to documentation and tools. Maybe you have even articulated some important notes for your new hire and have made time to share them one on one. That's great, but you can only do so much - things are changing all the time and it’s hard to keep things up-to-date. Manager-driven onboarding programs have a flat, context-poor information delivery and you're not always going to be available. What happens when you have more than one new hire? What happens when you have more than 10?
A common result is that a new hire fires questions (often into the ether of Slack) at the people who seem to know the answers - and they are often your senior engineers. They want to be supportive, so they tear themselves away from their high-value work to help your new hire track down answers. So the new hire is nowhere near ready to do their job, and they're also distracting your senior team members from doing theirs! When you try to onboard new engineers during a critical development cycle (and let's be honest, which of them aren't critical these days?) your whole operation grinds to a halt.
You have high expectations for your team, and you should. But software engineer turnover is the highest of any industry and the seeds of that churn are planted in the first thirty days. The confusion and disengagement a new hire feels in their opening weeks will stay with them and may contribute to their early departure. That means you are back at square one: New hire, new developer onboarding checklist, and another endless march toward making them productive, only to have them leave.
For example, let's imagine two new hires starting with a similar experience level on the same day. One is in a traditional two-week corporate-heavy onboarding program, the other is engaged in functional onboarding with a supportive framework like Edify. Before the one-week mark, the Edify engineer has completed their first commit, is getting more productive every day, and has already built relationships with the right subject matter experts for their questions.
By contrast, the engineer who had a more traditional onboarding is having lots of ups and downs as they guess what to do with missing documentation and “sit tight” in their home office, waiting for their manager to get back to them on important workflow advice. They are not productive for months, a disempowering and disappointing result for everyone - which can often lead to churn.
As onboarding specialists, we obsess over the metric time-to-productivity. But what is it and what does it mean for you and your team?
It is generally understood that there will come a time when your new hire is actively contributing to your organization. It's a tricky measure but it usually means that they're contributing more than you're putting into training and supporting them - their net value is in the positive.
These are the questions we ask when judging whether the new hire is becoming a productive member of the team:
- How well is the new hire understanding the process and professional expectations of their team?
- How well are they adjusting to the culture and the norms of the company?
- How well has all of this information been communicated to them? Has the onboarding process delivered the crucial information so the new hire can learn and grow?
- Has the new hire contributed good, novel work that did not break flows or processes?
If you can answer positively to all of these questions, your new hire is likely “productive”! However, most engineering teams don’t have a clear system for assessing time-to-productivity and therefore aren’t sure how long it takes for the new hire’s training wheels to come off.
Edmond Lau, former engineering lead at Quora, says the complexity of an engineer's work grows as the company does. He said that engineers who had mentors or starter projects that helped them grasp fundamental tools and abstractions did better than others months later because they knew what resources were available. "A key part of a good onboarding program is ensuring that everyone starts off on a consistent and solid foundation with respect to those fundamentals, so that there’s less variance in terms of who learned what based on initial project or mentoring assignments," he wrote.
Your deliverables don't go away just because you have a new team member to orient. That means you need ambitious goals for your new hire, too! The key to building 30, 60, and 90-day goals is to identify the key competencies and tasks your new hire needs to command and tie them to a reasonable timeframe. If you're not sure what seems reasonable, bring in your most recent new hire for a critical look at the onboarding process.
In our work, we've found that most engineering managers say new hires are not up to speed until seven to nine months into the job! That's a lot of lost productivity while you wait for them to get acclimated. That's why we built a software solution that ramps up a new engineer in just 30 days - whether they are remote-first or co-located with their team.
Anatomy of a successful remote engineer onboarding program
Your engineering team is unique, which means the way you work is also special. What you need most is consistency and flexibility in your onboarding program. They are your repos and your workflows. No out-of-the-box solution built for HR is going to work for your remote engineers. There is too much technical information and too many distinct workflows to ever make sense in an onboarding program built for other information workers. What you need is a program that puts the needs of engineers first.
Smart onboarding unfolds at a pace that is empowering for the new hire. With Edify’s developer onboarding, for example, there are prompts to complete sequential tasks every day, which gives the new hire confidence that they're working at the right speed for their new environment. They can speed up when they have extra time and delay tasks if they have a lot on their plate. Unlike other programs, where information is either delivered in a big dump in long lists or at meetings, our unique developer onboarding method is always-on but paced based on what we know about adult learning and engineer knowledge retention.
The big problem with documentation lists is that the information in them is flat and devoid of context, not to mention they tend to be impossible to maintain. You know your new hire needs access to Github so you set up a login and send them a link. Now they know two pieces of information: Where you write code, and how to log in.
By contrast, functional onboarding delivers this information as part of a section about how and why you use the tools you do. It is context-rich and framed in a way that helps the new engineer focus on what's important. As well as learning which tool to log in to, they are figuring out how to navigate your team's unique workflows and can start to immediately apply the knowledge they already have about Github.
It's also really important that the documentation is updated. When systems change, there's usually a reason for it, and by recycling old documentation you're also recycling old ideas and ways of working that no longer reflect your engineering team. The Edify platform daylights documentation that needs updating and provides an easy path to get it fixed.
For example, let's say two developers start on the same day at the same company. Yang is given standard documentation lists - a Word document with a bunch of links and brief descriptions from their manager. Tomas has dynamic documentation by Edify.
On day one, their experience is about the same. However, by day three, Yang is worried they're not working fast enough. There are 43 links in the document. Should they have investigated all of them already? They're starting to get frazzled. They opened some of the tools but they don't know enough about the product yet to figure out what's important and what's not.
Meanwhile, Edify is leading Tomas through his onboarding, giving him new tasks every day and checking in to fix roadblocks. Tomas knows exactly what he is supposed to be doing every day and he is given the context he needs to figure out what to focus on. Links to tools and documentation are correct because, with Edify's help, Tomas' manager checked them a week before he started work.
The way to enrich that experience and make the learnings stick is to offer a well-planned and supported onboarding buddy program. It takes more than inviting the new hire out for coffee on their first day!
To truly build a supportive human connection, the buddy needs to know what the new hire will likely need from them and how they can be a consistent, knowledgeable, and enthusiastic guide. They don't need to know everything but they should have been around for long enough to know the engineering team's tools, workflows, and cultural environment. It helps if they feel positively about being a buddy - their enthusiasm is contagious!
Knowledge pillars are the foundation for successful remote dev onboarding
Since HR-driven corporate onboarding has consistently failed engineering teams, managers have had to build their own programs. That means they can vary enormously between companies and even within them! We have found that focusing on four key areas - what we call the four pillars of knowledge - is the best way to onboard remote engineers.
Tech and tooling
Technology covers the what and the how. You probably have a lot of this in your remote engineer onboarding plan already but experience has taught us a list of links to different platforms don't go far enough. You need to surface practical, specific tools that will help new hires succeed. Often, this goes beyond what is in the SoPs and onboarding docs. If you're not sure where to start, ask your most experienced engineers what questions they get.
Many engineering leaders assume it goes without saying that they want their new hires to have a certain level of professionalism and to communicate in a particular way. Let me tell you: It does not go without saying. Engineers come from a vast array of backgrounds and other team experiences. Don't assume your remote engineers know they don't have to wear a suit and tie, and don't assume they will ping you on Slack when your pre-engagement communication has all been via email. More than that: Think about how messages and requests are handled, what standards you have, and what workflows are normal in your team. If you don't articulate them to the new hire and explain why, their wrong guesses can derail your whole operation.
The best way to do this is to think about the things that matter most to your team. What are the main goals and workflows of the team? How is communication handled between team members, and with other teams at the company? Is there a preferred method of documentation for specific messages or requests? All of this information needs to be recorded, saved, and shared with new hires - with guidance on why it matters.
Remote team members can often feel like they're in the dark about how their new company gets work done, and that can put them at a disadvantage from their first week! To devise what your team workflows and processes are, focus on the tasks, situations, and troubleshooting that happens every day. Are they just institutional knowledge or can you articulate them?
This is the biggest "why" new remote engineers have but it's frequently overlooked. Your new hire needs to know how to log in and who to ask for help, sure, but they also need to understand how their work contributes to the success of their team and your company.
Forwarding them the latest PDF of your product roadmap is not what I'm suggesting. Instead, focus on the simple things: What does your product do? What problem does it solve? And how does the new hire contribute to the whole?
It’s time for smarter developer onboarding
Our experience onboarding engineers taught us that the way engineering managers were running onboarding was failing all parties - new hires, engineering managers, and other team members alike. That’s why we built an interactive bot that guides the new engineer through a 30-day onboarding program.
It works by pairing the new hire with the bot eddy, who has gleaned all the necessary information and documentation links from a team member and delivers it to the new hire in a logical sequence, paced to reflect what a new engineer can focus on at one time. eddy also connects them with internal resources including a buddy and other subject-matter experts, using the communication tools most engineering teams are already using.
The Edify onboarding program is centered on the needs of managers, who can get real-time updates on their new hire’s progress. The program is designed for speed and consistency, which means similar results whether you’re hiring one new person or 20. And most importantly, eddy is your new hire’s constant companion, which takes the heat off you to answer all questions, explain all workflows, and track down all missing documentation.
Partners from technology companies including ActivTrak and OpsLevel helped Edify design the platform so it is deeply technical and relevant to the needs of engineering teams with ambitious dev roadmaps. We are invested in the success of new remote engineers and we have found a way to speed their time to productivity.
There are many challenges of running a distributed development team. With a flexible, functional remote engineer onboarding program, you can make sure a bad start is not one of them.