This year my team has been improving and structuring our developer onboarding process. The reason for that was that we started hiring developers who are currently at the beginning of their career, don’t have much experience with getting up to speed quickly at a new job, and need guidance along their journey.
We wanted our new colleagues to integrate into the team and get fully productive sooner. Since every developer has unique skills, experience, and work practices, we decided to tailor onboarding process to each new starter: build on their strength, accelerate their learning, and make it easy for them to collaborate with other team members.
The outcome was great. New starters quickly learnt the relevant parts of the codebase and product domain, efficiently contributed to delivery, and rapidly integrated into the team.
This article describes our new personalised developer onboarding process. I have written it to share our experience with engineering managers and senior engineers involved in developer onboarding in their organisations. I hope they will find our practices useful and applicable in their environment.
The key parts of our onboarding process 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 a unique practice, of course. Many organisations have onboarding buddies.
Our onboarding buddies are experienced developers who are 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.
The buddies are helping with mainly technical aspects: writing and reviewing code and exploring 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 in our team gets an individual list of tasks to complete during the first 3–4 weeks. The purpose of the 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 is not helpful without using that information. New starters want to apply their skills and experience and earn trust of their new colleagues. Quick wins help them build confidence, that is why we give them plenty of opportunities for that.
In our team, the team lead and the 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 risk. For example, straightforward refactoring, easy-to-fix bugs, simple technical and product tasks.
The complexity of tasks on the list goes up to keep challenging the developer. Tasks are varied enough to identify gaps in their knowledge and close them during the first months. That variety also forces the new starter to work with the majority of their new colleagues, not only with their buddy. For example, a junior developer with JS, React, and Android experience gets an opportunity to work with all front-end and native developers in our team. A junior full-stack developer – with all front- and back-end developers.
The first tasks from the list don’t require product domain knowledge. Thanks to that, the developer focuses on getting familiar with the codebase and the development process in the team.
To complete the last tasks from the list, the developer would need some domain knowledge. Three-four weeks have been enough for our developers to pick up basic concepts from the business domain. In our case that is online and mobile banking. This separation, purely technical tasks first, product tasks later, allows the developer to have a single “learning focus” at all times, minimises distractions, and helps learn faster.
In other words, the first tasks help the new starter understand the development process in our team, then the developer focuses on getting familiar with relevant parts of the code base, and then with getting basic domain knowledge.
We prepare a long enough list to keep the new hire busy for three or four weeks. We slightly update the list as we go, of course. By the end of onboarding it becomes clear what tasks would be best for the developer to continue working on.
3. The First Day
On the first day the team lead introduces the new starter to their onboarding buddy and gives an overview of how the team works and what the first weeks are going to look like. That brings some clarity and sets expectations for our new team member. 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 their buddy’s help. In our case that requires checking out the source code, running a script, and following a short readme.
We are not onboarding a developer each month, so the readme and the script may get outdated. The new team member with the help from their new colleagues 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
We organise the task list for the new starters in a way that encourages collaboration between them and the other team members. In other teams that bonding may take weeks and even months. We value collaboration and teamwork, so have to accelerate the process.
In our team the new developer has to ask questions to figure out technical details, get feedback on their code and work practices. That’s how they get familiar with their new colleagues as engineers and as human beings. Some people might be uncomfortable 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. The risk for a new starter in a remote team to end up working in their own bubble is high. We do a lot to prevent that.
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 the team.
5. Providing and Soliciting Feedback
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. Sometimes, the buddy or the new starter may feel uncomfortable providing feedback to each other directly, so I do that for them.
In addition, I ask new starters to share their ideas about how their on-boarding could be easier and what they think they need to get up to speed even sooner.
Our daily catch-ups don’t take much time, usually less than 10 minutes. However, they quickly uncover issues. Luckily, in our case all 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 couple of weeks daily catch-ups feel too frequent and we schedule weekly 1–1s. In a few months, as the new team member settles in, we change the schedule to fortnightly.
During the first 3–4 weeks I check what the onboarding buddy and other developers think about the 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 save 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.
We personalise onboarding in our team to help the new developer to:
- get connected with the new team members,
- get familiar with how we work,
- learn relevant parts of the codebase,
- and get some basic bits of the domain knowledge.
Onboarding takes about four weeks. The new engineer starts with relatively simple technical tasks and progresses to more challenging product-related tasks. Along the way we identify their strengths to build on them, uncover gaps in their knowledge and ways to close them.
We use that knowledge together with their professional interests and aspirations that we discuss at 1-1s to pick the best tasks after onboarding to keep the new hire fully engaged in building the product and to support their professional growth at the same time.