The embedded integration platform for B2B software companies.
Take a moment and try to put yourself in the shoes of someone who's just landed a job on a development team. You pored over page after page of job postings, looking for the perfect combination of challenging, rewarding, and remotely attainable. You fretted over every last little detail of your resume and cover letter. You spent countless hours brushing up on algorithms and data structures practice questions, determined to be prepared for anything they might throw at you in a technical interview. You made it through round after round of phone screenings, technical interviews, cultural interviews, and executive interviews. Finally, seemingly against all odds, they offered you the job and you quickly accepted before they could change their minds. Congratulations! You are officially The New Person™.
It takes about 7 seconds for the euphoria to fade and some harsh realizations to sink in:
In short, you feel like you have no idea what you're doing. It turns out that being The New Person™ is the worst.
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.
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?
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:
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.
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.
At Prismatic, we've focused quite a bit on two key areas that have helped improve Time to First Commit.
Documentation is by no means glamorous, and if we're honest, nobody really likes writing it or maintaining it. But everyone likes having it around. It's especially helpful if you're The New Person™ and you're just trying to figure out which end is up. At Prismatic, we have gone to great lengths to document as many things as we reasonably can. The nature of the documentation generally falls into one of two categories:
Things that tend to be pretty stable get added to our wiki in Notion. These are things like:
Things that tend to be more fluid get documented in Markdown files and committed to version control alongside the application source code, as in these cases the documentation often depends on the source code. Some examples are:
One of the nice things about having these files committed alongside the source code is that it means the documentation automatically becomes part of the code review process. We consider it a bug if an impactful change is made to the source code but not properly reflected in the documentation.
Things like setting up a new development environment, keeping dependencies updated, and managing application infrastructure changes often boil down to following a series of steps. Well, guess what? It turns out that computers are super good at following a series of steps. So make the computer do the work! The trick of course is describing the steps that they should follow. That's where automation tooling comes in.
We're still a pretty small team at Prismatic, so we knew that investing early on in automation would have tremendous payoff as our team continues to scale and as the application itself continues to grow in both capability and complexity. This has an additional benefit in that it significantly reduces the stress for a New Person™ joining the team, as they can be up and running with a fully configured environment in just a couple hours.
A few of the more impactful examples of automation that we're using at Prismatic are:
Between having comprehensive, up-to-date documentation and automation around most common development tasks, we've been able to get Time to First Commit as quick as a few hours, with everyone thus far easily managing it on their first day. We will continue to pay close attention so that as our systems and processes scale in complexity, as they always seem to, we will keep that first day experience as painless as possible for The New Person™.
Previously published at https://prismatic.io/blog/the-new-person/
Create your free account to unlock your custom reading experience.