Though people often think about the time it takes for a new engineer to start delivering value, they rarely ask themselves how long it takes for them to be fully ramped-up.

Working in many tech organizations, and dealing with tech training, I've had a chance to speak with numerous tech leaders. When I ask team leads and tech leaders “how long is your onboarding process?”, most managers’ first answer is, “it takes a new engineer X days/weeks before they start delivering something”. When asked if that is the end of their onboarding process, they immediately acknowledge that it isn’t.

So what exactly is the definition of a full ‘ramp-up’ for software engineers and why is there such huge variance around this topic?

In the past few months, at our early-stage startup Swimm, we surveyed over 80 engineers and engineering managers from varying company sizes about their onboarding journey. They reported it takes, on average, 3–9 months to fully ramp-up. Let's say, for instance, that you manage to cut the time of full ramp-up in half. This could mean a great deal of extra engineering time for your organization.

This post highlights a crucial step in the onboarding process, often overlooked — Full ramp-up.

The 4 Steps of Onboarding

Let’s talk about where that step fits during an onboarding process. We (at Swimm) like to mark 4 key steps outlined here:

Fully Ramped-Up — The Definition. Imagine a graph that visualizes the value that a new hire creates. It starts off at 0, until the new hires “Starts Delivering Value”. It then grows over time, as the new hire learns new information about the company, the product, the codebase, etc.

At some point, this graph plateaus, as the (not-so-new) hire has learned almost everything there is to know to do the job. Somewhere around the inflection point around this plateau is what we call “Fully Ramped-Up”.

From New Hire to Fully Ramped-Up

In most of the companies we surveyed, engineers and managers reported it takes 3 to 9 months to be fully ramped-up.

There is also a significant percentage of companies where it takes a full year. Imagine what that means for a company where most engineers leave after approximately 2 years. They might have spent half their time being merely partially productive.

Companies in growth mode should make this information actionable. From the moment you find your estimated company ramp-up time, the next step would be to try and decrease it. The rewards can be very significant.

To give a sense of what that could mean, here’s a simplified example: 

Imagine a late-stage startup that is rapidly growing and will hire 100 new engineers in the upcoming year. Let’s assume that in this company it takes around a month before a new hire creates any meaningful value, and 6 months before they are fully ramped-up. If this company manages to cut the time to full ramp-up in half, that would mean around 17 more developer-years in that year! That is millions of $ in salary costs alone, not to mention the impact on development speed.

How Can You Measure Full Ramp-Up Time?

There’s a heated debate about whether one should try to measure how much value software engineers create, and if it’s even possible. Here are a few ways you can make some educated estimates of full ramp-up time:

Survey your team leads and mentors — The people in charge of giving tasks and/or mentoring new hires, usually have a good estimate of the average time it takes for someone to be as independent as they can get.

Map key proficiencies — You can also make a list of all the types of tasks a fully ramped-up engineer should know how to do (you should do this anyway, as it might help you build a better onboarding plan). Then ask yourself how long it usually takes before new hires can do all those things independently.

Guesstimate: Use your gut. Most managers and mentors we talked with could give us an estimated range.

Bringing it Home

Add this to your KPIs. Make “fully-ramped-up” an actionable and viable task. It means changing some perceptions and adding a result-oriented approach to reducing the time it actually takes to complete an onboarding cycle in your company.

Start measuring impact. Want to see how we came up with our numbers? Check out this sheet. Feel free to create your own copy to see what this might mean for your company/team. We also added an equation to calculate how much mentor time you can save.

There are some companies out there that challenged themselves to cut this time. We like this blog post from Zapier detailing how they changed their onboarding process. It’s particularly relevant these days since Zapier is a fully remote company.

Hey, I’m Tom, co-Founder of Swimm, a DevTool we launched after witnessing how engineer onboarding practices could massively affect R&D effectiveness. My background is in Tech, Training and Policy. I hold a Masters in Public Policy from Princeton, an MBA and a B.Sc. in Physics and Math.

Photo source: Doran Erickson, Unsplash.