The Onboarding Metrics Nobody Tracks (But Should)

Most engineering teams measure onboarding by feel. "How's the new hire settling in?" Good vibes at the two-week check-in. A thumbs-up on Slack.

This is how teams miss that their onboarding is broken — because the signal is polite conversation, not data.

The engineers who join your team are trying to make a good impression. They're not going to tell their manager on day four that the setup docs are three years out of date and the dev environment crashes on macOS Sequoia. They'll figure it out, ask around quietly, and absorb the friction as "how things work here."

By the time you find out something was hard, the person who struggled is fully onboarded and the next hire will hit the same wall.

Three metrics worth tracking

1. Time to first PR (T1PR)

From their first day to their first merged pull request. Not a big PR. Any PR. Even a docs fix counts.

A new engineer who makes their first PR within 48 hours has a fundamentally different onboarding experience than one who takes two weeks. The first PR is the threshold between "observer" and "contributor." Crossing it early builds confidence, surfaces blockers, and gets the engineer into your team's actual workflow.

Target: under 3 days for most teams. Under 1 day if you can get there.

If you're averaging 5+ days, the blocker is usually one of: setup problems, unclear "good first task" supply, or too much ceremony required before code can be submitted.

2. Time to first production deploy (T1D)

From their first day to their first change in production. This includes getting deploy access, understanding the deploy process, and actually shipping something — however small.

This metric matters because production access is a forcing function. It requires credentials, permissions, familiarity with your deploy pipeline, and understanding of what's safe to change. Teams with tangled deploy processes see this metric balloon, which tells you exactly where the friction is.

Target: under 2 weeks for most teams. Under 1 week if you have a healthy CI/CD culture.

3. Time to unblocked (T1U)

This one is qualitative but still trackable: ask new engineers at their 30-day mark, "When did you feel like you could build things without needing help for every step?" Record the number of days. Average across hires.

This is the metric that captures what the other two don't — the difference between mechanically completing tasks and being genuinely productive. Some engineers can ship a PR in day two but feel completely dependent for their first three weeks. Others take longer to get the first PR in but ramp quickly once they're set up.

T1U above 30 days is a red flag. Above 60 days means your codebase or team culture is actively slowing people down.

Why teams don't measure this

The data is there — nobody collects it. Your GitHub history has every engineer's first commit and first merged PR. Your deploy logs have their first production deploy. None of this requires new tooling. It requires someone caring enough to look.

Onboarding is seen as HR's problem. The first week has buddy programs and culture sessions and company all-hands. Technical onboarding is assumed to happen on its own. But technical onboarding is an engineering problem, not an HR problem.

New hires absorb blame for slow starts. "They're still figuring things out" is the explanation. Sometimes true. But when every new hire takes three weeks to feel productive and the one who came from a company with better DX ramped in ten days, the problem isn't the people.

Nobody has an ownership stake in the number. Metrics improve when someone is accountable for them. If no team or person owns "time to first PR," it won't improve even if it's terrible.

What good onboarding looks like structurally

A curated first week. Not a reading list. A sequence: on day one you run setup, on day two you fix this specific small bug, on day three you review a PR from the backlog, on day four you pair with your assigned buddy on a real ticket. Structured, not freeform.

An honest "first tasks" queue. A label or board column of issues that are actually good for someone who is new. Not the tickets labeled "good first issue" that turned out to require six months of context. Real tasks that can be done in a day or two with the documentation available.

A setup document that's been tested in the last 90 days. Whoever onboarded most recently should have added any missing steps. If the last onboarding was a year ago, the docs are wrong. Run them yourself on a fresh machine to find out how wrong.

Access provisioned before day one. GitHub org, AWS/GCP console, Datadog, Sentry, Slack channels, password manager, deploy permissions — all of this should exist on day one, not "we'll get to it later." Access delays are the single most common cause of slow T1D.

An explicit "you are not blocked, ping me" person. Not just a buddy, but someone whose explicit job for the first two weeks is to unblock the new hire within the hour. Not "feel free to ask questions." Specifically assigned, specifically responsible.

The 30-day retrospective

At 30 days, have a structured 30-minute conversation with every new engineer:

1. What took longer than it should have?
2. What was missing from the docs?
3. What surprised you?
4. What would have helped most on day one?

Write down the answers. Fix the top three. This conversation, done consistently, is how your onboarding gets better over time without a dedicated headcount to maintain it.

The compounding return

Good onboarding is one of the highest-ROI engineering investments a team can make. A new hire who's productive in 10 days instead of 30 has effectively recovered 20 engineer-days on a 12-month contract. That's a feature. That's weeks of runway at a startup.

More importantly: engineers who onboard fast feel capable early. Engineers who feel capable stick around. The correlation between a strong first 30 days and 12-month retention is real.

Track the numbers. Own the numbers. Fix the numbers. Everything else is just hoping.