Onboarding: How Long Until a New Hire Ships?

TL;DR: A new hire's ramp speed is mostly a property of your system, not their talent. Time-to-first-PR is the right first milestone because it proves the entire loop from laptop to merge works. But the real ramp curve runs months longer, and what stretches it is always the same three things: knowledge locked in heads, review queues that leave newcomers hanging, and (especially remote) weak social connection to the team. Measure the ramp to debug your onboarding, never to grade the human.

You hired someone great. Six weeks later they're still asking where things live, their second PR is stuck in review, and someone in a leadership sync asks the poisonous question: "is the new hire working out?" Nine times out of ten, that's the wrong question aimed at the wrong target. A slow ramp is your onboarding system performing exactly as built - and the new hire is the only person in the building who can see its flaws, because they're the only one without three years of accumulated workarounds.

What does "productive" actually mean for a new hire?

Teams love time-to-first-PR because it's concrete and it genuinely means something: a merged first PR proves the environment sets up, the codebase is navigable enough to change, and the review process admits outsiders. It's a fine first milestone precisely because it tests the system end to end.

It is not, however, "productive." A day-two typo fix and a week-three real change both count as a first PR while meaning different things. Honest ramp tracking uses a curve of milestones, roughly: first merged PR → first meaningful feature shipped solo → first on-call or incident participation → able to review others' changes in the domain. The gaps between milestones tell you where your system stalls people - a fast first PR followed by a two-month crawl to first feature usually means good scaffolding and a knowledge-silo problem right behind it.

One honesty note, because vendor content is littered with invented benchmarks: there is no credible universal number for "how long onboarding should take." Ramp time varies with codebase size, domain gnarl, and how much knowledge is written down. Measure your own baseline across hires; improve against that.

Why ramps are slow: it's the map, not the hire

Three system failures explain most slow ramps.

The map is in people's heads. A newcomer's job is navigation, and most orgs ship them a codebase with no map. This isn't a newcomer-only tax. In the 2024 Stack Overflow survey, 61% of all professional developers report spending more than 30 minutes a day searching for answers or solutions. Newcomers pay that tax at maximum rate, on every task, without knowing which person to interrupt. Every knowledge silo on your team is a corridor a new hire can't enter without an escort.

The feedback loop ignores them. A first PR that waits days for review is a system telling a newcomer they're not worth interrupting anyone for. It doesn't have to be that way: Google's study of its own review practice (Sadowski et al., ~9M reviewed changes) found an overall median reviewer response under 4 hours, with small changes getting first feedback in under an hour. Newcomers ship small changes almost exclusively - fast review of small changes is functionally an onboarding program, and slow review is functionally a hazing ritual.

The social fabric never forms. When Microsoft studied 267 developers who joined software teams during the pandemic (Rodeghero et al., ICSE-SEIP 2021), most had onboarded remotely without ever meeting their teammates in person, and building a strong social connection with the team stood out among their struggles. That matters mechanically, not sentimentally: a newcomer who doesn't feel safe asking "dumb" questions asks fewer of them, and every unasked question is a day of searching. The paper's recommendations center on deliberately engineering that connection instead of hoping it happens.

What actually speeds up the ramp

• A paved road to the first PR. A documented, tested dev-environment setup and a curated list of genuinely useful starter tasks. If setup takes three days of tribal knowledge, day one of onboarding is actually day four.
• Review-priority for newcomers. Explicit team agreement: new-hire PRs get picked up fast. Small changes reviewed quickly is the cheapest mentoring your seniors can do, and it compounds daily.
• An onboarding buddy with real time carved out. One named person whose job includes the questions, which converts the social-connection problem from luck into process. Remote teams need this doubly, per the Microsoft findings above.
• Docs where the churn is. Don't write the encyclopedia; document the five paths every newcomer walks: setup, deploy, the core domain model, how to find owners, how on-call works. Short, close to the code, maintained.
• Route newcomers through silo territory deliberately: real tasks in single-owner areas with the expert reviewing. This spreads knowledge in both directions and chips at your key-person risk while the newcomer ramps: the same rotation that teaches them de-silos you.

Measure the system, not the newbie

Track milestones across all hires (time-to-first-PR, time-to-first-feature, time-to-first on-call) and read them as a diagnosis of your onboarding, in the spirit of the SPACE framework's warning that no single activity count judges a human. Consistent slow spots across different hires are system bugs; treating them as performance verdicts on individuals just teaches new people to optimize for optics in their most vulnerable months.

If you are living the expensive half of this right now - a senior hire weeks in with nothing real merged - the pain-side read is your new senior hire hasn't shipped anything real yet.

Ramp speed is one of the clearest windows into overall engineering team health: it integrates your documentation, your review responsiveness, your knowledge distribution, and your team's social fabric into one observable curve. The door: pull the last four ramp curves from your own history - start date to first merged PR to first shipped feature. Find the longest gap. That gap is your onboarding system's slowest component, it will still be there for the next hire, and unlike the hire, it's entirely yours to fix.