Hiring and getting people up to speed in a high-growth organization can be an intimidating experience. It can be easy to focus all our efforts on finding the right people — only to overlook the activities needed to help teammates get up to speed once they’ve joined.

When a customer brings up the topic of onboarding with us, it’s typically because they’re facing their next wave of hiring and want to use data to help accommodate that growth. Specifically, there are usually two overarching goals they want to achieve:

• Use data to provide clear expectations around onboarding milestones (setting a pace for when they expect people to be fully ramped up within their team), and
• Use data to provide actionable and attainable targets for new employees to achieve.

In practice, most managers tend to create a 30/60/90-day plan or something similar to it. It’s useful to think about what it means to be a fully contributing member of the team and work back from that — where each milestone has clearly articulated expectations around the activities and behaviors a team member should be exhibiting at that time.

The onboarding timeframe, distinct phases, and how check-ins are conducted with new hires will vary depending on the company’s values and what they have experienced with their onboarding process historically. But despite the variance, there are two intended outcomes of the onboarding process that most organizations share:

• We want the new team member to create solutions and contribute to the codebase, and
• We want them to collaborate with their colleagues and together produce even greater work.

Both of these concepts are simple, they’re easy for new employees who are in an unfamiliar environment to understand, and they’re easy to track. Today we’ll focus on three metrics that provide visibility into the onboarding process: Active Days per Week, Pull Request Involvement,and Unreviewed PRs.

Active Days per Week

Active Days per Week is any day where a developer contributed code to a project.

There are many different forms of engineering work: exploring solutions, writing code, reviewing others’ work, discussing specs and architecture — and for new hires, who are essentially starting with a blank slate, there’s a lot to learn about the code, team, and organization in order to be successful in what they were hired to do.

So the intuition behind Active Days per Week is simple: are new hires getting what the resources they need to start contributing to projects? And then, with time, are they getting comfortable with taking on more significant tasks?

Within GitPrime, you can use the Player Card report to visualize an engineer’s Active Days per Week over the specified time period. Within that same report, you’ll also be able to see the broader scope of someone’s day and how they’re participating in the code review process.

The important thing is that by day 90, your new hire is integrated in the code and while they don’t know everything, they know where to look. This should allow them to take on most tasks that you’d ask of someone with their experience level.”

Mike OliverVP of Engineering at Runkeeper

Involvement in the code review process

Involvement is the percentage of Pull Requests that the Reviewer(s) participated in. It’s a very context-dependent measure; if you’re looking at Involvement within a small team, an individual may show 60% Involvement, indicating that they provided a comment or approval on three out of the 5 PRs opened on that team. But if you zoom out to view the whole organization, that same individual’s level of Involvement will be much lower since they aren’t participating in many of the PRs outside their team.

We want to ensure that new employees are engaging in code review both as a Reviewer and a Submitter. We want to see team members giving and receiving feedback, sharing information and learning about the codebase, and starting to develop an area of expertise about the product.”

We want to take Involvement with the context of the team or organization’s average. If the team that this new hire joins has an average of 20% Involvement, you may want to see the individual ramp up to 10% within six months of starting. You could then walk that back and set incremental goals: by day 14, you’d like to see 1% Involvement. By day 30, 2%. In the first 60 days you want to see it at 5%, and closer to 10% at the 90-day mark.

Unreviewed PRs

Unreviewed PRs is a percentage of pull requests that didn’t get any reviews before being merged. Teams generally want to ensure their new hires are getting plenty of review on their PRs. They want to ensure that the code the new hires are writing is safe and meets their standards — but they also want to make sure that new employees are getting feedback from their peers and learning about the code.

In an ideal world, PRs are never merged without being reviewed — even when they’re relatively small in size or made by more senior developers. Many organizations establish a policy and configure their system to programmatically reject unreviewed PRs. In practice, the goal is to drive the percentage of Unreviewed PRs down to zero or close to it.

We want to make sure that new engineers are submitting pull requests and participating in the review process, because one of the best ways to get people up to speed with a new codebase is to look at what other people are doing, and to have more experienced people give you feedback.”

Aaron SilvermanEngineering Leader at Storyblocks

Measuring the onboarding process

To get an understanding of how long it normally takes someone to get up to speed in your organization, look back at the team’s historical data (specifically Active Days per Week, PR Involvement, and Unreviewed PRs) and see how long it took for your existing team members to ramp up. Get a range of timeframes and build your expectations around those historical averages.

Then, be flexible and iterate on the process. When expectations aren’t met, stay curious and look to understand why — maybe there was a blocker or confusion around a specific project or way of working. Take those experiences into account and improve the process for future hires.

By leveraging these reports within GitPrime, you can establish objective milestones or progression paths that help your managers understand whether they are providing their new employees with the resources they need to successfully get up to speed.