Running your engineering onboarding program.

Most companies say that it takes three to six months for newly hired engineers to fully ramp up. Engineering leaders know it’s impolitic to admit that it takes their team longer than three to six months to onboard new engineers, so that’s what they say out loud, but they generally believe it takes longer for a new engineer to become fully productive. They also know that their most impactful engineers are still becoming more productive after years with the company.

Running engineering onboarding is optimizing two closely related problems:

1. How do we increase the percentage of engineers who are reasonably productive at three months?
2. How do we set the foundation that ends with more extremely impactful engineers a few years from now?

Done well, it excites new hires and raises the floor for success. Indeed, in rapidly hiring companies, effective onboarding is the highest-value investment you can make into engineering productivity, but somehow it’s often dismissed as a secondary concern. Fortunately, like many oft-forgotten processes, you can go from no onboarding to rather good onboarding in short order.

To get there, we’ll walk through:

• Fundamental components of onboarding, including examples of several real companies onboarding processes
• Role of executive sponsor, orchestrator, manager and buddy in a typical onboarding process
• Curriculum to consider including in your onboarding
• Why onboarding programs fail
• Whether to integrate with wider company onboarding
• When to prioritize onboarding

By the end, you’ll have a plan for incrementally improving your current onboarding, and a clear perspective on when to move from ad-hoc efforts to a structured onboarding program.

Onboarding fundamentals and examples

A structured onboarding process comes down to staffing a handful of roles are filled (especially your role as the executive sponsor and someone to orchestrate onboarding), and deciding on the specific curriculum to include in your onboarding.

What this specifically looks like varies a bit across implementations, so I think it’s helpful to start with a few concrete examples of real-world engineering onboarding. Two caveats as we talk through these particulars. First, these often omit significant efforts around company-scope new hire onboarding, to focus specifically on engineering onboarding. Second, every company’s onboarding process evolves over time, any static description like those above can only capture one specific iteration, and all of the companies described below have evolved their onboarding beyond the specific approaches described here.

Examples of engineerin gonboarding programs:

• Digg: I showed up, got a company branded t-shirt and a laptop. My manager introduced me to the two other members of my team. They tried to issue me an integration environment, but the one engineer who knew how that worked had recently quit, so they told me to take over another recently departed engineer’s environment instead. With that, the onboarding was complete.

  It’s a bit messy, but a surprisingly large number of startups have effectively no onboarding beyond showing up, getting a laptop, and getting pointed to team mates who can help

• Facebook: Facebook runs a six week Engineering Bootcamp, attended by every new engineering and engineering management hire, with a focus on facilitating team selection between new hires and Facebook’s teams, and teaching new hires Facebook’s approach to development. They work directly on Facebook’s software, often fixing bugs, and are supported by dedicated Facebook engineers who review their pull requests, run office hours, and so on.

  Facebook’s Bootcamp is the most frequently mentioned model of high-investment engineering onboarding. When considering copying components, keep in mind both the volume of engineers going through Bootcamp (10s and later 100s of concurrent new engineers), and that it solves for both onboarding and team matching, which is atypical of most companies’ hiring processes

• Stripe: the first day focused on laptop setup, security practices, and getting familiar with Stripe’s development tools by making a small commit to the product website (eventually adding oneself to the company website’s About page). New engineering hires were then run through a curriculum ranging from architecture to observability.

  The final step of engineering onboarding group new hires into teams of four to six engineers. Each team worked on a project together, with one existing Stripe engineer serving as the project’s tech lead. These projects generally lasted 1-4 weeks, and were completed before releasing the teams to join their long-term teams

Roles

It’s easy to put a lot of energy into doing one-off design for your onboarding process, but onboarding programs are living things that require ongoing care. It’s more helpful to start by thinking about the roles necessary to operate an operating process, particularly the executive sponsor, program orchestrator, team manager, and onboarding buddy.

Executive sponsor

As the engineering executive, you probably won’t run engineering onboarding. You may lead an onboarding session for each class of new hires, which lets them know that you’re a real person, and builds a connection they can use to reach out if they have concerns later on. However, you do have a very important role to play in onboarding, which is serving as onboarding’s executive sponsor.

As onboarding’s executive sponsor, you should

• Select the program orchestrator to operate and evolve the program
• Align with the orchestrator on how to monitor the program over time (certainly through surveys, but ideally some objective data too)
• Monitor the program data on a monthly basis
• Meet directly with new hires who have exceptionally good or bad onboarding experiences to understand where things might be falling through the cracks
• Celebrate the program on an ongoing basis so that people continue to prioritize its success, including supporting onboarding work as a valid contribution towards being promoted

Amplifying the last point, companies struggle to prioritize onboarding, even when they know intellectually that it’s very important. Problems can be easy to miss, because new hires are unlikely to start out their time at a new company by complaining about onboarding.

Only you, as the executive sponsor for engineering onboarding, have the vantage point and authority to maintain an ongoing quality bar for an impactful onboarding program.

Program orchestrator

Where the executive sponsor provides the organizational resources to run an onboarding program, it’s the program orchestrator who translates those resources into a living program. Most frequently this is an engineering manager who runs onboarding in addition to other responsibilities, but at a scaled company this might well be someone in Engineering Operations or a Technical Program Manager.

The general role expectations are:

• Develop and maintain the program’s curriculum: what content to prioritize? How many courses should you have? And so on
• Evolve the program incrementally over time based on participant feedback and outcomes
• Coordinate each onboarding class to ensure it runs effectively
• Create onboarding templates that fit the curriculum, and are used by each new hire’s manager to continue their onboarding beyond the program itself
• Align with the executive sponsor on monitoring the program’s outcomes. This should typically include a post onboarding survey to all participants, a summary of survey responses, and data trends over time. You may also want to look at other developer efficiency metrics to understand where to focus subsequent onboarding investments
• Address the little mishaps that naturally happen in a program like this, e.g. a segment’s teacher calling out sick for the day

Selecting an effective program orchestrator is the single most important decision you’ll make for an effective onboarding program, and you’ll make it over and over again, as folks move shift out of this role. The most important considerations in my experience are:

• Real experience operating as an engineer at your company (or relationships to engage those with that experience)
• Energized by people as individuals rather than compliance to a process
• Ability to use feedback to drive ongoing improvement

Being the onboarding orchestrator is generally a part-time role until a company gets rather large (20+ engineers joining per month), but it’s not a small task. Whoever runs this program should be able to devote 20+ hours a month to its success. An engineering manager could take this on and manage a team, but it wouldn’t leave them much time for something else.

Team manager

Even the best onboarding process will have gaps and will prioritize the standard case over any particular individual, which is where the new hire’s manager comes into play. Where onboarding is focused on getting new hires off to a productive start, their manager is ultimately responsible for the new hire’s long-term success at the company.

The general role expectations are:

• Create a personalized onboarding document for each new hire, starting from a template created by the program orchestrator
• Start weekly 1:1s with the new hire. Even if you prefer less frequent 1:1s, it’s very valuable to have them weekly for a new hire’s first several months
• Assign an onboarding buddy to the new hire. In some cases, this is handled by by the program orchestrator, in which case you should ensure an appropriate buddy is assigned
• Partner with the onboarding buddy to identify a new hire’s first several projects. Finding safe learning projects that also provide real value to the business is an art, and will significantly accelerate the new hire’s impact and sense of belonging
• Make sure the new hire has actually been added to the various team meetings, chat rooms, email groups, and so on. Even if it’s supposed to happen automatically, this stuff gets routinely messed up, and can be very demoralizing for new hires when it happens

It’s worth acknowledging that managers are also operating under their own pressures, for example shipping a delayed project or restaffing a small production on-call rotation. It’s surprisingly common to see some friction between manager’s short-term goals and the onboarding program’s longer-term goals, e.g. asking to pull their new hire from onboarding to task them on a key deadline. The program orchestrator should fight against this tendency by frequently reminding managers how important onboarding is to their team’s success.

Onboarding buddy

The last important onboarding role is the onboarding buddy. The particulars vary a bit by company, but in most cases they are a second point of contact within the new hire’s team. The buddy can answer specific questions on development, setup and initial projects. They are also a fallback for when the team manager might be unavailable or slower to respond.

The general role expectations are:

• Bring the new hire along with you to meetings, to grab lunch, and to meet other members of the company. Don’t let them linger alone! This is especially true in remote companies, where a bit of effort will transform the company from an anonymous wall of faces into a community
• Schedule daily time with the new hire for their first several weeks. This can be 15 or 30 minutes with some time blocked afterwards in case it runs long. The goal is to resolve any blocking issues or topics for the new hire. Having something scheduled helps minimize the common scenario where the new hire feels awkward asking for help directly
• After one to two weeks, chat with the new hire about whether it’s helpful to continue the meetings for another month or two. This will come down to their personality and preferences more than any sort of best practice
• Keep in touch with the new hire’s manager about areas where things are going well or where they’re running into problems. It can be tempting to ignore early problems, but this is really the only chance you’ll have to address behavioral and cultural misalignment before they calcify. Feedback may not always be a gift, but it’s particularly valuable early

Curriculum

Once you’ve identified the orchestrator for your onboarding program, there’s still the matter of deciding on your curriculum–what should you actually focus on teaching? As an initial point to experiment from, I’d recommend three segments:

• Engineering values and strategy
• Technical architecture
• Spinning up the development environment

Once you have those three overview courses, work the problem from two angles:

• Survey new hires a month after onboarding to ask what they wish had been covered
• Survey manager and tech leads about areas where new hires are struggling. These might be technical, but is even more likely to be cultural

This will steer you down a valuable path and avoid getting lost in the endless potential onboarding topics. In particular, it will help you avoid including topics that are theoretically useful but no one shows much real interest in.

The other question to consider is whether to include a project component in your onboarding program, like Facebook’s programming components of Bootcamp or Stripe’s onboarding project teams. The general answer here is that these work very well if you put a lot of energy into them, and otherwise don’t go particularly well. It’s worth keeping in mind, the alternative to running an onboarding-driven project is that teams select projects for their new hires, which usually go well and don’t require centralized coordination.

Finally, one implicit topic in your onboarding curriculum is getting to know the people who join the company around the same time. When you’re looking purely at information learned and outcome metrics, it’s easy to miss what new employees often mention as onboarding’s biggest impact to them: getting to know the group of other new hires and building a network of people to ask questions of and eat lunch with.

Who can attend engineering onboarding?

The question of who is required to attend engineering onboarding, as well as who is allowed to attend, will come up periodically over the course of any program. My recommendation is to require all engineers and all engineering managers to attend, regardless of level. Some very experienced engineers and managers will attempt to skip, but I think that’s a bad idea to allow. Onboarding is as much about why things work the way they do as it is about how they work, and the number one risk for senior hires is that they try to change how things work before understanding why they work the way that do. You should especially require attendance for senior hires who insist they don’t need to attend.

If other functions, e.g. product, ask to attend engineering onboarding, my advice would be to not initially schedule them to attend, but letting them individually ask to be added to future onboarding cycles. This ensures that folks who really want to attend can, without requiring reworking engineering onboarding to be a rewarding experience for those without an engineering background.

Why onboarding programs fail

It’s tempting to think that onboarding programs fail because no one tried hard enough to create a great program. Certainly, some companies don’t invest in onboarding, which is a lost opportunity, but that isn’t what leads to failure. Instead, most programs fail because someone–with extremely good intentions–creates a complex, involved program.

The sequences goes like this:

• A new program orchestrator is selected to run engineering onboarding
• They develop a new, more involved program that addresses all the identified needs, although it happens to take a lot of energy to operate
• The new program launches, and everyone loves it. Finally, onboarding is solved!
• Over time, it’s hard to get enough internal engagement to run the program. People still love the program, but have too many conflicting priorities
• The orchestrator gets frustrated and transitions to another role. Te program is run by their replacement, who often doesn’t have the original orchestrator’s passion for the area
• The program becomes stale and bureaucratic
• The program is scaled back significantly to something much simpler

When you consider revising your onboarding process, make sure it’s something the orchestrator can run for the long-term. This needs to be something you can run when the excitement of a newly launched program dies down, and engineering managers stop sending the orchestrator “thank you” cards. The worst onboarding programs come from trying too hard, rather than not trying hard enough.

Integrating with company onboarding

In addition to engineering onboarding, it’s likely that your company has a wider onboarding program. This program might touch on many of the topics that are important within engineering onboarding, particularly those like users, annual goals, or company values. You should absolutely lean on the content from these whole company onboarding segments, and avoid duplicating the content.

The more controversial question that often comes up is whether the team coordinating company onboarding should also coordinate engineering onboarding. For example, if the People Programs team is running onboarding, shouldn’t they also schedule the onboarding sessions for the engineering team?

My experience is that you generally should continue running onboarding from within engineering. There are a few reasons for this:

• There is usually significant support for handing off the program to a centralized function to run it, because the program orchestrator sees it as an opportunity to take on a new role.

  However, the people who replace the program orchestrator will be less focused on effective engineering onboarding, and will not have experience operating as an engineer at your company. They will approach engineering onboarding with a focus on making it more consistent with the shared company onboarding process, even if that means eliminating key aspects of what makes engineering onboarding effective. This isn’t because they’re bad people, it’s just the natural incentives of a centralized function

• Once another function is responsible for running your onboarding process, experimenting with improvements will become much more difficult, as it requires cross-functional coordination with a team who are often very busy. Increasing the cost of experimentation will significantly harm onboarding quality over time

• Feedback and onboarding quality data will often become sensitive data within the other function, only infrequently shared with you after being sanitized. Rather than driving your onboarding with data, including knowing who to reach out to about problems, you may lose access to that data

Sometimes circumstances will align such that it’s unduly painful to maintain control of engineering’s onboarding process, and that’s fine. Sometimes ownership of these problems becomes sufficiently political that it’s difficult to retain ownership; executive leadership is about taking the best available path, not dying on every sword that presents itself.

When to prioritize onboarding

Onboarding is particularly impactful when you’re hiring a solid chunk of new hires every month. If you have ten new hires each month, then the economies of running classes will start to outpace one-on-one training. This is doubly true when you begin accelerating hiring, as your existing team will be both busy hiring, and out of practice at onboarding new engineers.

Even if you’re hiring modestly, good onboarding is a valuable investment. Effectively ramping up new hires is always worthwhile. The only case where I’d recommend against investing into onboarding is when you’re hiring so infrequently that onboarding materials frequently go out of date before they’re used a second time. In those cases, it’s better to invest into personalized onboarding with the individual than design a larger-scale program. Keep in mind, that’s not only a matter of headcount growth, but also of your natural attrition rates. Many companies are not growing their engineering organization, but still hiring many new team members due to attrition.

Finally, remember to experiment your way into the right level of onboarding. Start with something simple that you can pull together in a few days, and that might be enough.