Onboarding software engineers
I’m currently reading Will Larson’s An Elegant Puzzle which is by far the best book on systems of engineering management I’ve ever read (hopefully I’ll be able to write and share a book review). In the section related to hypergrowth, the author makes a very good point about the impact of training new engineers to the overall productivity of a tech team:
Imagine a scenario in which training a single new engineer takes about 10 hours per week from each trained engineer, and in which untrained engineers are one-third as productive as trained engineers. The result is [...] a ratio of two-untrained-to-one-trained. Worse, for those three people you’re only getting the productivity of 1.16 trained engineers (2 x .33 for the untrained engineers plus .5 x 1 for the trainer)
While this scenario is admittedly extreme, the insight is in stark contrast to what I’ve been observing at many high growth companies that have little to no onboarding process for new engineers, but still count on the fact that they will be productive the first month. But having said that, what can be done to onboard software engineers on top of pairing them with trained engineers and giving them a cool welcome package?
The impact of onboarding
Onboarding is a relatively new term and has been defined as the process of helping new hires adjust to social and performance aspects of their new jobs. Although little research has been conducted on onboarding specifically as it is called now, research has examined aspects of onboarding and its positive relationship to employee orientation and socialization in the workplace. While the numbers vary from study to study, all of them concur on the fact that a strong onboarding process drastically improves productivity and employee retention. Great. So, what does a strong onboarding process look like for software teams?
In The Unicorn Project, a fictionalized story about a DevOps transformation taking place at a large corporation, the lead character gets assigned to a new project and finds herself going through weeks of hassle and bureaucracy, just to be able to get the developer build environment up and running on her laptop. While this nightmare doesn’t happen in most companies, it is common for new engineers to wait several days before starting to write and deploy code.
One of the main reasons is that new hires have to go through HR and finance processes, not counting the fact that all hardware and software requests are usually made on the first day. Instead, I would really recommend starting the onboarding process before the new hire comes in. All HR and finance processes can be done online (using solutions like Payfit and Alan), the hardware can be ordered beforehand and all software accesses can also be done before the first day. Ideally new engineers should be able to deploy on their first day, which forces getting all of their accounts set up, their development environment ready, showing them where source control is, how code review works and so on.
Onboarding as a product
At game company Valve Corporation, new employees’ first day is designed like, well, a game. You’re given the employee handbook and you have to figure out by yourself what to do and even on which project you should work. It’s even designed to not be “about fringe benefits or how to set up your workstation or where to find source code”.
But not all companies are as adventurous as Valve. Every new engineer that joins Facebook, whether a recent college grad or a new director, goes through an intensive six week program called Bootcamp, designed to immerse them into the code base, give greater flexibility in choosing a project, and promote the Facebook habits and culture.
While very different, both onboarding programs have a common point: they’ve been designed with a certain culture and output in mind. Like any product. So when designing your onboarding process, you should actually use product design techniques focusing on user experience. More precisely, the experience you should be measuring is the perceived value:
- For new employees, it shows if they felt truly onboarded in the company and have the tools and information they need to get started
- For their managers, it shows if the onboarding’s output (the “trained” engineer) is up to their standard in terms of productivity and timing (ideally productivity should be 100% and timing should be the lowest possible)
- For the organisation, it shows if the new employees really fit in terms of culture, behaviours and social interactions
Document, document, document
An engineering leader I’m currently coaching recently brought up the onboarding topics. He was welcoming a new member in his team and was concerned about how to onboard her remotely. He was saying that usually he was giving new employees a tour of the open space, introducing people as he saw them, and didn’t know how to do that remotely. It was actually a great opportunity to start designing an onboarding process that will be offered to all new employees from now on, remote or not. So he wrote down what this new person should know, who she should meet, then he started sending information and making introductions. But instead of writing everything down, I advised him to delegate the task of writing down the onboarding process document to the new employee.
When writing down something, one owns its content much more. Moreover, having newcomers write/update documents is a great way of having a fresh look on perhaps outdated information, or worst, unspoken rules. The other advantage is to start writing and maintaining up-to-date documentation that will be available for both current and future employees, a common denominator for companies with great onboarding.
You can even gamify it a little. Most engineers love learning new stuff by going through the documentation first. So you can make it part of the onboarding to find out what to do and who to meet going through the onboarding document, while asking them to update it in the process.
In summary
- A great onboarding process can have a significant impact on your company’s scaling pace, as well as on new employees’ productivity and retention
- Onboarding should be designed like products with a focus on user experience but also on the measurable output
- Great onboarding have great documentation, so make it part of your process to have new employees update the document while they’re being onboarded
Additional resources
If you’re interested to get more content about onboarding, I recommend the following resources:
📖 The First 90 Days, Updated and Expanded: Proven Strategies for Getting Up to Speed Faster and Smarter | Michael Watkins
💻 A curated list of awesome onboarding for new developers | Yassine Azzout