How to Fast-Track Onboarding for Software Developers
By: Andrei Gridnev
Tags: Work, Careers, Programming, Leadership, Hiring

People Management

How to Fast-Track Onboarding for Software Developers

Setting up new hires for success by accelerating learning, encouraging collaboration, providing and soliciting feedback

Photo by Kelly Sikkema on Unsplash

To get fully productive at a new job, a software developer needs to:

understand how their new team works,

get familiar with the product source code and architecture,

get familiar with the product business domain.

In our team we started to help our new hires to get up to speed sooner with a personalised onboarding process. It has been working well for us: our new colleagues have been learning quickly, contributing efficiently, and integrating into the team well.

In this article I’d like to share the details of our approach. Its key parts are:

Appointing an on-boarding buddy Preparing an individual task list Starting to contribute on the first day Encouraging collaboration Providing and soliciting feedback frequently

Let’s now look into each part.

1. Appointing an Onboarding Buddy

The role of the onboarding buddy in our team is to help the new starter to set up the development environment, explain how the team works in terms of writing and reviewing code, answer technical questions, and guide the new starter when necessary during the first weeks. This is not unique, many organisations do something similar.

The onboarding buddy in our team is an experienced developer, who is familiar with the part of the codebase that the new hire is going to work on at the start.

The buddy must be genuinely interested in supporting the new developer during the first month or so. Appointing someone who doesn’t want to perform that role is counterproductive.

Our onboarding buddies are helping with mainly technical aspects: writing and reviewing code and learning the product domain. Everything else is on the new hire’s manager.

To make sure the new starter fully uses their buddy’s help, we set the expectations for the developer and the buddy on when to ask for help, what type of questions to ask, etc.

For example, we recommend a new starter, before asking a code-related question, to spend 15–20 minutes (but not more than that) on searching for the answer on their own and ask their buddy or the team for help after that. That encourages the new developer to explore the codebase but ensures that they won’t sink too much time into that when their colleague can unblock them immediately.

2. Preparing the Task List

A new starter at our team gets an individual list of tasks to complete during the first 3–4 weeks. The purpose of that list is to set up a journey through the codebase to familiarise the new developer with the parts that are most relevant to their role as well as the important bits of the product domain.

Contributing code is the fastest way to learn a new codebase. Reading the source code and design documents or listening to the new colleagues explaining how it works without using that information is not particularly helpful. New starters typically want to demonstrate their skills and experience to their new colleagues. Quick wins help them build confidence and we give them plenty of opportunities for that.

In our team, the team lead and buddy prepare the task list together. We take into account the skills of the new starter, the current product priorities, and the buddy’s availability to support the new developer in the first weeks: review code, answer questions, provide feedback, and ensure that the work gets merged and shipped promptly.

These tasks require anywhere from a couple of hours to a day to complete. We expect the new developer to finish at least one task on their first day. The tasks have no dependencies on work that other team members need to complete to avoid blockers. All tasks are non-critical to avoid stress for the new starter and minimise the risk. For example, straightforward refactoring, easy-to-fix bugs, simple technical and product tasks.

The complexity of the tasks on the list goes up to keep challenging the developer and be appropriate for their experience level. Tasks are varied enough to identify gaps in their knowledge and start closing them. That variety also allows the new starter to work with the majority of their new colleagues, not only with their buddy. For example, a new junior with JS, React, and Android experience gets an opportunity to work with all front-end and native developers in our team.

The first tasks on the list require little to no product domain knowledge, so the developer focuses solely on getting familiar with the codebase and the development process in the team.

The last tasks on the list require some domain knowledge. Three-four weeks have been enough for our developers to pick up basic concepts from the business domain. In our case — online and mobile banking. This separation, purely technical tasks first, product tasks later, allows the developer to have one “learning focus” at a time.

In other words, if we get back to the three things that developer needs to get familiar with to get productive in the new team, then the first tasks help the new starter to understand the development process in our team, then they focus on getting familiar with relevant parts of the code base, and then with getting basic domain knowledge.

We prepare a task list to keep the new hire busy for three-four weeks. After that it is clear what tasks should be best for them to continue working on.

3. The First Day

On the first day a new developer in our team is introduced to their onboarding buddy and gets an overview of how the team works and what the first weeks are going to look like to create clarity and set expectations. We also have a brief team handbook to share with the new starter.

After the introduction to the team the new starter sets up their development environment with the help from the buddy. That requires checking out the source code, running a script, and following a short readme.

We are not onboarding a developer every month, so the readme and the script may get outdated. The new team member with the help from other team members is expected to fix errors and omissions in the script and the readme and commit their changes.

We expect the new developer to start working on the task list and complete at least one of them on their first day. We think it is important to give our new colleague a chance to feel successful on their first day by shipping even a few lines of code. New dev team members want to start contributing immediately to build confidence and demonstrate their skills. Their managers only need to support that and point their new hires’ efforts in the right direction.

4. Encouraging Collaboration

The task list for the new starter in our team is organised to encourage collaboration between the new developer and other team members. The new team member has to ask questions to figure out technical details, get feedback on their code and work practices. That’s how they get familiar with other team members as engineers and as human beings.

Some people might not be comfortable with reaching out to their new team members who they have never met before. Nudging developers to collaborate with each other helps them to break the ice and connect. This works in both ways: for the new starter and for other team members. In remote teams this is particularly important.

Collaboration helps a new starter to learn the codebase, get familiar with the product, and adjust to the way the team works sooner. Some knowledge about the product and codebase (tacit knowledge) is never written down and has to be transferred through collaboration between team members.

Finally, as the onboarding buddy may be busy or on leave or unable to help for another reason, every developer in our team is expected to review the new starter’s code, provide feedback, and answer their questions. The more people can support the new team member and get them up to speed — the more beneficial that is for a team.

5. Providing and Soliciting Feedback

In our team I catch up with new starters almost daily during the first couple of weeks. I ask them about their progress and how their buddy or I can help them with any issues that they may experience. In addition, I ask them to share their ideas about how their on-boarding could be easier for them and what they think they need to get up to speed sooner.

Our catch-ups don’t take much time, usually no more than 10 minutes, but they uncover issues during onboarding very quickly. Luckily, in our case those issues have been minor. Here are examples of questions I ask:

Do you get enough help from your buddy? Do you get it soon enough?

Do you get reviews on your PRs soon enough?

Is the feedback that you get clear, actionable, and make sense?

What do you think of your tasks? Are they too hard? Are they too easy?

What would you change in you onboarding?

After the first 1–2 weeks daily catch-ups feel too frequent and I schedule weekly 1–1s with the new developer. In a few months, as the new hire settles in, we change the schedule to fortnightly.

During the first 3–4 weeks I also check what the onboarding buddy and other developers think about our new team member to find out if I need to take any actions or relay some feedback to the person. For example, I may encourage the new starter, when they get stuck, to ask their buddy for help sooner to avoid wasting time.

In addition to that, at the first all-company retro we ask the new starter to give the company some feedback on their first week: what was good, what wasn’t, what they would change.

By the end of the first 3–4 weeks I get a picture of what the new developer strengths are, what they need to learn, and what they want to work on. I use that information to pick the best tasks for the person: to use their strengths, to help them acquire missing skills, and to allow them to work on the most interesting things for them where possible.