developeronboardingcost.com
← The Lab

Metrics

Eight metrics. One onboarding dashboard.

What gets measured improves. These are the metrics engineering leaders already track for DORA, with onboarding-specific framing and benchmarks. Stand up the first three this quarter.

M01

Time to first commit

Days from start date to first PR merged. The single most-tracked onboarding metric. DORA elite teams measure 1-2 days; low performers see 2-4 weeks. Lagging indicator of dev environment friction.

Measure: Git history; first non-revert commit by author email.  |  Tools: Jellyfish, LinearB, Swarmia, internal Git script.

Elite

1-2 days

Low

2-4 weeks

M02

Time to first deploy

First merge to production environment. Highly correlated with platform-engineering investment. Mature golden paths produce day-one production deploys.

Measure: CI/CD logs filtered by author.  |  Tools: GitHub Actions, GitLab CI, internal deploy logs.

Elite

Day 1-3

Low

Month 1+

M03

Time to full velocity

Weeks until story-point output is at 80-90% of team average. The ground truth ramp metric. Sensitive to team size and ceremony quality.

Measure: Sprint velocity divided by team-average velocity.  |  Tools: Jira, Linear, Shortcut, Swarmia.

Elite

6-8 weeks

Low

5-8 months

M04

Ramp-up cost ratio

Total onboarding cost divided by annual salary. Below 25% is healthy; above 35% suggests programme drag or codebase complexity issues.

Measure: Output of the calculator on this site.  |  Tools: Calculator on this site / internal finance spreadsheet.

Elite

15-22%

Low

30-45%

M05

Mentor time consumed

Hours per week of senior engineer time absorbed. Should peak in week two and decline rapidly. Sustained mentor load past week six is a strong signal of programme failure.

Measure: Calendar audits or pair-programming sessions logged.  |  Tools: Loom history, calendar tags, mentor self-report.

Elite

Peaks 8-12 hrs/wk, < 3 hrs by W08

Low

20+ hrs/wk sustained

M06

New hire NPS

Survey score from new hires rating their onboarding experience. Run at Day 30, Day 60, and Day 90. Trends matter more than absolute numbers.

Measure: Post-onboarding survey, 0-10 scale.  |  Tools: Lattice, CultureAmp, Officevibe, Google Form.

Elite

70+

Low

< 30

M07

90-day retention

Percentage of engineers still employed at 90 days. Industry average sits at ~78% (DevPath). Best-in-class programmes report 95%+. The most expensive metric to miss.

Measure: HR system, cohort by start month.  |  Tools: BambooHR, Workday, internal HRIS.

Elite

97%+

Low

70-78%

M08

Sprint velocity recovery

Weeks for surrounding team velocity to return to pre-hire baseline. The team-side cost of onboarding. Hides in 'we are slower this sprint' if not measured.

Measure: Team velocity before vs after new joiner.  |  Tools: Jira velocity reports, Linear analytics.

Elite

2-3 weeks

Low

8+ weeks

Sources

DORA Accelerate State of DevOps 2024-2025, Stack Overflow Developer Survey 2025, daily.dev First-90-Days Playbook, GitHub Octoverse 2025, BCG Software Productivity Index, Brandon Hall Group Onboarding ROI study, DevPath / Zartis early-attrition research, SHRM replacement-cost framework.

FAQ

Common questions

Which one metric should we start with?+

Time to first commit. It is cheap to measure (Git history), already understood by engineering leaders, and tightly correlated with dev-environment quality. Once it is in place, layer on time to first deploy and time to full velocity.

Should we share these with the new hire?+

The team-level metrics, yes. The per-person metrics, sparingly. Time-to-first-commit shared with the new hire on Day 1 builds focus. Sprint velocity recovery shared with the new hire builds anxiety.

How do these relate to DORA metrics?+

Time to first commit and time to first deploy are onboarding-specific instances of the DORA 'lead time for changes' family. Teams already tracking DORA can plug onboarding metrics into the same dashboard with little extra work.

What if 90-day retention is fine but ramp metrics are slow?+

It usually points to codebase complexity or unclear scope. People are staying because the team is good, but they are slow to contribute because the system is complex. Invest in dev environment automation and ADRs.

Updated 2026-04-28