As companies start increasing their pace of innovation, engineering organizations find themselves in an interesting position. 

Instead of hypergrowth, teams are now focused on a new paradigm of efficient growth, with an eye toward improving developer effectiveness. With teams reporting a three to nine-month average time-to-productivity for new engineers, it's becoming increasingly clear that onboarding has an outsized impact on overall engineering effectiveness. 

Improving new engineering effectiveness

The first weeks of an engineer’s new role represent the most formative time for building context. A new engineer’s primary motivations are to understand their role, get access to information, and understand their team’s collaboration style. Done well, their pace of learning will increase and they’ll be contributing meaningfully in a matter of weeks. Done poorly, engineers can take months to build context and may never feel fully productive.

Here are five strategies to improve the effectiveness of your new engineer.

1. Set a clear structure for the first few weeks

For the first few weeks of an engineer’s time, they will be familiarizing themselves with the codebase, tools, people, and processes. The volume of new information is very overwhelming and how it is delivered will impact their ability to be productive, particularly in a remote environment where they aren’t building connections with their teammates.

Below are two common ways to onboard with very different outcomes.

Bad structure: assigning a new ticket on day one with no structured guidance and a “message us if you need us” mindset. 

This approach overwhelms the engineers with having to traverse a company culture they barely know for information. While the “sink or swim'' mindset is common in engineering, it often leads to wasted time as engineers spin their wheels trying to access knowledge.

Good structure: an organized system that introduces information in a way that builds on itself (i.e., introducing the team, introducing the tech stack, learning about the product domain, introducing the first project).

This approach helps a new engineer organize information by domain and create a solid foundation to build upon with each passing week.

2. Early 1:1s with both a manager and buddy

When a new engineer first joins, they are joining a largely unfamiliar codebase, team, and culture. In a remote setting, building context can be even more challenging. A study at Microsoft Research found that onboarding new engineers in a remote setting increases challenges with collaboration, asking for help, and building team connections. This is where a manager and a peer-level mentor (often known as a “buddy”) come in.

As Will Larsen points out, the team manager and the buddy both play distinct roles in supporting a new engineer’s success. The manager’s focus is to set the new engineer up for long-term success at the company, while the buddy’s focus is to answer questions frequently, resolve uncertainty, and build early confidence. A new engineer should know who their manager and buddy are in the first few days of joining.

An early 1:1 with both the manager and buddy, ideally in the first week of their joining, increases social familiarity and connection on the team. When new engineers have an early relationship established, they are more comfortable reaching out for help.

To get the most out of the 1:1, teammates should have a brief agenda that focuses on building clarity around an engineer’s role and the team they work with. For a manager, this might be a walk-through of the onboarding plan and an overview of the team culture. For the buddy, this may be a discussion on teammates, where important information lives, and how to ask for help.

3. Create a clear, well-scoped first engineering project

The first coding project will set the tone for how features get built on the team. While some teams know how to jump straight from a simple, written update into the building of core business logic, this structure relies on engineers to figure out everything from code structure to GitHub best practices. A more effective approach is to introduce an early task that is clearly scoped, well-defined, and helps new engineers gain familiarity with both business logic and development best practices.

When selecting the right first project, find something that strikes a balance between being straightforward and impactful. Bug fixes are often a great place to start – they are contained, have clear outcomes, and are usually tied to a core piece of business logic. Just make sure that the steps to reproduce are clearly labeled, as well as the expected result.

An example of this: if a back-end engineer joins a team that relies heavily on Kafka, an early feature could be to fix a small bug relating to event processing.

4. Give engineers an opportunity to build user empathy

Often when getting new engineers up to speed, teams are in a “yesterday” mindset – pressured to meet product deadlines, they needed this engineer here yesterday. This can lead to managers only building context for their new team members on what's immediately in front of them, instead of the broader vision. But it's not enough to just share the “what” behind the work – when teams share the “why”, productivity is boosted. As Wharton Professor Adam Grant shows, helping teammates build empathy for their end-users leads to better work.

For engineering teams, this empathy can be built in a number of ways. Shadowing customer success calls for a half day or sitting in on product discussions are two examples. If syncing calendars proves challenging, managers can collect and share customer call notes as well. Doing so will help engineers better understand the product they’re contributing to and result in better product development. When engineers know more about who they are building for, they can design features to better reflect how they’ll be used by customers.

5. Encourage a healthy code review culture

Once an engineer has set up their local environment, picked up their first task, and written some code, they’ll need to submit that code for feedback. For most engineers, their first pull request (PR) will come with multiple cycles of feedback from the team on things such as core logic, naming conventions, and code style. For the newly joining engineer, this will also be their first opportunity to “share their skills” and shape their confidence in working with the team. 

A good code review culture will accelerate a new engineer’s confidence and velocity. Conversely, if that first PR goes poorly, this decreases a new engineer’s pace almost immediately. Improvements in code review culture can take on many forms - here are a few:

• Reduce idle time: encourage teammates to make sure that comments from new engineers are addressed within one day. This gives an engineer the opportunity to learn and move forward, without being blocked for multiple days.
• Demonstrate, not tell: for PRs with more than three to four comments, encourage existing teammates to hop on a call to walk through their feedback. This will help new engineers better understand the systems they are working with.
• Encourage empathy: a new engineer likely hasn't built strong relationships with their team yet. Encourage teammates to be respectful and open-minded when delivering feedback. Even simple remarks like calling something “lazy” can have harmful effects and decrease a new engineer’s comfort with collaborating.

Final thoughts

Onboarding is a powerful tool that sets the tone for a team’s overall effectiveness. When done well, onboarding a new engineer lifts the entire team up and increases a team’s overall effectiveness. When done poorly, onboarding slows progress for the engineer and their overall team, leading to decreased productivity and lower tenure. 

As managers focus on efficient growth in this next season of innovation, now is a great time to improve processes (or introduce tools) to make new engineers become more effective, faster.