A guide to successfully onboarding a developer
The onboarding experience sets the tone for a new developer — beyond the interview process, this will be the developer’s first impression of the company and the job. The onboarding process should be thoughtfully designed and should give the developer the tools they need for success and autonomy.
Before you start crafting your onboarding process, think back to your first few days at the organization. Except for the people who wrote the very first lines of code, everyone was new to the job at some point. Think about how much you had to learn in the beginning. Since then, institutional knowledge has only grown, so newcomers have even more to absorb and contextualize than those who joined even a few months earlier.
Without a structured onboarding process, this can be overwhelming for a new developer, for obvious reasons. By examining the experience with fresh eyes, you can identify the areas that need the most structure.
A good onboarding process will empower new employees and equip them with the knowledge and context they need to be successful at your company. A good onboarding process also has the power to improve employee retention, which enables smoother growth for your organization.
In this guide, we’ll walk you through some of the most crucial steps of successfully onboarding a developer.
Set goals and work backwards
In order to pull together a comprehensive onboarding process, you first need a sense of what you want the developer to accomplish by the end, and how long you expect that to take. What is the outcome of onboarding at your organization? Should an employee be handling tickets by the end of onboarding? Should they have input on architecture?
Once you have a goal in mind, think about how long you’d expect someone new to be able to take on that responsibility. The complexity of your code will be an important factor in figuring this ou. Should a developer be pushing code within a week? Three weeks? With an outcome and anticipated timeframe in mind, you can then start plotting out each phase of the process.
With an outcome and general timeframe in mind, you can work backwards to figure out what should be accomplished during each day of the onboarding process. It’s a good idea to set discrete goals for each day — this will help you maintain structure, and it will help the developer see the progress they’re making along the way. For example, the goal for day one might be to work through hiring documents and request access to the platforms they need, while the goal for day three might be pushing a line of code or tackling a mock ticket.
It’s also important to take the size of your organization into account when planning activities and training sessions. Smaller organizations have the opportunity to be more hands-on with onboarding and can personalize training to a greater degree, while larger organizations may opt for a structured, bootcamp-like approach.
Set up meetings
During the first few days of onboarding, consider how you can make a new developer feel welcome, especially if they’ll be working remotely. On the first day, the new developer should meet with their team members and manager for an intro call. This is a good opportunity to break the ice and get to know one another before the standup meeting, and avoids an awkward period of time where the developer is left wondering what to do.
A casual, 30-minute call can orient a new developer and make them feel more comfortable from the beginning. During this call, you can give the developer a sense of what the rest of the day, and training period, will look like.
Even if the whole team is included in the initial intro call, it’s a good idea to set up a few one-to-one meetings throughout the first week between the new developer and individual team members. This gives a new team member the chance to ask general questions or debug an issue, and gives experienced team members an opportunity to share expertise. These meetings also create time and space for the new developer to get to know their new team members and begin building rapport. Ultimately, the most important part of these meetings is just making sure they happen — the outcomes will naturally be focused on what matters most in the process.
Managers will probably want to set up more frequent meetings during the first few weeks. It’s a good idea to check in with a new developer two or three times a week before scaling back to once-a-week meetings. This gives managers the opportunity to gauge how the developer is acclimating and what their working style is like. Especially with smaller teams, these one-on-ones can significantly ramp up productivity.
Knowledge transfer sessions, which go beyond basic training, give developers a comprehensive understanding of the codebase and product. Developers can meet with other teams to gain a better understanding of their roles, as well as clients’ expectations. Project managers and product owners can give developers more context about the product and features, as well as the highest priorities.
In meeting with fellow developers, the new team member can gain a lot of context about the codebase. Although a lot of this may go over the developer’s head at first, when they begin coding, they’ll have small epiphanies and begin making connections because of these conversations.
Knowledge transfers help orient new team members not only as a developer, but as a member of the company as a whole. These sessions can also give a developer a clear sense of how they can add value to the business.
One of the most important parts of onboarding happens outside of meetings and activities: the onboarding document. It’s crucial that your organization has a well-documented setup process for your codebase, so a new developer can simply follow instructions for getting started. Thorough documentation also makes it easy to set discrete goals for the onboarding process. For example, a developer’s initial goal might be setting up access to all the tools they need by the end of the first day.
Create a single onboarding document with all of the links a developer will need, so developers have one resource that they can continue to refer back to. Having a basic guide is incredibly helpful to a new developer — structure gives them confidence in the process, and gives them a sense of what expectations are.
In this guide, you can also link to recommended readings: design docs, the most recent all-hands slide deck, a recording of a customer call, an overview of the team’s current plans, or any other resource that will give a developer context for what’s currently happening at the company.
Things can evolve quickly in between onboarding developers, so emphasize to new team members that the setup instructions are a living document. If developers encounter issues, it’s their responsibility to call attention to the problem or update the document with a fix so the next developer has a smoother experience. This responsibility is a key part of a culture of growth, and maintaining the document with small changes over time pays off in the long run. Plus, it gives new team members the sense of contributing something to the organization from the very beginning.
You may also consider investing in a service catalog, which acts as a single pane of glass for all your services and resources. With a service catalog, you can keep all of the documentation for each service in a single place.
Conduct an access audit
If you provide developers with a list of all the tools and links they need, make sure to conduct an audit to make sure new team members can access those tools when they join. This way, new developers don’t have to request access to a bunch of tools every day for the first week, which can disrupt momentum.
If your onboarding process requires that developers file tickets to gain access to certain tools, include instructions for the developer on how to file tickets. Make sure to include this in the developer’s checklist as well. One of the developer’s first goals might include filing tickets for those tools by the end of the first week.
Dashboards and monitoring tools
Make sure that you include dashboards and monitoring tools in the developer’s list of resources. Giving them access to relevant dashboards and key metrics can provide greater context about the product, expectations, and future goals. Provide the developer with guides on how to find logs, how those logs work, and how to navigate logs by user and workspace.
Because debugging is part of a developer’s flow, it’s a good idea to give the developer patterns and practices your teams use for debugging. If those are not already documented somewhere, make sure to include them in the onboarding document.
When building out your onboarding checklist, give the developer line of sight into future responsibilities. If the developer will be expected to join the on-call rotation down the road, let them know when that will happen and what the operational process for on-call at your company is. Tell the developer when they’ll be shadowing others and what the expectations for each stage of that process are. If the developer will eventually join the interviewing team, you can provide them with a list of interview questions so they have more insight into that process.
Giving a new developer a picture of what’s coming down the road allows them to plan and prepare. It also gives them a clear sense of the progress they’ll make in the near- and mid-term. Plus, they won’t feel as though new responsibilities are thrown at them out of nowhere.
Measure progress and continue learning
A good developer onboarding process should result in greater productivity and the ability to write a first line of code faster. Consider establishing proxy metrics to gauge the success of your onboarding process — time to code (or time to line up code in production) might be a good way to determine if you’re on the right track.
Be receptive to feedback from developers and keep an open mind when it comes to adjusting your onboarding process. Because new team members are the ones experiencing the onboarding process, they have the most insight into whether it’s fully preparing them for the job. They can also point to improvements in the process that well-established team members, who have a lot of institutional knowledge, may not see.
Don’t hesitate to learn from other teams at your organization along the way, too. See what other teams do well, and think about how you can incorporate those practices into your own onboarding process.
Onboarding is all about holistic learning, both for the new team member and those who are already established at your organization. By keeping this at the core of your developer process, you’ll be set up for success.