Good news - you've completed your extensive hiring process! The result? A newly minted member of the development team. As a team lead, while it's nice to exhale once the signed employment contract is in hand, the real work has just begun.
Bringing someone new into the fold isn't just a matter of hiring and then setting them loose on the codebase. You could do this, of course. But if you do, the ramp from zero to fully productive becomes exponentially longer.
This means your organization doesn’t build a return on investment (ROI) in that developer until much later. Onboarding has a cost, just like hiring.
Good onboarding creates a high ROI for your team, the company, and the new developer.
Effectively orienting developers to their projects encompasses documentation and context (what we call vision transfer), team philosophy and communication, and preventing a toxic team dynamic.
Doing these things well during onboarding helps build developer ROI starting from day one.
Documentation and Business Context
Of primary importance is introducing the new developer to the code they'll be interacting with regularly. Developers with a high understanding of the code they’ll be working on feel 42% more productive than developers with little or no understanding.
Start setting up the signposts for where they can expect to find the answers when they have questions about the codebase. If the code is well-constructed, those signposts aren't other developers on the team (although they can certainly be helpful).
Instead, they need to know things like where the data-related code is, where the presentation code is, and where the migrations are.
Essentially, you are walking your team member through the architecture. If your team works with several codebases (or more), having consistent architecture across the board can help a lot.
If the architecture is similar, we don't have to do a basic review on each project and thus rehash the same pieces in different places. Instead, each project’s onboarding can be more about project-specific business problems and algorithms and contribute to vision transfer.
Team Philosophy and Communication
Your team’s collective philosophy should be to bring new members up to speed as soon as possible. That's not all on the team lead, but you are instrumental in establishing that tone and culture.
If that culture doesn’t yet exist on your team, you'll fight some inertia to get the existing developers "re-onboarded.”
Ideally, your team will already be able to communicate the important areas of the code.
Instead of introducing the code yourself, you can tag-team it with team members who have previously spent time in different areas of the code.
An added benefit is the face time between team members that contributes to organic team-building on a personal level.
Preventing Toxic Ownership
One thing to look out for in the team dynamic is "pet" bits of the code. Team members will inevitably feel a sense of code ownership, especially when a developer has been in the code for a long time.
We want our developers to take pride in their work and the problems they've solved, especially if it is well-constructed. But as team leads, we need to watch out for and work to separate a toxic code-ownership stance from healthy pride and satisfaction.
Hopefully you covered this in the hiring process - you want to have efficient, competent, humble contributors to the code.
If your team already operates like this, your veterans can set an example and show humility when a newcomer is about to modify their code.
In doing so, the veterans won't show the code in a manner to scare the newbie off because "here be monsters." Instead, with a nod to how well the code has worked thus far, they can welcome future contributions.
Onboarding as Investment
Successful onboarding is about setting developers up for success on their projects. Onboarding well reinforces a collaborative development environment for new hires and veterans alike.
Providing clear signposts and context, fostering a culture of communication, and eliminating toxic ownership are effective ways to introduce new developers to codebases and projects.
When introducing code is done right, your team gains an engaged, knowledgeable contributor who can deliver value sooner–a win for everyone.