Some Thoughts on Improving Tech On-boarding

New year, new you, new job?

As this is on-boarding season, I thought it would be interesting to go over some personal thoughts on how to improve the tech on-boarding process. As usual, a small disclaimer that this is my personal perspective on the matter through the lenses of software engineering, and as such will not apply in most other contexts. Yet, I hope some of the thoughts shared hereafter prove useful and do inspire you to build a better process.

Instead of focusing on common advice around on-boarding best practices, I'll go over a few more specific ideas that I believe will help improve your existing process.

Treat your code as if it were open source

There are some benefits in treating your code base as if it were open source, and one of them is better on-boarding. Some traits of open source software that you can borrow are documentation, open culture, and shared code ownership.

At the root of any open source project, you usually find a README.md file that provides an overview of the project, how to run it, and how to contribute. While your product and code base might be slightly more complex than the average open source project, having clear documentation facilitates on-boarding. Be careful though, outdated documentation is worst than no documentation. At a minimum, you should have clear guidelines as to how the code is structured, how to set up and run a local environment, and how the team collaborates and works together. Ideally the code itself is also documented with high-quality comments explaining the why instead of the what or the how.

Having an open culture, where all decisions are made in public and clearly documented, can also prove useful when on-boarding a new colleague. Not only will that provide some context around the product and the code, but it will also show how decisions are made and what are the team dynamics. It will also provide a template and invite new colleagues to share their ideas.

As much as possible, create an environment of shared code ownership. Instilling code reviews and standards across teams is an easy way to achieve that. The goal should be that every engineer has enough knowledge on all parts of the code that they can work on them. This also facilitates on-boarding, as such a set up would help new colleagues grasp the intricacies of the code base.

Treating code as open source becomes even more paramount in a remote setup!

Pairing is your super-power

Assigning a buddy to new joiners is a staple in most on-boarding processes, but it is even more important for software engineers, as usually there is a lot of context around the product and the code base that isn't captured in documentation.

As much as possible, encourage buddies to pair program with the new joiners in the first few weeks. Make buddying an explicit part of their occupation in those weeks so that they can provide the best support to new joiners. Organize regular check-ins where you can get continuous feedback on the on-boarding process. Keep track of areas where there seems to be more of a struggle. Getting all that data is eased with a buddy system as the feedback loop is almost instantaneous.

Finally, create spaces beyond your buddy system to help your new colleagues socialize. Make it part of the on-boarding process that they meet people from other teams and other functions in the company. That will break silos early on and create a stronger sense of belonging.

As with the previous point, pairing becomes even more primordial in a remote setup!

Find an adequate first task

The last point I wanted to touch upon is finding an adequate first task, as this can help set a positive trajectory for your new colleagues if done well. The first task should have low coupling, be non-trivial, and generate high impact.

Ideally, the first task should not need deep knowledge of the code base or the product. Your new colleague won't be equipped yet to fully grasp the nuances, and they might get discouraged by the time it might take them to wrap their head around all the edge cases. It also shouldn't be on the critical path of the product, nor should it be an urgent feature. The last thing you want is for their first task to end up breaking some critical part of your product, or missing a deadline. A good first task could be additive rather than an incremental improvement of an existing feature. It should have low coupling with the existing code base if possible. That way, you reduce the risk of the task breaking or having to be rushed.

This will depend on the level of seniority of your new colleague, but try to make the first task a non-trivial one and set the level of complexity so that it is still an interesting challenge. Writing tests or fixing bugs are, in my opinion, terrible first tasks. Instead, make the first task pure product work. Paired with a buddy system, working on a slightly challenging task will naturally provide opportunities to pair and exchange ideas. It also signals to the new colleague that they are valued and trusted to work on complex topics. Quick wins are fine, but creating space for new joiners to fully experience the life cycle of building a non-trivial feature will help down the line. Allow them to showcase what they can do from the get-go! Careful though on not making the first task too challenging as that might backfire and lead to a loss of motivation and self-esteem.

Finally, pick a first task with high impact, either for the business or for the company. Not only will that improve their self-esteem as their work will immediately create value, but it might already create synergies with existing team members.

Of course, as with most professional endeavors, it helps to also set clear expectation and entertain an open feedback culture.

Ultimately, everyone is different, and the best on-boarding process is the one that can adapt to the uniqueness of every new colleague while equipping them with the right environment for them to succeed.

Happy on-boarding!