The honest answer to "how long until a new engineer ships something to production?" is almost always longer than the hiring manager told the candidate, longer than the CTO reported to the board, and longer than it needs to be. I've tracked this number across more than thirty engineering organisations. The median is not flattering.
Most companies don't publish these numbers. Not because they're secret — because they've never measured them.
Why Nobody Publishes These Numbers
Onboarding metrics are uncomfortable in the same way technical debt metrics are uncomfortable: measuring them makes the problem visible, and visible problems invite accountability. So most organisations default to qualitative feedback — "how was your onboarding experience?" — and take the 7/10 average score as evidence that things are basically fine.
They are usually not fine. They are usually slow, inconsistent, and expensive — and because every new engineer goes through it only once, there's no internal accumulation of frustration that forces a fix. The engineer adapts. The bad process persists.
I track four specific onboarding metrics now across every engagement:
| Metric | What It Measures | Why It Matters |
|---|---|---|
| Time-to-first-commit (T1C) | Days from start date to first code merged to any branch | Local dev environment, access, tooling friction |
| Time-to-first-production-deploy (T1P) | Days from start date to first change reaching production | Pipeline clarity, deployment process, pairing culture |
| Time-to-full-autonomy (T1A) | Weeks until the engineer needs minimal guidance on task selection | Codebase documentation, architectural legibility |
| Onboarding completion rate | % of day-1 checklist completed within first week | Documentation currency, runbook quality |
The Benchmarks, Honestly
These numbers come from structured assessments across companies ranging from 15 to 350 engineers, mostly in Europe, spanning SaaS, fintech, insurtech, and enterprise software. They are not survey averages — they are measured data or CTO-reported data from organisations where I've been in the building.
Time-to-first-commit:
- Bottom quartile: more than 30 days
- Median: 16–20 days
- Top quartile: 3–5 days
- Best I've seen: same-day commit on day 1 (with a fully automated dev environment and a pre-selected good-first-issue)
Time-to-first-production-deploy:
- Bottom quartile: more than 70 days
- Median: 40–50 days
- Top quartile: 10–14 days
- Best I've seen: 4 days (a team that pairs new hires with a senior for their first week and deploys their first change together on day 4)
The range is extraordinary. The gap between a top-quartile team and a bottom-quartile team on time-to-production is more than 50 working days. At a fully-loaded cost of €700–900 per day for a mid-senior engineer in a German or Dutch market, the bottom-quartile team is spending €35,000–45,000 per hire before that engineer contributes anything to production.
The compounding effect nobody calculates
The direct cost is just the salary burn. The indirect cost is what that engineer's early frustration does to their perception of the organisation. Engineers who take more than 30 days to ship their first change are significantly more likely to report low confidence in the codebase, low trust in the team's processes, and reduced intention to stay beyond 18 months. Slow onboarding is a retention risk, not just an efficiency problem.
What Slow Onboarding Is Actually Telling You
A long time-to-first-commit is a diagnostic signal, not a standalone problem. It's almost always caused by one or more of the following:
Local development environment is fragile or undocumented
The most common cause. The engineer receives a README that was last updated 14 months ago, references three tools that have since been replaced, and assumes a global dependency that isn't installed on any machine purchased in the last two years. The new hire spends two weeks building the environment that should have taken two hours.
I've walked into organisations where the onboarding README had a "known issues" section longer than the setup instructions. That section is not a helpful disclosure. It is evidence that the documentation has been abandoned.
Access provisioning takes too long
GitHub access, cloud environment access, internal tool access, VPN certificates — in poorly-administered organisations, each of these involves a separate request to a separate person or team, with no SLA and no clear owner. I've seen engineers wait 10 days for a cloud environment that could have been provisioned in 20 minutes if there were a runbook for it.
The fix is almost always simple: a pre-provisioned access bundle that fires automatically on a confirmed start date, owned by engineering operations (or whoever owns the engineering management system), with a 24-hour SLA.
No designated "good first issue" practice
The engineer arrives, gets oriented for a day, and is then pointed at the backlog and told to "pick something up." The backlog was written for engineers who already know the system. Nothing is labelled for context, bounded in scope, or pre-reviewed for suitability as an entry point. The engineer either picks something too large and gets stuck, or picks something too small and feels patronised.
High-performing teams maintain a small backlog — usually 3–5 items — of specifically curated good-first-issues. These are sized for one engineer in under a week, touch a meaningful part of the system, and come with an explicit description of what "done" looks like.
The CI/CD pipeline is too opaque
Even after local setup, the path to production is unclear. Engineers don't know the branching convention, the review expectations, the deployment trigger mechanism, or what a passing pipeline actually looks like. The result is friction at every step — not because the engineer is slow, but because the system wasn't designed to be legible to someone new.
What the Best Teams Do
The teams in the top quartile on T1C and T1P share a small number of practices. They are not expensive. They are discipline, not infrastructure.
A single command — one script, one make dev, one docker compose up — that produces a working local development environment against a representative data set. Tested monthly. Owned by the platform or developer experience function. Not aspirational; actually tested by someone on their own clean machine.
All access — source control, cloud environment (read-only production, full dev), internal tooling, documentation — is provisioned before the engineer arrives. The IT/engineering ops runbook for this is one page. The trigger is a confirmed start date in the HRIS system.
A specific senior or mid-senior engineer is assigned as onboarding buddy for the first two weeks. Not a manager. An engineer who can pair on the first task, answer "where does this live?" questions in real time, and give honest feedback on what the new hire should prioritise.
The onboarding buddy pre-selects a good-first-issue before the engineer starts. The issue is bounded, meaningful, touches real production code, and has a clear definition of done. The goal is a merged pull request by the end of week 1.
The new engineer deploys their first change to production with the onboarding buddy alongside. The buddy narrates the deployment process, explains the monitoring expectations, and debriefs afterward. The T1P clock stops here. This is not a ceremony — it is a transfer of operational competence.
The onboarding journey from day one to first production deploy moves through five distinct stages:
The Business Case for Fixing This
Let me be concrete about the return. A 30-engineer team that hires 10 engineers per year and reduces T1P from 45 days to 12 days saves approximately 330 engineering days per year. At €750/day fully loaded, that's roughly €247,000 in recovered productivity. The investment to get there is typically one engineering sprint's worth of work: updating the onboarding documentation, scripting the environment setup, and establishing the good-first-issue practice.
The ratio is absurd. Most engineering productivity investments return 1.2–2x. This returns 5–10x in the first year.
| Scenario | T1P | Engineers Hired/Year | Productivity Lost | Annual Cost |
|---|---|---|---|---|
| Bottom quartile | 70 days | 10 | 700 days | ~€525k |
| Median | 45 days | 10 | 450 days | ~€337k |
| Top quartile | 12 days | 10 | 120 days | ~€90k |
| Improvement (median to top) | -33 days | 10 | -330 days | ~€247k saved |
These numbers assume nothing about quality of work. They're purely about the time before a hire contributes anything to production. The quality case for faster onboarding — higher engineer confidence, better early retention, faster feedback on cultural fit — is on top of this.
The metric you're probably not tracking
If you cannot tell me your organisation's current T1C and T1P within 20% accuracy, you are probably in the bottom half of the distribution. The act of measuring these numbers, even imprecisely, is the first step toward improving them. Teams that track T1P reduce it by an average of 40% within two quarters — not because tracking causes improvement, but because what gets measured gets owned.
How to Start This Week
You don't need a new platform or a new engineering operations hire. You need three things:
First: Ask your last five hires when they made their first commit and their first production deploy. Write those numbers down. You now have a baseline.
Second: Have someone new sit with the onboarding documentation and try to follow it. Don't help them. Watch where they get stuck. Those are your top priorities.
Third: Assign one engineer to own the onboarding runbook. One person. A specific person. With a target: T1P under 14 days for the next three hires.
That's the whole plan for month one. Everything else is iteration on top of a baseline you now actually have.
The organisations that do this work find that onboarding improvement also surfaces other structural weaknesses — undocumented systems, access management debt, unclear deployment conventions — that were invisible until someone had to explain them to a newcomer. The new hire is not just a productivity unit. They are a diagnostic instrument. Use them as one.
If you want to benchmark your engineering organisation against real data — including onboarding metrics, delivery performance, and developer experience — let's talk. I run structured engineering assessments as part of digital transformation engagements. Book a 30-minute discovery call and we can establish where you actually stand.