When you start a new job, it often feels like you’ve jumped into the deep end of the pool and you need to find a way to just stay afloat. Eventually, the panic subsides and you’re keeping your head above the water. Then you learn to start swimming and are able to move confidently within your new surroundings. How can you tell which stage you’re in?

Every new job starts with a process of “onboarding” into that role, whether formal or informal. How do you know when you’re fully onboarded? When do you feel like you have a good handle on things?

When I started at Sequin, one of the first things I did was write down a list of Onboarding Milestones that I could use to gauge my progress. These milestones gave me a roadmap of where I needed to dig deeper. They gave me a sense of accomplishment to see how far I’d come since I started. They formed the basis of my 30/60/90-day and then quarterly goals.

My initial list was very focused on learning the codebase and its architecture. Here it is:

  • [x] Can confidently review a non-trivial PR
  • [x] Can ship customer-facing code to production
  • [x] Can implement and test a non-trivial feature end-to-end
  • [x] Can safely refactor a non-trivial part of the codebase
  • [x] Can successfully complete a single day of on-call with no help
  • [ ] Can successfully complete a full week of on-call with no help
  • [x] Can safely make a small deployment change (e.g. adding a new env var)
  • [ ] Can safely make a larger infrastructure change (e.g. CI, CD, deployment)
  • [x] Can definitively answer questions about how something works from another team member
  • [ ] Can update the CHANGELOG (We decided to make announcements elsewhere, so no longer relevant)
  • [x] Can write a big picture/visionary memo about product direction
  • [x] Can triage/debug a production issue with no help
  • [x] Can recognize when seemingly innocent issues are representative of a larger issue

Over time, I add and remove milestones from the list. I might come to realize that there’s something important that I don’t know much about, so I’ll add milestones to tell me when I’ve learned about it. Something might change that means that a milestone is no longer relevant, so I’ll drop it.

As you can see, I hit most of these milestones in my time at Sequin, but I still had a couple to go.

On one of my on-call weeks, I handled everything on my own until the last half-day of my shift, when a really weird new issue arose that I couldn’t figure out. I asked for help, and the milestone remained incomplete. But that’s OK. I was much more capable at customer support than when I started and I even contributed substantial improvements to the support process. This outstanding milestone helped me to focus on learning what I still needed to learn in order to eventually complete it.

Upon reflection, I’d add more items that are less technically focused. Sequin is a very small startup where we all needed to wear a lot of hats. This list has nothing about some of these hats. Some examples of what I’d add:

  • More cross-functional items related to marketing, customer calls/discovery sessions, sales, etc.
  • Writing documentation
  • Writing blog posts
  • Other outside communication
  • Leading projects
  • Using our own software for something useful (“dog-fooding”)

You don’t need to change companies to get value from Onboarding Milestones. Use them any time you get promoted or take on new responsibilities.

I will definitely employ Onboarding Milestones again when I start my next role. I’ve found them extremely valuable.

Your list of Onboarding Milestones is going to be very different from mine. Here are some things to think about as you start to brainstorm:

  • What kinds of things are you expected to accomplish in your role?
  • What does success look like for your role?
  • How senior is your role? The milestone list for someone new to this career will look very different than the one for a senior person with many years of experience.
  • What do you value?
  • What can you control and/or influence? What factors are outside of your control?

Here’s a partial list of categories to consider as you develop your Onboarding Milestones:

  • Customer interaction
  • Representing your company to the outside world
  • Customer support
  • Troubleshooting/debugging/incidents
  • Peer interaction
  • Mentoring/being mentored
  • Contributions to code/documentation/PR reviews
  • Comfort in the codebase: where to find stuff; where the tech debt lives; etc.
  • Subject matter expertise
  • Able to onboard someone else (aka onboarding buddy)
  • Knowing which screw to turn
  • Leaving the honeymoon phase: starting to see technical/process/leadership issues

What categories would you add to this list?

Learning is a continuous process. “Onboarded” is not a binary on/off state. You might complete your company’s formal onboarding process, but that has nothing to do with whether you’re really onboarded.

Onboarding is like the sunrise: the darkness slowly gives way to light, but you’re never really sure when that happened. There might be some “aha” moments, like when the sun first peeks over the horizon, but expect this to be a continuous process. You can use your Onboarding Milestones to help you measure your progress.

Thanks to Bucky, Gene, and Jeff for brainstorming the milestone categories with me, to Drew for the sunrise metaphor, and to Anthony for his thorough review of an earlier draft of this post.