5 exercises — the language of developer onboarding metrics: time to first PR, time to first production deploy, ramp-up period, and friction language.
Key onboarding metrics
Time to first PR — days from start date to first pull request; proxy for setup friction
Time to first production deploy — days until first ship to production; measures pipeline confidence
Ramp-up period — time until developer reaches defined output threshold (e.g. 75% of team median)
Onboarding friction — any barrier slowing new developers: broken scripts, stale docs, unclear ownership
ROI formula — weeks saved × engineers hired = engineer-weeks recovered → £ value
0 / 5 completed
1 / 5
A DX lead presents onboarding improvements to the VP of Engineering: "Before the platform changes, our time to first PR was 11 days. We have reduced it to 3 days." What does "time to first PR" measure, and why is it a valuable onboarding metric?
Time to first PR measures how many days pass between a new hire's start date and their first pull request. It is a powerful onboarding metric because: (1) it is objective and automatically measurable via the version control system; (2) it exposes friction in the setup chain — local environment, access permissions, documentation clarity, toolchain install time; (3) it is a leading indicator of ramp-up velocity — new hires who open a first PR within 3 days onboard 40-60% faster on average (per DX research). A 3-day target requires: working local dev environment in < 1 hour, clear first-task documentation, a good "good first issue" backlog. In presentations: "Reducing time to first PR from 11 days to 3 days means new engineers are contributing 8 days earlier — significant at scale."
2 / 5
An engineering manager explains an onboarding initiative: "We also track time to first production deploy — separate from time to first PR — because shipping to production requires additional access, understanding of the deploy pipeline, and confidence in the process." Why is "time to first production deploy" a different and complementary metric to "time to first PR"?
Time to first production deploy and time to first PR measure different stages of the onboarding journey. A developer might open a first PR on day 3 (good!) but not deploy to production until day 30 because: (1) production access requires a security review; (2) the deploy process is undocumented or complex; (3) they lack confidence and are waiting for a mentor; (4) the staging-to-production promotion workflow is opaque. The gap between the two metrics identifies where the second phase of onboarding friction lives. A healthy pattern: first PR by day 3, first production deploy by day 7-10. A gap of 3+ weeks signals deploy-pipeline documentation or access-provisioning problems. In DX reporting: "Time to first PR is 3 days; time to first production deploy is 28 days — the 25-day gap indicates our production access and deploy documentation needs urgent improvement."
3 / 5
A platform team proposes measuring the ramp-up period as an onboarding KPI. A senior engineer asks: "How do you define when a developer is 'fully ramped up'? That seems subjective." Which definition of ramp-up period is most measurable and defensible in a DX programme?
A ramp-up period is most defensible when defined by measurable output thresholds rather than time or subjective judgement. Option C uses a quantitative benchmark: PR throughput and review participation at 70-80% of team median for two consecutive weeks. This approach: (1) is objective and measurable from existing data; (2) accounts for individual variation — some engineers ramp in 4 weeks, others in 12; (3) identifies stalled ramp-ups early, triggering intervention before 90 days; (4) creates a feedback loop between onboarding investments and their outcomes. Alternative measurable definitions include: "steady deployment frequency for 4 consecutive weeks" or "independent PR review with no escalation for 2 weeks." In DX vocabulary: "We define full ramp-up as reaching 75% of team median PR throughput — our median ramp-up period improved from 11 weeks to 6 weeks after the onboarding programme."
4 / 5
A developer experience researcher identifies patterns in onboarding exit surveys: "The top three sources of onboarding friction reported by new joiners are: (1) broken local setup scripts, (2) outdated documentation, and (3) unclear ownership of who to ask for help." Which metric best captures the aggregate impact of these friction sources?
Time to first PR is the best single aggregating metric for onboarding friction because it is directly downstream of all three cited sources: (1) a broken local setup script prevents the developer from running the project → delays first PR; (2) outdated documentation means the developer cannot follow the setup guide → delays first PR; (3) unclear ownership means the developer spends hours waiting for someone to help unblock them → delays first PR. The metric does not tell you why it is slow (you need exit survey data for that), but it reliably signals that friction exists and quantifies its total cost. This is why time to first PR is the cornerstone onboarding metric: it is objective, automatically measurable, and sensitive to all major friction categories. To diagnose the cause, combine it with qualitative data from onboarding exit surveys or friction logs.
5 / 5
An engineering director presents onboarding improvements to the board: "We hired 20 engineers last quarter. By reducing onboarding friction, we reduced the average ramp-up period from 10 weeks to 6 weeks — a saving of 4 weeks per engineer." Which statement best translates this improvement into a business outcome the board can evaluate?
Option C applies the DX ROI multiplication formula to onboarding: (1) per-person saving: 4 weeks per engineer; (2) team multiplier: × 20 engineers = 80 engineer-weeks; (3) business translation: 80 weeks ≈ 1.5 FTEs for a quarter, valued at £90K (assuming £60K annual salary = £1,125/week × 80). This is the exact framing boards respond to — it converts an HR/DX metric into financial and capacity terms. Option A is a satisfaction score (good supporting data but not board-primary). Option B is an activity metric (documents written) without outcome translation. Option D is anecdotal. The pattern for all onboarding ROI presentations: "N engineers × W weeks saved = total engineer-weeks recovered = £X in engineering capacity, delivered by a programme that cost £Y."