Improving Developer Onboarding: Best Practices

When a new developer arrives at a company, everything comes at them all at once - new team, projects, processes, tools, technologies, and codebase. It's like stepping into a bustling metropolis with its own language, culture, and way of life. Onboarding into life in this busy metropolis isn't just a process; it's a pivotal moment. It's the bridge between the excitement of joining a new team and the real, day-to-day challenges of contributing effectively. It can be the catalyst for a developer's success or, unfortunately, the precursor to their departure. Consider this: A 2022 survey revealed some sobering statistics. 52% of new hires in the United States contemplate resigning within the first three months of starting a new position, and a staggering 74% actively look for new opportunities before their first anniversary. These numbers underscore the critical importance of a well-executed onboarding process. Let’s delve into the best strategies that can transform a potentially overwhelming transition into a seamless and productive journey. Onboarding Approach - “Sink or swim” or “Here are 80 hours of lectures” Does this approach sound familiar? “Hey, I’ve sent you an email containing all the materials you will need to get familiar with what we do. You will find 10 hours of videos that will help you understand the business and around 15 different tools to set up. Any questions? Cool, welcome aboard!” Some hiring managers believe in the old adage of “sink or swim,” throwing the developers into the deep end as soon as possible… and, oftentimes, without much assistance. While hands-on practice and research are a cornerstone of ramping up your codebase and tech stack knowledge, it may take longer for a new engineer to obtain the critical knowledge that other team members have. Even if an engineer is used to self-learning and can gradually fill in the “known unknowns” themselves, they have no way of knowing what the “unknown unknowns” are (things they don’t even know they are missing), unless someone in the team tells them. For example, the fact that they use an obscure legacy message queue solution, just for a specific feature. Therefore, to help the new hire hit the ground running and provide more comprehensive guidance, the hiring manager might decide to set up a more structured onboarding process. This, however, might result in situations like this: “We’ve scheduled for you daily 8-hour video conferences where the engineering team will walk you through all of their code, line-by-line, for 4 weeks. Then you can start working on the code - if you need help we have documentation throughout 3 different systems, although some might be incomplete, contradictory, or outdated.” Alas, even the best onboarding plan can't anticipate every question, or expect the new hires to remember everything they’ve learned in the first week. Since the above two strategies are not entirely successful, the hiring manager might think that the best solution is to craft a personalized approach that aligns with the individual developer's role and experience. Unfortunately, this can often turn into: “We’ll wait for the engineers to arrive and they’ll figure something out together” In practice, the best onboarding approach may involve a combination of these approaches. For example, starting with a structured onboarding to cover essential basics and then transitioning to an agile or self-paced approach once the engineer is comfortable, all the while ensuring they have access to thorough and updated documentation. Regardless of the balance you strike between structure and flexibility, your main objectives should be (a) a great first impression of your team, company, and product and (b) setting up your new hire for long-term success. Onboarding Best Practices - The Big Picture The length of onboarding can vary from organization to organization and from role to role. Usually, the minimum is 3 months, but given the huge impact it can have on the new engineers' productivity, morale, and retention, it’s a process that can last up to 18 months. To ensure the new engineer has all the context they need to become a functioning member of the team as soon as possible, we recommend starting with an overview of the “big picture”: COMPANY → How does their role fit into the big picture? Engineers don’t just write code, but create products, services, and experiences. For example, can they see how the feature they’re working on will help drive the business results the company is pursuing? Having exposure to executive leadership and high-level strategy also allows new hires a glimpse of the company culture and a better understanding of business priorities. PRODUCT → What kinds of experiences are the typical customers having? Engineers that try the product first hand have a better understanding of user pain points, can analyze requirements, flesh out features, and implement designs that consider future functionalit

Mar 27, 2025 - 16:30

Improving Developer Onboarding: Best Practices

When a new developer arrives at a company, everything comes at them all at once - new team, projects, processes, tools, technologies, and codebase. It's like stepping into a bustling metropolis with its own language, culture, and way of life.

Onboarding into life in this busy metropolis isn't just a process; it's a pivotal moment. It's the bridge between the excitement of joining a new team and the real, day-to-day challenges of contributing effectively. It can be the catalyst for a developer's success or, unfortunately, the precursor to their departure.

Consider this: A 2022 survey revealed some sobering statistics. 52% of new hires in the United States contemplate resigning within the first three months of starting a new position, and a staggering 74% actively look for new opportunities before their first anniversary. These numbers underscore the critical importance of a well-executed onboarding process.

Let’s delve into the best strategies that can transform a potentially overwhelming transition into a seamless and productive journey.

Onboarding Approach - “Sink or swim” or “Here are 80 hours of lectures”

Does this approach sound familiar?

“Hey, I’ve sent you an email containing all the materials you will need to get familiar with what we do. You will find 10 hours of videos that will help you understand the business and around 15 different tools to set up. Any questions? Cool, welcome aboard!”

Some hiring managers believe in the old adage of “sink or swim,” throwing the developers into the deep end as soon as possible… and, oftentimes, without much assistance.

While hands-on practice and research are a cornerstone of ramping up your codebase and tech stack knowledge, it may take longer for a new engineer to obtain the critical knowledge that other team members have.

Even if an engineer is used to self-learning and can gradually fill in the “known unknowns” themselves, they have no way of knowing what the “unknown unknowns” are (things they don’t even know they are missing), unless someone in the team tells them. For example, the fact that they use an obscure legacy message queue solution, just for a specific feature.

Therefore, to help the new hire hit the ground running and provide more comprehensive guidance, the hiring manager might decide to set up a more structured onboarding process.

This, however, might result in situations like this:

“We’ve scheduled for you daily 8-hour video conferences where the engineering team will walk you through all of their code, line-by-line, for 4 weeks. Then you can start working on the code - if you need help we have documentation throughout 3 different systems, although some might be incomplete, contradictory, or outdated.”

Alas, even the best onboarding plan can't anticipate every question, or expect the new hires to remember everything they’ve learned in the first week.

Since the above two strategies are not entirely successful, the hiring manager might think that the best solution is to craft a personalized approach that aligns with the individual developer's role and experience. Unfortunately, this can often turn into:

“We’ll wait for the engineers to arrive and they’ll figure something out together”

In practice, the best onboarding approach may involve a combination of these approaches.

For example, starting with a structured onboarding to cover essential basics and then transitioning to an agile or self-paced approach once the engineer is comfortable, all the while ensuring they have access to thorough and updated documentation.

Regardless of the balance you strike between structure and flexibility, your main objectives should be (a) a great first impression of your team, company, and product and (b) setting up your new hire for long-term success.

Onboarding Best Practices - The Big Picture

The length of onboarding can vary from organization to organization and from role to role. Usually, the minimum is 3 months, but given the huge impact it can have on the new engineers' productivity, morale, and retention, it’s a process that can last up to 18 months.

To ensure the new engineer has all the context they need to become a functioning member of the team as soon as possible, we recommend starting with an overview of the “big picture”:

COMPANY → How does their role fit into the big picture? Engineers don’t just write code, but create products, services, and experiences. For example, can they see how the feature they’re working on will help drive the business results the company is pursuing? Having exposure to executive leadership and high-level strategy also allows new hires a glimpse of the company culture and a better understanding of business priorities.
PRODUCT → What kinds of experiences are the typical customers having? Engineers that try the product first hand have a better understanding of user pain points, can analyze requirements, flesh out features, and implement designs that consider future functionality.
Including product recordings or customer interviews in the onboarding, and scheduling meetings with Support, Sales, Customer Success, and Marketing also provides insight into the user experience.
ROLE → Ahead of time, the hiring manager, should have fleshed out a document explaining the job-specific tasks, day-to-day responsibilities, and milestones. One of the first steps in the onboarding process should be walking through this together to clarify what’s expected of the role and any specific projects or tasks they will be working on.