Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

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

onboarding-framework.png

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

Recently Written

Software engineering manager interview questions (Aug 6)
Here are some questions I like to use to get a sense of who an engineering manager is and how they work.
A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.