Your New Senior Hire Hasn't Shipped Anything Real Yet

TL;DR: You hired a senior engineer to move the needle. Five weeks of full salary later, their biggest merged change is a config tweak, and the org's word for that is "ramping" - a word that means a number nobody tracks. Time to first PR is where the measurement starts; the tenth merged PR is where it gets honest. And when you finally measure it, the blocker is rarely the hire: it's the areas of your codebase that can't be entered without one specific person. Measure the ramp, find the gate areas, fix the docs and ownership that lock them.

Week five. The staff engineer you fought a whole hiring cycle for, the one who shipped serious systems at their last three jobs, has merged a dependency bump, a README fix, and a change to a test helper. In standup they say "still getting my bearings in the billing code," and everyone nods, because everyone said the same sentence in their own first month. That nod is the problem. "Ramp-up" is the only budget line in your company that has no number attached, no owner, and no review - it's just a season, like weather.

Ask the two questions nobody in that standup can answer: how long does it usually take a hire here to land something real, and what exactly is this one waiting on? If the answers are "no idea" and "the billing code is kind of Petra's thing" - congratulations, you've found both the metric and the root cause in one breath.

You're paying full price for the not-shipping

The cost is invisible only because it's never itemized. A senior engineer's cost isn't their salary. Benefits, equipment, employer taxes and space put a fully loaded employee at roughly 1.25 to 1.4 times base in Hadzima's classic MIT analysis, and the fully loaded cost of an engineer is the honest multiplier for every month of anyone's time. Every week of ramp is a week of that number spent on navigation instead of shipping.

Some of that spend is legitimate: nobody ships real change in a codebase they can't yet read, and a rushed ramp produces confident damage, not value. The dysfunction isn't that the ramp costs money. It's that the cost is unmeasured, so it never competes for attention with things that are: the org that tracks its CI bill down to the cent will burn a month of loaded senior salary on "getting bearings" every single hire, forever, because no dashboard ever showed the burn. You won't find a folklore benchmark here for what onboarding "should" cost. There isn't a citable one. Your own last four hires are the benchmark, and pulling their dates takes an afternoon.

Measure time to first PR, then keep counting to ten

Time to first PR - start date to first merged pull request - is the right place to start because it tests the whole system end to end: environment setup, codebase navigability, review process. Your git history already holds it for every hire you've ever made, which makes it the rare metric with free historical baselines.

It's also easy to flatter. A day-two typo fix and a week-three real change both count, which is why the honest ramp curve keeps counting: first merged PR to tenth merged PR. Ten is past the starter-task supply. Nobody reaches ten merged PRs on curated onboarding tickets. By ten, the person is finding work, entering areas, and surviving review at a working rhythm. That later gap is where onboarding systems actually stall people, and it's the part "time to first PR" alone never sees: the hire who merges something in week one and then takes two more months to reach ten has a map problem, not a talent problem. The broader time-to-productivity picture runs on the same logic: milestones as a curve, read as a diagnosis of the system, never a grade on the person.

The areas nobody enters without an escort

Now the root cause. When you segment the ramp by where the hire's changes landed, most orgs find the same shape: newcomers ship freely in two or three well-trodden areas and go silent everywhere else. The silent areas aren't harder - they're gated. The setup steps live in someone's shell history, the documentation is a museum, and there is exactly one person who can competently review a change there, so every newcomer PR into that area waits in one calendar. Knowledge silos don't just create departure risk. They set the speed limit on every ramp you'll ever run. This is measurably common: Avelino et al. found 34% of 133 studied systems had a truck factor of exactly 1, codebases full of areas one exit away from orphanhood, which are precisely the areas a new hire can't enter unescorted.

Two more gates compound it. Review responsiveness: newcomers ship small changes almost exclusively, and Google's study of ~9 million reviewed changes shows small changes can get first feedback in under an hour. A first PR that waits three days is a choice your system is making, and a review queue piled in front of one person is usually the mechanism. And the question tax: in the 2024 Stack Overflow survey, 61% of professional developers report spending over 30 minutes a day searching for answers. Newcomers pay that tax at the maximum rate, and pay it silently if the social fabric isn't there to ask through, which Microsoft's remote-onboarding research flagged as the struggle that shapes everything else. A slow ramp is team health summarized in one number: it integrates your docs, your review queue, your knowledge distribution, and your team's willingness to be interrupted.

The free diagnosis: four hires, three timestamps

1. Pull the ramp for your last four hires. Start date → first merged PR → tenth merged PR. Two gaps per hire. An afternoon with your git host's API, or honestly a spreadsheet.
2. Find the consistent stall. Fast-first-PR-then-crawl means good starter scaffolding and gated areas behind it. Slow-first-PR means setup and review-queue problems. Same stall across different hires = system bug, not a hiring miss.
3. Map where their changes landed. List the areas no newcomer has entered in a year. For each: who's the only competent reviewer? That's your gate list, and it doubles as your cost-of-losing-them exposure, because the area a newcomer can't enter is the area that orphans on resignation day.
4. Ask the newest hire what they avoided and why. They're the only person in the building who can still see the onboarding system's flaws; everyone else routed around them years ago and forgot.
5. Fix the gates, not the hire. Docs on the five paths every newcomer walks. Explicit review-priority for newcomer PRs. And route the next newcomer through gated territory deliberately, with the expert reviewing: the same rotation that ramps them de-silos you.

How you'd actually see this in Busfactor

The afternoon of spreadsheet archaeology is exactly the ritual that happens once and never again, while every future hire ramps unmeasured. Busfactor computes the ramp continuously from your git history: onboarding p50 - the median days from a joiner's start in your history to their tenth merged PR - sits in the judged stat grid with a healthy/watch/bad verdict, not a raw number you have to interpret. It's built to be honest about samples: only people who joined after your observed history starts count as joiners, and it won't say anything until at least three of them have reached ten merged PRs. When the ramp is slow it fires a finding with both readings stated, ramp friction (docs, setup, review gatekeeping) or newcomers being handed properly hard work, because a long ramp isn't automatically a broken one. And it praises what improves: if your two newest joiners ramp measurably faster than the house baseline, the report says someone fixed onboarding and nobody noticed. The gate areas, meanwhile, are what the knowledge map draws org-wide: which areas have exactly one competent owner - the corridors your newcomers can't walk without an escort.

The honest limits: Busfactor reads git, not your HR system. "Start" is the person's first appearance in the data, and the metric can't see pairing sessions, whiteboard time, or the week spent on a design doc that never touched a branch. Ten merged PRs is a proxy for "operating," not a definition of value. The measurement tells you where hires stall and which areas gate them; whether a particular ramp was slow or just deep is a judgment the receipts hand back to you.

The door

Pull the last four ramp curves this week - start, first merged PR, tenth. One gap will be embarrassing, it will be the same gap for every hire, and it is entirely yours to fix: usually one undocumented setup path, one review queue, and two areas with a single gatekeeper. Fix those before the next start date and you've bought every future hire weeks of shipping you're currently paying for as weather. If you'd rather the curve watch itself, and see which areas are un-enterable before the recruiter does, get your org's free read.