{"id":3892,"date":"2022-01-24T12:34:09","date_gmt":"2022-01-24T02:34:09","guid":{"rendered":"https:\/\/eisabainyo.net\/weblog\/?p=3892"},"modified":"2022-12-24T14:19:00","modified_gmt":"2022-12-24T04:19:00","slug":"the-three-stages-to-onboarding-software-engineers-a-guide-for-engineering-managers","status":"publish","type":"post","link":"https:\/\/eisabainyo.net\/weblog\/2022\/01\/24\/the-three-stages-to-onboarding-software-engineers-a-guide-for-engineering-managers\/","title":{"rendered":"The Three Stages To Onboarding Software Engineers – A Guide for Engineering Managers"},"content":{"rendered":"

Spoiler alert: Don't let them touch code on Day\u00a01.<\/em> <\/p>\n

Onboarding is one of the foundations that companies and managers need to get right for new software engineers to become productive, loyal, and engaged employees.
\nWe all know this: First impression matters. The first impression for a new software developer starts the moment they join the company, and that impression lasts for a long time, sometimes for the duration of their tenure with the company. Set the bar high by making them feel valued and setting them up for success.<\/p>\n

The three stages of onboarding new software engineers<\/h3>\n

There are three main stages to onboarding software engineers. They are:
\nStage I: The Big Picture
\nStage II: The Process
\nStage III: The Code<\/p>\n

As you can see, learning about and writing code is the last stage, which is for excellent reasons. As an engineering manager onboarding a new software engineer, you will need to guide the engineer, so they don't get tempted to start coding right away. They need to understand the big picture and know about the processes so that they don't encounter landmines that will slow down their progress later.<\/p>\n

Let's take a look at what to cover at each stage of the onboarding journey.<\/p>\n

\n

Stage I: It's About the Big\u00a0Picture<\/h3>\n

The goal of stage 1 is for the engineer to understand three critical pillars\u200a-\u200athe company, the product, and the role. On the company pillar, they need to know the culture and values, the dynamics, and how things get done.<\/p>\n

On the product pillar, it's recommended that they play around with the product and use the features as a typical customer would. Doing this will build their customer empathy and accelerate their efficiency when they start writing code.<\/p>\n

The role pillar ensures they understand what's expected of the role. This includes how they work with their peers, stakeholders, and colleagues. What they need to deliver in the role is critical to their success.<\/p>\n

When should a new software engineer learn more about the company, its culture, and its values?<\/strong>
\nSmall startup: On day one
\nLarge enterprise: Within the first three days<\/p>\n

When should a new software engineer learn more about the product, its features, customers, and value proposition?<\/strong>
\nSmall startup: Within the first two days
\nLarge enterprise: Within the first week<\/p>\n

When should a new software engineer understand what's expected from their role, who they will be working with, and what outcomes they need to produce?<\/strong>
\nSmall startup: Within the first three days
\nLarge enterprise: Within the first week<\/p>\n

*When should a new software engineer start talking about their career aspirations with their manager?<\/strong>
\nSmall startup: Within 30 days
\nLarge enterprise: Within 90 days<\/p>\n

\n

Stage II: It's About the\u00a0Process<\/h3>\n

Every software engineer can write code, but code just sitting on a developer's machine is not much value to the company or customers. One significant risk engineering managers need to prevent with new software engineers is the Not Invented Here syndrome. We want to avoid re-inventing the wheel for things that have already been done or defined in the company.<\/p>\n

The process stage of onboarding ensures new software engineers know how to get their code to the hands of customers, leverage current systems and mechanisms that already exist within the company, and become team players that contribute to the success of the team that they are joining.<\/p>\n

When should a new software engineer start being on-call for their team's services, especially if the company practices You Built You Release It (YBIYRI)?<\/strong>
\nSmall startup: Within the first month.
\nLarge enterprise: After they've shadowed an on-call rotation. Usually after a few months.<\/p>\n

When should a new software engineer put their hands up to drive a team activity, e.g., running a retro?<\/strong>
\nSmall startup: After they've seen how it's done at least two times.
\nLarge enterprise: Same as above.<\/p>\n

When should a new software engineer be comfortable being an Approver for someone else's Pull Request?<\/strong>
\nSmall startup: Within 15 days
\nLarge enterprise: Within 60 days<\/p>\n

When should a new software engineer know about the build and release process?<\/strong>
\nSmall startup: Within the first week
\nLarge enterprise: Within the three weeks<\/p>\n

When should a new software engineer start being an active participant in various guilds and charters, e.g., Frontend Guild, Technical Architecture Guild, etc.<\/strong>
\nSmall startup: In one month
\nLarge enterprise: In three months<\/p>\n

When should a new software engineer start contributing to technical discussions?<\/strong>
\nSmall startup: In three months
\nLarge enterprise: In six months<\/p>\n

When should a new software engineer have good knowledge of operational aspects of engineering?<\/strong>
\nSmall startup: Within the first 20 days
\nLarge enterprise: Within the first 60 days<\/p>\n

\n

Stage III: It's All About the\u00a0Code<\/h3>\n

The last and final stage is the favorite stage for most software engineers. Coding is their comfort zone. One of the reasons this is the final stage that a good interview process would have ensured that the new software engineer has the required technical capability for the role, and this stage is relatively straightforward.<\/p>\n

When should a new software engineer set up the development instance on their machine?<\/strong>
\nSmall startup: On the first day
\nLarge enterprise: Within the first two weeks<\/p>\n

When should a new software engineer make their first commit?<\/strong>
\nSmall startup: Within the first three days
\nLarge enterprise: In the first two weeks<\/p>\n

When should a new software engineer expect to see their work live on production?<\/strong>
\nSmall startup: Within the first ten days
\nLarge enterprise: It depends. The next release cycle after their first month.<\/p>\n

When should a new software engineer learn about best practices and coding standards?<\/strong>
\nSmall startup: Within the first week
\nLarge enterprise: Within the first two weeks<\/p>\n

When should a new software engineer understand the system's architecture that they'll be contributing code?<\/strong>
\nSmall startup: In the first week
\nLarge enterprise: In the first month<\/p>\n

When should a new software engineer start contributing to story estimation?<\/strong>
\nSmall startup: After your first sprint
\nLarge enterprise: After two sprints<\/em>
\nOne sprint=Two weeks<\/p>\n

When should a new software engineer independently pick up and complete a task from the team's backlog?<\/strong>
\nSmall startup: Within the first sprint
\nLarge enterprise: Within the first month<\/p>\n

Regardless of whether they are a junior software developer or a senior one, you, as their engineering manager, should have some tasks that they should be able to pick up independently based on their seniority level. Make sure you communicate the expectation with them.<\/p>\n

\n

Best practices for onboarding new software engineers<\/h3>\n

As an engineering manager who's onboarded hundreds of new software engineers at tech companies ranging from interns and graduates to staff engineers, there are five best practices:<\/p>\n