Considerations for engineering leaders creating an onboarding strategy

This is part final part of our three-part engineering leader’s guide to an onboarding strategy. If you want to start at the beginning, check out Why quality onboarding matters for engineering leaders. 

Since there is no one-size-fits-all onboarding process, this guide lays out several considerations for designing a thoughtful approach that suits an organization’s culture.

Whether looking to onboard a team’s first outside engineers or to revamp an existing process, effective engineering leaders start with understanding what they want out of their onboarding program. Yes, they can fail fast with onboarding and iterate and improve on the fly, much like we all do with just about any software we develop. But they will also save themselves time and resources (in the form of retaining successfully integrated engineers) if they answer some key questions in advance of designing a program’s version 1.0. 

These questions include: 

• At what point in the new-hire process do we begin onboarding? 

• How long will formal onboarding last? How about informal onboarding? 

• What impressions of the organization and the team do we want engineers to develop on the first day? 

• What’s important or particular about our organization’s culture that we’d like new hires to understand explicitly? 

• Who in the organization will play what roles in onboarding? And who ultimately owns onboarding? 

• What types of goals and milestones do we want to set for new engineers? 

• What’s our plan for evaluating our program’s success? 

Of course, individual leaders can dash off some back-of-the-envelope answers to these questions by themselves. But when they’re serious about developing an onboarding plan that’s both successful and evolvable, it’s worth their while to answer these questions with other stakeholders in the organization.  

Onboarding is a product, and the intended audience is the newest engineers. 

Like any product, customer satisfaction contributes to its success. So for engineers to thrive in an organizational environment, it’s important to develop an onboarding plan that sets them up for self-driven success as well as one that the existing organizational structure can get behind. It’s got to be a process that the other managers, team leads, executives, mentors and so on can support and work with.

The clearer the onboarding philosophy is before starting to craft an onboarding plan, the more effectively the organization will get on board with it. 

Naturally, a successful onboarding gets engineers producing and contributing to the overall success of the team and the organization. But what does a successful engineer do? “Code lots” might be accurate, but it isn’t really descriptive. 

It’s worth taking the time, even if it’s already been done previously, to determine what exactly success looks like in a specific organization. 

For example, at Drift, speed and customer centricity are the organization’s two differentiators, according to Pete Karl II, Lead of Product Efficiency. New engineers build up incremental and immediate wins to the point of creating customer value during the onboarding process at Drift, precisely because those are the organization’s core tenets.  

“Customer value is the fuel that drives engineering success here,” Karl says. “Because we’re customer-centric, the quality by which we measure ourselves is how successful our customers are, not test coverage, not which framework we chose.” 

Customer centricity, in practice, means that engineers aren’t refactoring for the sake of refactoring, or rebuilding something for the sake of rebuilding, or choosing a new tool for kicks and grins. The answer to “Should I use this? Should I introduce this? Should I tackle this?” depends completely on whether it will have a beneficial impact on the customer.  

Karl goes over this concept with new hires in a 15-minute chat so they get that Drift’s work is oriented around the success of its customers. But the real onboarding on this idea happens with the engineers’ first customer-centric contributions to the code. 

This final win of Drift’s onboarding is so important because it’s when the engineers place the work in context—they connect the technical work they’re doing to the benefit a customer derives from that work. The engineers get to own that bridge. Creating customer value is their job, now and in the future. 

So what is an organization’s center—the point from which its work is focused? Is it finance-centered, product-centered, impact-centered, customer-centered?  

This is a conversation to have explicitly as part of designing an onboarding process. It will guide the understanding of what a successfully onboarded engineer does—and then shepherd the team as its leaders get them fully engaged and contributing actively as efficiently as possible. 

If an organization doesn’t know what exactly success looks like, that’s alright—for the moment. Figuring it out may help clear up any identity crises the company is experiencing. And once it’s pinned down, new hires can get up to speed by contributing work from that central purpose and leaders can assess their progress through that lens.

Remember always that onboarding programs are an investment in an organization. Teams can throw spaghetti at a wall and see what sticks. Or, by focusing on what factors are most crucial to success in their specific organization, they can focus their efforts to maximize the impact that the newest engineers can make over their time with the team.

A frequent assumption about onboarding is that it begins when engineers show up for their first day on the job. In the view of Benjamin Jackson, principal at For The Win, that’s way too late to start the process. 

“Really from the moment you initially reach out to a candidate, you’re onboarding them into your organization,” he says. “That is their first experience with your company.” 

We all judge books by their covers. Justified or not, that first experience will set the initial tone for a company’s entire relationship with candidates. They can either wow them, or lose them. So even though prospective developers are far from setting up passwords or filling out W-4s, treating them like they’re already one of your own goes a long way toward a positive relationship. 

Then, Jackson says, keep up that relationship for the transitional period between hiring a candidate and when they begin. 

“This is the thing that often gets most overlooked,” he says. “It’s not just a candidate experience that counts, but also the preparation prior to the first day.” 

An organization has wined and dined a candidate who agrees to join the company. But before jumping ship, they’ll put in their two to four weeks’ notice. “That is a great time for candidates to get cold feet,” Jackson notes. 

It’s also a great time for another company to swoop in and sweep them up with an offer letter and more thorough coaching before they even walk in the door. That other company is using an effective onboarding process to make a more thorough, transparent offer. 

So keep up genuine efforts during that transition period. Jackson suggests welcoming new hires in whatever way is true to the company—inviting them to a social event with their new team, or sending them information they can read to ramp up before they get to the job. 

“All of those things help keep people from getting cold feet,” he says, “but they also give people a head start so when they do walk in the door they can spend the first day getting things done instead of reading your code guidelines.”

An engineer’s new company gets only one chance at a first impression. So the hiring and onboarding process does even more than establishing a relationship with prospective hires; it actually sets the tone for how the company operates. 

“We talk about how engineers hate process,” says Cate Huston, Mobile Lead at Automattic, “but here’s my theory about engineers and process. Engineers actually love process, but when they love it they call it culture.” 

This is a classic example of actions speaking louder than words. Conducting interviews and onboarding in a way that’s honest to the everyday culture defines the organizational environment for new engineers. 

Huston recommends interviewing prospective hires with curiosity, rather than looking for reasons to fail them. Curiosity, in short, means striving to get to know people—which also helps out in the long run because teams can start them off in a position to hit the ground running. Managers will already know something of their strengths and can put them on a project that speaks to them. 

“My observation about onboarding,” Huston says, “is that you spend as long as you do onboarding somebody badly, trying to fix it.” 

It’s all about individuals succeeding in their new roles. So by onboarding mindful of culture, tech leaders actively show their team members that success is crucial and that they are investing their efforts in ensuring that success. The process for making the transition into the company becomes clear and transparent. And by incorporating these processes from the get-go, leaders set the tone for what the culture empowers their teams to do.

Drafting employee handbooks is a classic way to codify all the expectations discussed in this guide—what engineers should expect from their teammates, their managers and the organization, as well as what all of those expect from an engineer. That action alone can strengthen the relationship between leadership and already existing teams, in addition to setting the tone for new developers. Done well, the org will also end up with a killer employee handbook. 

We know there’s hardly a more boring text on the planet than your typical employee handbook. That’s why Benjamin Jackson suggests doing something different. 

“I think that treating the employee handbook as a legal or an HR mechanism is missing half the point,” he says. “There’s a missed opportunity for a lot of companies to reinforce their culture—through the content, what they choose to put in it, the voice and tone, the design.” 

Employee manuals are about setting expectations. They still have to acknowledge all those legal and HR necessities. “But you can set expectations that are wholly unrelated to the minutia of policy,” Jackson says. 

(He points to some well-designed employee handbooks at Austin Frazer, Big Spaceship, and Valve.) 

Once an employee handbook articulates an org’s cultural experience, it’s still not meant to be just handed off to a new employee. It doesn’t do the heavy lifting by itself. The human-to-human channel of information is still the most personal and meaningful. 

“The research that I’ve read says that mentoring is one of the most guaranteed ways to increase someone’s chance of success,” Jackson says. So getting current employees involved with onboarding new hires helps them all feel more ownership in the process; it also gives new engineers a real person to turn to in those crucial first weeks and months.

Once engineers are up and running, the code review process is an invaluable tool for ensuring a team is consistently learning from each other. Code review is always a chance for cross-pollinating information and expertise between team members, which makes it a great place for integrating new hires into the team.

A key component of successful engineer onboarding is ensuring both that engineers new to a team are learning the code as well as learning how to engage meaningfully with their new teammates.

If the onboarding process doesn’t look to be going well for new hires, trust that evaluation—and then look for both concrete measures to take, and make responses to each individual engineer’s new job situation.  

If new developers don’t seem to have a sense of cohesion within the team or if they seem at all overwhelmed or afraid of certain things, those are signs that their onboarding needs a course correction.  

Of course, managers typically don’t expect a new hire to understand every aspect of the job on day one. That’s why they keep an eye on whether their contributions are trending in the right direction over time. But it’s those more primal responses—how new hires respond to new environments and responsibilities—that offer the biggest tip offs right away. 

Conversely, managers can also look for signs that a team member is being onboarded successfully and opportunities to continue encouraging it. 

Being onboarded well leads to a sense of belonging and accomplishment. Whatever philosophy rests behind an organization’s onboarding process, and whatever other steps are taken, engineers developing that sense is perhaps the greatest outcome of onboarding. Whenever managers ensure new engineers take on projects that suit their skills, offer them sound support, pay attention to their developers and value their opinions, those engineers are encouraged to have a voice within the team.