There will be no edition next week, for Canada Day-related reasons.
Today’s edition is brought to you by the Moderna mRNA vaccine, and how gloriously it has kicked my butt today. I couldn’t be happier about being fully vaccinated, but I could be slightly incoherent as a result this week.
Bear with me.
I have gathered my best thoughts on effective strategies for onboarding developers, and I’m excited to share ways to improve how we think about bringing new people onto our team.
Onboarding is one of your highest leverage activities as a leader, so take the time. Across all industries, 88% of organizations “don’t onboard well” and a “great onboarding” can increase retention by 82%. This is a high-leverage activity that is often an afterthought.
It’s About Behaviours and Habits
Having the proper mindset allows us to set proper expectations around what an onboarding process looks like.
Adopt a patient mindset. There’s a reason why my favourite general-purpose book on onboarding specifically for leaders is The First 90 Days. The processes in this book allow the proper time for habits to grow.
From the point of view of the new developer, there are three primary goals:
- Learning about the system in your company
- Adapting behaviours and habits to align with the norms in your company
- Reaching full productivity with patience.
Make it Real
As a leader, it is your job to ensure that new hires come up to speed in a repeatable way.
This does not mean “sandboxing” new developers in courseware or non-production work for weeks. This also does not mean throwing folks into the deep end, bragging about your “ambiguous startup environment” and your performance culture and putting all the work on them.
The rule - real work in the first week. Involve them in decision-making and ceremonies, bring them into the flow of real work that’s happening all around them.
Your Builds Have to Work
If the new hire needs to find three other people to solve mysteries about your coding, build, or development process, this is broken. Having to search for this information is a strong indicator that there is other fragilities in your engineering systems.
Onboarding is a product, and your documentation is part of this.
The First Relationships are Everything
One of the best tactics that I’ve adopted over the years is the buddy system. Give the first relationship a great start by connecting the new hire with a more experienced and willing member of the team.
This works best if your systems actually work, and folks can concentrate on building meaningful relationships and not fielding 68 questions a day about build errors.
Script it Out
Even if you’re onboarding remotely, have a checklist.
Related to treating Onboarding as a product, script out the interactions, particularly if you’re remote.
Metrics can help provide a view on how folks are doing. This is not necessarily a judgement on them, it’s information on how your onboarding system is doing.
The usual caveats apply around focusing on these metrics at all costs. Do not get myopically buried in these, or start comparing all of your new hires to each other.
Helpful metrics include:
- Time to first deploy
- Time to first PR review
- Time to Nth PR - not just the first one, but time to the 6th or 10th.
- Time to start commenting on other folks’ PRs
Qualitative measures help as well. Related to the answers you get when you Script it Out, check in on their experience and track how you’re doing - just like you would with any other product.
This is a live system. Success not only depends on the time and seriousness you take for this process, but in how you improve over time.
If you have hiring plans this year, take a look at how you’re doing it. How successful (even anecdotally) were the folks that came into your organization recently?
It’s important that we give this critical system the priority it needs - so start digging in.