The New Person™: Improving the Developer Onboarding Experience
Tags: Work, Software Development, Developer, DevOps, Startup

Being The New Person™

We’ve all been there. For many of us, probably more than once. It’s just never much fun. Thinking back to my first job out of college, which was many years ago at a small startup company, I remember feeling all these same things. The thing I felt most strongly, however, was that I just wanted to contribute something. Anything! So that I got some sense of accomplishment, certainly, but also to show my teammates that I wasn’t just a waste of space!

These feelings of uncertainty when I was The New Person™ were hardly unique. In fact, many of the developers I’ve worked with and hired over the years have shared with me that they’ve felt these same sorts of negative emotions when they first started, and that they too felt the best way to overcome them was to just get something meaningful accomplished as quickly as possible.

Improving the Onboarding Experience

One of the jobs of being a manager is to ensure that every New Person™ is set up for success to the greatest extent possible. It’s tremendously expensive to find, hire, and retain great talent, so it’s critical that all new employees get started off on the right track. Getting new employees engaged quickly makes it much more likely that they decide to stick around instead of just continuing to job hunt. This is of course a team effort, and it won’t work very well unless you have a good plan for getting the rest of the team involved.

But for the moment, if we’re saying that one of the first things to tackle is to help The New Person™ overcome these negative emotions, and that the best way to do that seems to be to help them accomplish something meaningful quickly, how can we formalize that as part of the onboarding process?

Time to First Commit

Through the years, my teams have had great success with onboarding in part by focusing on a metric called “Time to First Commit”. It’s exactly as it sounds: It’s the time it takes from when The New Person™ first sits down at their desk to the time when they’ve landed their first commit to the version control system. The target you shoot for will probably vary depending on the nature of the application, your languages, frameworks, tools, and probably quite a few other factors. In general, I consider it success if The New Person™ is able to get their first commit in by the end of their first day.

This metric has a couple of properties that make it especially effective:

It’s Comprehensive

Time to First Commit encapsulates many different aspects of the developer experience. In order to commit code, a developer must have a fully configured development machine, security credentials assigned, source code checked out, often a task assigned in whatever issue tracking system you use, and at least some of the organization’s various SDLC polices understood at a basic level. The processes around all of these things must be optimized, at least in part, to account for this metric.

It’s Quantitative

Time to First Commit is a measurable quantity, which means that it’s relatively easy to figure out where your team is at now, what a reasonable target might be, and then steps the team can take to drive towards achieving that goal. It means that as new tools are adopted and processes evolved over time, you can measure whether these things have positively or negatively impacted this metric and take the necessary steps to address any problems. For example, if a developer checks in a change that brings in some new dependency and hasn’t documented how to set it up (or better yet, automated the setup), it’s pretty likely you’ll see a regression in this metric.