A framework for onboarding new employees

When hiring new employees the process of getting them ready to be productive members of the team is usually arbitrary and disorganized. The HR process of getting payroll and benefits set up may be effective, but training someone in the way the actual work happens is not. Most of the time onboarding consists of, "Chuck will show you what you need to know." Chuck isn’t given any guidance to follow, and every new employee gets trained differently.

To learn how to cook hamburgers at McDonald’s, a new employee watches several hours of video, then gets a hands-on demonstration, and finally cooks a few burgers while someone monitors. When we hire someone to build complex software products, the onboarding process is, "You’re smart, I’m sure you’ll figure it out."

Running a good onboarding process is essential to making sure new employees are productive, satisfied, and effective.

There’s no single good way to onboard an employee. The details of the role, the company, and what makes for an effective teammate differ. Instead of One True Process, here’s a framework for creating one that you can adapt to each situation.

Milestones

The point of an onboarding process is to make someone effective once you’re done. Effectiveness isn’t a state, it’s a continuum. A developer with a year of tenure wouldn’t be effective if she were only able to do what she could do after her first month. So the first step in the framework is defining the milestones. What do you want her to be able to do one week, one month, or one year after hiring?

The milestones will be different for different roles and realities. In a bureaucracy with lots of initial HR paperwork, it might be a week before a new hire even can start working. The complex codebase might mean it’s a month before you can expect any reasonable contribution. Yet if you’re a startup you might want to push for new developers to make their first commit on the first day.

To define your milestones, start by thinking of the small steps toward the larger goal of a fully-ramped hire. You might expect all your developers to be contributing significant changes once after one month. How do you get the new employee to that point? She needs a local dev environment, an account on the build server, and to understand how to navigate your issue tracker.

Then build these steps into the smallest possible measurable outcomes the employee could generate. What’s the “hello world” of each step? For example, setting up a local development environment is subjective. Who can tell if it’s done? But “deployed something to production” is an outcome you can measure. It’s not subjective. There’s either code in production or there’s not. She couldn’t do that without a local environment, access to the build server, and so forth, so it’s a good proxy measurement for all those steps.

This is your milestone. The outcome and the timeframe for completion.

Here are some sample milestones to illustrate the concept:

Developer

• Day 1: trivial change (even a code comment) pushed to production
• Day 2: one “good first issue” issue resolved and deployed
• Day 7: completed one story
• Day 30: triaged a production bug she did not create
• Day 45: wrote the release note for one change

Product manager

• Day 1: can perform your scripted basic sales demo
• Day 7: present to the product team on 10 things you find confusing about the product and why
• Day 15: report back to the team on customer feedback from two customer meetings
• Day 45: present results and next steps from one product experiment
• Day 60: run the product strategy training for new sales hires

For the product manager to accomplish that day 45 milestone he will need to be able to define a useful experiment for the team, guide it through deployment, run reports on product analytics, and perhaps interview some users that used it. He’ll need a solid thesis on what to learn from the experiment and a plan for what to adjust based on the learnings.

Training

The next step in the onboarding framework is to figure out to give someone the knowledge they need to reach each milestone. Will you have documentation they need to read? Pair with someone more experienced and just observe? Get active training from a peer or manager?

You’ll want to document exactly how you expect the person to reach each milestone. What materials or information you will need? How do you intend to provide them?

For example, the developer that on day one will deploy a trivial change to production will need to know how to set up her local environment. This is probably best accomplished with a document and a buddy to ask if she gets stuck. She’ll need to know how to get her code reviewed. You might decide that it’s her buddy’s job to do that and that he needs to show her how. She needs to know how to run tests and check the build server for errors, and you might decide to make this part of the “getting started” document that helped her set up her development environment. And finally, you need her to deploy to production, so you have her buddy show her how to do it.

The idea is to break all those steps down and be intentional about what you teach and how you teach it. Put each step in writing, even if it’s just, “her buddy will add her to the build server spam channel.”

You’re breaking down the training into small modules that you can continually improve as time goes. If you try and create the ultimate onboarding training all at once, you’ll fail. The task is simply too large and complex. So you break it down into a series of much smaller pieces of training, and you don’t worry too much if they are all complete, or even correct. Because you’ll be improving them with the feedback loops.

Feedback Loops

The final part of the framework is a feedback double loop. The first loop is the Step Loop. The new hire improves the process, both at a micro level (“the deploy system docs were missing this command”) and a macro level (“the ‘Good First Issue’ list was too complex and I needed an extra couple days to understand the codebase”). In the Step loop, the employee that’s going through the process gives feedback on the process to improve each step as they go through it.

The second loop is the Process loop. The rest of the team evaluates, after every new hire, whether the onboarding process is correct and complete. For example, when you decided that a new software engineer should push a trivial change to production on her first day, was that useful in getting her up to speed faster? In this loop, the team evaluates the results of the entire onboarding process and makes adjustments. If something is missing, the team adds it in. It’s okay if the addition is incomplete because it will get improved in the next feedback loop.

The process will likely grow too large over time. That you will add too much level of detail. That every moment of the early days of a new hire’s life is over-proscribed. When running the Process improvement loop, the team should watch out for this and prune and refine milestones, not just add them.

The Step improvement loop cleans up the details. The Process improvement loop evolves the entire onboarding process.

The Framework

The framework is defining Milestones that determine Training, with a double Feedback Loop that continually evolves and improves both the milestones and the training.