January 18, 2022
MTTR; Deployment Frequency; Cycle Time: no one reading this post would be surprised to hear these are all important metrics for engineering leaders and team leads to continuously track and find ways to improve. But one of the most overlooked, and possibly one of the most impactful metrics to the success of an engineering team is engineering ramp time. For growing companies, engineering ramp time is so important because it has an outsized influence on your team’s delivery speed, capacity for work, and budget plan moving forward. Let me elaborate…
Engineering ramp time is the time it takes from when a software engineer starts a new job to when that person can consistently deliver the expected value and/or output of that position. It’s important to distinguish this from onboarding time, which is how long it takes an engineer to go through the onboarding process and start to deliver any value at all. The key difference is that over the course of [usually] months between when they first deliver value and when they are fully ramped, that new engineer will grow more and more productive, delivering value faster and taking on larger, more meaningful projects. That requires a great deal of knowledge about the company, the codebase, the product, the customers, etc., and it takes time.
Generally, a software engineer takes months to fully ramp, and often that can be upwards of 6 months or more. That’s meaningful time when you’re trying to grow a business! And it’s a meaningful difference from the 3-4 weeks you might expect an engineer to onboard and start delivering value. But why measure ramp time instead of using a handwave of a number to guesstimate work? The simple answer is two-fold: planning and improvement.
The capacity of your team can be highly dependent on the amount of time it takes new engineers to ramp, especially for teams in growth mode. As we’ve pointed out in our 10 KPIs Engineering Leaders Should Track, “if you’ve linked hiring to the ability to build and deliver a new product or feature (and most of us do), it’s important to know approximately how long to expect new hires will still need to ramp after hiring is done. Bake this into your assumptions during product and roadmap conversations, for operational planning sessions, and as you plan throughout the year.”
The other consideration for measuring ramp time is improvement – you can’t improve what you don’t measure. Small changes to your average ramp time can have huge implications on your team’s performance and on your bottom line! Let’s use a fabricated example. Say I work for a growth stage company who’s trying to hire 62 engineers this year (can’t imagine who I’m talking about right now). If my company could shave just one month off the time it takes an engineer to fully ramp, it would add 5 developer-years to it’s engineering power this year alone! Just think of the impact on development 5 additional [fully ramped] engineers could have on this team. And I bet your CFO would be interested in what that means for next year’s budget…
How to measure ramp time is a debate unto itself. A good place to start might be to benchmark operational metrics of fully ramped engineers across roles and responsibilities, and measure new engineers against those benchmarks. Of course operational metrics like coding day, issues resolved, or PR cycle time don’t tell the whole story, and every organization needs to define for itself what constitutes a fully ramped engineer. But doing the hard work to codify that definition, and making ramp time a KPI for you to measure will clearly pay dividends for your organization and your business.
