Time to proficiency is one of the most consequential metrics in engineering team management, and one of the least rigorously measured. Most engineering organizations have a rough sense that new engineers take "a few months" to get up to speed, and the number lives as tribal knowledge rather than tracked data. This matters because tribal knowledge doesn't tell you whether your onboarding is getting better or worse, whether your L&D investments are working, or where new engineers are losing time in the ramp.
Measuring time-to-proficiency well is harder than it looks, because "proficiency" means something different depending on role, codebase area, and organizational context. This post walks through three approaches — from lightweight to rigorous — and when each one is appropriate.
Why the Measurement Is Harder Than It Sounds
The first challenge is defining the endpoint. Proficiency for a backend engineer joining a payments infrastructure team means something different from proficiency for a frontend engineer joining an early-stage consumer product team. If you're measuring time to a single threshold, you need to define what that threshold is in terms that are objective enough to measure consistently.
The second challenge is that the ramp isn't linear. New engineers often show rapid initial progress — they get their environment set up, complete the onboarding tasks, start making small contributions — and then hit a more complex plateau when they encounter the parts of the codebase that require deep system understanding. If your measurement captures only early progress, you're measuring the easy part of the ramp and missing the part that actually varies based on onboarding quality.
The third challenge is that external factors confound the measurement. A new engineer who onboarded during a major infrastructure migration will have a different ramp than one who onboarded in a stable period, regardless of the quality of the onboarding program. You need enough data points and enough control for confounders to draw meaningful conclusions.
Approach 1: Behavioral Milestone Tracking (Lightweight)
The simplest approach that produces genuinely useful signal is milestone tracking: define three to five behavioral milestones that represent meaningful progress in your specific onboarding context, and track when new engineers reach each one.
Examples of useful milestones in an engineering context:
- Time from start date to first PR merged to production (excludes trivial documentation changes)
- Time from start date to first solo deployment to production
- Time from start date to being added to the on-call rotation
- Time from start date to first PR that requires no significant revision before merge
These milestones have the advantage of being objective — they're recorded events in your existing tooling — and of being meaningful, because they represent real operational capability rather than completion of training modules. A new engineer who has deployed to production solo has demonstrated a level of system understanding that a completion certificate cannot proxy.
The limitation of milestone tracking is that it measures discrete events rather than continuous competency development. It also doesn't tell you what drove the variation — whether a faster ramp reflects a better onboarding program, a more experienced hire, or a simpler codebase area.
Approach 2: Activity Quality Signal (Intermediate)
A richer approach tracks not just when milestones happen, but the quality signal associated with engineering activity over time. The two most useful quality proxies from existing workflow data:
PR review comment density over time. Track the number and category of review comments an engineer receives per PR across their first six months. A healthy ramp shows declining comment density — not because reviewers are less thorough, but because the engineer's code requires less correction. A flat or increasing comment density trajectory suggests the ramp isn't progressing as expected and warrants investigation. Plotting this across a cohort of new engineers lets you see whether the trend is consistent or whether there are outliers that might indicate onboarding gaps.
Escalation rate in incident response. Track how often new engineers escalate during incidents versus resolve independently, as a function of time since hire. As engineers build operational depth, escalation rates should decrease. If they're not decreasing on the expected timeline, that's a signal about where the operational learning is stalling.
This approach requires more analysis than milestone tracking, and it requires connecting data across your version control and incident management systems. But it produces a richer picture of where the ramp is progressing well and where it's stalling.
Approach 3: Role-Normed Competency Assessment (Rigorous)
The most rigorous approach involves building a role-normed competency model for each engineering role and tracking new engineers against it at regular intervals. This means defining the specific technical competencies required for full effectiveness in a given role, establishing what "proficient" looks like for each competency in your specific codebase context, and assessing new engineers against that model at 30, 60, and 90 days.
This is the approach that produces the clearest signal about which specific competency clusters are slowing the ramp. It's also the most resource-intensive to build and maintain. The competency model needs to reflect your actual codebase requirements, not a generic engineering skills taxonomy — which means it needs to be defined by people who understand your specific infrastructure, and it needs to be updated when your infrastructure changes.
For organizations with significant onboarding volume — five or more new engineers per quarter — the investment in a rigorous assessment model pays off in the form of more precisely targeted onboarding investment. For smaller or more stable teams, milestone tracking and activity quality signal may be sufficient.
A Practical Example: Measuring the Impact of an Onboarding Change
Consider a backend platform team that introduced a structured onboarding track focused on their service mesh and observability tooling — historically the two areas where new engineers stalled the longest based on PR review patterns. They measured the cohort that went through the new onboarding track against the prior cohort using three milestone metrics: time to first production deployment, time to first solo on-call shift, and PR review comment density at 90 days.
The results weren't dramatic — this isn't a before-and-after success story — but they were informative. The new cohort showed a moderate improvement in time to first production deployment and a more meaningful improvement in PR review comment density at 90 days, specifically in the observability and service mesh categories. Time to first on-call shift was similar between cohorts. This told the team something specific: the onboarding change had improved code quality ramp but hadn't yet addressed the operational depth needed for on-call readiness. That finding pointed directly at the next iteration of the onboarding program.
That kind of directional feedback is only possible if you're measuring before and after. Organizations that don't measure time-to-proficiency can't improve it systematically, because they have no way to know whether their onboarding changes are working.
What Time-to-Proficiency Measurement Is Not
A word on what this measurement shouldn't be used for: individual performance evaluation. Time-to-proficiency is an organizational metric, not a ranking of new hires. Variation in individual ramp times reflects a mix of factors — prior experience, codebase complexity in their assignment area, quality of their onboarding buddy, hiring class timing — many of which are outside the engineer's control. Using the metric to evaluate individual performance rather than organizational learning effectiveness defeats the purpose and will undermine the trust required to collect honest data.
The useful question is always: what does the distribution tell us about our onboarding program, and where are the gaps that we can address? Not: why did this specific engineer ramp more slowly than average?
Starting Simple
If you're not currently measuring time-to-proficiency in any structured way, milestone tracking is the right starting point. Define three milestones that make sense for your engineering context. Start recording dates when new hires reach them. After two or three cohorts, you'll have enough data to see patterns and decide whether you need a more rigorous approach.
The goal isn't a perfect measurement system. It's having enough signal to know whether your onboarding investments are moving the ramp in the right direction — and where to look when they're not.
