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  “ ?”, 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. how long is your onboarding process 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 from varying company sizes about their onboarding journey. 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. , we surveyed over 80 engineers and engineering managers They reported it takes, on average, 3–9 months 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 outlined here 4 key steps : — The Definition. Imagine a graph that visualizes the value that a new hire creates. It then grows over time, as the new hire learns new information about the company, the product, the codebase, etc. Fully Ramped-Up It starts off at 0, until the new hires “Starts Delivering Value”. At some point, this graph plateaus, as the (not-so-new) hire has learned everything there is to know to do the job. Somewhere around the inflection point around this plateau is what we call “Fully Ramped-Up”. almost 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. 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. Companies in growth mode should make this information actionable. 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 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: heated debate — 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. Survey your team leads and mentors — 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. Map key proficiencies : Use your gut. Most managers and mentors we talked with could give us an estimated range. Guesstimate Bringing it Home . 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. Add this to your KPIs . Want to see how we came up with our numbers? Check out this . 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. Start measuring impact sheet We like detailing how they changed their onboarding process. It’s particularly relevant these days since Zapier is a fully remote company. There are some companies out there that challenged themselves to cut this time. this blog post from Zapier 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. : , Unsplash. Photo source Doran Erickson

Engineer Onboarding: The Ugly Truth About Ramp-Up Time

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

What Whiplash Teaches Us About the "Sink or Swim" Method in Engineering

The HackerNoon Newsletter: The Road to Hell is Paved with Good DRY Intentions (10/31/2025)

Simple, Battle-Tested Algorithms Still Outperform AI

The Road to Hell is Paved with Good DRY Intentions

The MVP Engineering Playbook: Ship a Useful 0→1 in 6 Weeks

What Whiplash Teaches Us About the "Sink or Swim" Method in Engineering

The HackerNoon Newsletter: The Road to Hell is Paved with Good DRY Intentions (10/31/2025)

Simple, Battle-Tested Algorithms Still Outperform AI

The Road to Hell is Paved with Good DRY Intentions

The MVP Engineering Playbook: Ship a Useful 0→1 in 6 Weeks

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps