Five Engineering Metrics That Actually Matter in 2026

In this deep dive, I surveyed 120 engineering leaders at companies ranging from Series A startups with 8 engineers to public tech companies with thousands — and asked them a deceptively simple question: which metrics actually changed how you run your team? Not which metrics you report to the board. Not which metrics appear on your VP's dashboard. Which ones, when they moved in the wrong direction, caused you to stop a sprint, restructure a team, or kill a project?

The answers surprised me. DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — came up in nearly every conversation. But nobody treated them as differentiators anymore. "DORA is table stakes in 2026," one VP of Engineering at a $2B fintech told me. "Every team I interview candidates from claims four deploys per day. The question is what they measure *after* DORA."

What separated the top quartile of teams from everyone else wasn't more metrics. It was five specific metrics they tracked with religious consistency — and a long list of metrics they'd deliberately stopped measuring because the gaming was worse than the signal.

Today, we cover:

• Why DORA metrics are necessary but no longer sufficient
• The five metrics that separated top-quartile teams in our survey
• How each metric is measured, what good looks like, and common failure modes
• The metrics high-performing teams explicitly stopped tracking — and why
• How to implement these metrics without creating dashboard theater
• Benchmarks by company stage from our survey data

---

1. Beyond DORA: The Metrics Maturity Gap

The DORA research program, born at Google and popularized through the State of DevOps reports, gave engineering leadership a shared vocabulary. Before DORA, "we're doing well" meant different things to different teams. After DORA, you could compare deployment frequency and change failure rate across organizations.

But here's the problem with shared vocabulary: once everyone adopts it, it stops being a differentiator.

I analyzed survey responses from 120 engineering leaders collected between March and June 2026. The pattern was clear:

• 91% track deployment frequency
• 87% track lead time for changes
• 84% track change failure rate
• 79% track time to restore service (MTTR)

These numbers are up dramatically from 2022, when roughly half of mid-size companies tracked DORA metrics consistently. The industry matured. Good.

But when I asked leaders to rank which metrics *predicted* team performance — measured by a composite of developer satisfaction scores, roadmap delivery rate, and incident frequency — DORA metrics ranked fifth through eighth. The five metrics that ranked highest weren't on most dashboards at all.

"We hit four DORA metrics on green for two quarters while our best engineers were updating their LinkedIn profiles. Deployment frequency told us we were shipping. It didn't tell us we were shipping the right things, or that our on-call load wasn't burning people out." — VP Engineering, Series C SaaS (180 engineers)

The insight isn't that DORA is wrong. It's that DORA measures delivery system health — and delivery system health is necessary but insufficient for organizational performance. The teams that win in 2026 measure delivery *and* operational sustainability *and* developer experience with equal rigor.

---

2. Metric #1: Time to Restore Service (Including Detection Time)

Every team tracks MTTR. Almost nobody tracks time to detect as a first-class metric — and that omission hides the most actionable information on the dashboard.

How top teams measure it:

``` Total Time to Restore = Time to Detect + Time to Diagnose + Time to Fix + Time to Verify ```

Each component is tracked separately. When MTTR spikes, the decomposition immediately tells you whether to invest in monitoring (detection), runbooks (diagnosis), code quality (fix), or deployment pipeline speed (verify).

What good looks like:

Component	Top Quartile	Median	Bottom Quartile
Time to detect	< 5 min	18 min	> 45 min
Time to diagnose	< 15 min	42 min	> 90 min
Time to fix	< 30 min	65 min	> 180 min
Time to verify	< 10 min	25 min	> 60 min
Total MTTR	< 60 min	150 min	> 360 min

Survey data from 120 teams, normalized to SEV-2 incidents (customer-visible but not catastrophic).

The detection gap is where the leverage lives. Teams that alert within 5 minutes recover 3.1x faster overall — not because they fix things faster, but because they start the clock earlier. A team with a 30-minute fix time but 45-minute detection has worse effective MTTR than a team with a 60-minute fix time and 3-minute detection.

Common failure modes:

• Measuring MTTR from the first customer report instead of from incident start time
• Bundling detection and diagnosis into a single "response time" metric that hides whether your monitoring or your runbooks need work
• Celebrating MTTR improvements that came from reclassifying incidents rather than actually recovering faster

Priya Sharma, an engineering director at a healthcare tech company with strict uptime requirements, described her team's transformation: "We reduced MTTR from 4.2 hours to 1.1 hours in two quarters. But 70% of that improvement came from detection — we added synthetic monitoring for the three workflows that caused 80% of our incidents. The actual fix time barely changed."

---

3. Metric #2: PR Cycle Time (Open to Merge)

Pull request cycle time — measured from PR creation to merge — is the single highest-correlation metric with developer satisfaction in our survey. Teams with median PR cycle time under 24 hours scored 23 points higher on internal developer experience surveys (measured on a 100-point scale) than teams with median cycle times over 72 hours.

Why it matters more than deployment frequency:

Deployment frequency tells you how often code reaches production. PR cycle time tells you how long code sits in limbo — reviewed, debated, revised, and sometimes abandoned. Long cycle times create context-switching costs, stale branches, and the subtle morale damage of work that feels stuck.

How to measure it correctly:

• Track median, not average. A few 3-week PRs destroy your average but don't represent team experience.
• Decompose into waiting time (time awaiting review) vs. active time (time in development).
• Segment by PR size. A 50-line PR and a 2,000-line PR should have different benchmarks.

What good looks like:

Metric	Top Quartile	Median
Median PR cycle time	< 18 hours	36 hours
Median time awaiting first review	< 4 hours	14 hours
% PRs merged within 24 hours	> 72%	48%
% PRs abandoned (closed without merge)	< 3%	9%

"We thought our problem was slow CI. It wasn't. Our problem was that the average PR sat unreviewed for 22 hours because reviewers were chosen ad hoc. We switched to round-robin assignment with a 4-hour SLA and cycle time dropped 40% without touching CI at all." — Staff Engineer, 60-person platform team

Common failure modes:

• Including draft PRs in cycle time calculations (inflates numbers)
• Not tracking abandoned PRs (hides work that was started and wasted)
• Optimizing for cycle time by splitting PRs into unusably small chunks — measure reverted-PR rate alongside cycle time to catch this

---

4. Metric #3: Unplanned Work Ratio

This is the metric most engineering leaders wish they'd tracked earlier — and the one that most reliably predicts burnout before it shows up in exit interviews.

Unplanned work ratio measures what percentage of team capacity goes to incidents, urgent bug fixes, support escalations, and "drop everything" requests versus planned roadmap work.

How to measure it:

Track at the team level weekly. Categorize work into:

1. Planned roadmap — work from the current sprint or quarterly plan
2. Planned maintenance — tech debt, dependency updates, scheduled infrastructure work
3. Unplanned reactive — incidents, hotfixes, executive escalations, customer emergencies

Unplanned work ratio = Category 3 / (Categories 1 + 2 + 3)

What good looks like:

Ratio	Interpretation
< 15%	Healthy. Team has capacity for innovation.
15-25%	Normal for mature products with production traffic.
25-35%	Warning zone. Tech debt or reliability issues accumulating.
> 35%	Critical. Team is in firefighting mode. Roadmap delivery will suffer.

Survey finding: teams above 30% unplanned work ratio missed quarterly roadmap commitments at 2.7x the rate of teams below 20% — even when the teams above 30% worked longer hours.

The systemic signal:

Unplanned work ratio is a lagging indicator of systemic problems. When it rises above 25% for two consecutive quarters, top-performing engineering leaders don't just add capacity. They run a root cause analysis:

• Is reliability degrading? (Check incident frequency trend)
• Is tech debt compounding? (Check change failure rate trend)
• Is the team understaffed for the product surface area? (Check engineer-to-service ratio)
• Is product scope expanding without corresponding team growth? (Check roadmap commitment rate)

James Okoro, CTO of a logistics startup that grew from 15 to 85 engineers in 18 months, shared his experience: "Our unplanned work ratio hit 41% in Q3 2025. We were proud of our DORA metrics — deploying 6 times per day. But we were deploying fixes, not features. That single metric convinced the board to pause hiring for two new feature teams and instead add three platform engineers focused on reliability."

---

5. Metric #4: Change Failure Rate by Service

Aggregate change failure rate — the DORA metric — hides the teams and services that need help. Top-performing organizations decompose it by service, team, and deployment type.

Change failure rate = deployments causing a production incident, rollback, or hotfix / total deployments

Why per-service tracking matters:

In our survey, the average organization-wide change failure rate was 8.3%. But decomposed by service, the distribution was bimodal: 60% of services had change failure rates below 4%, while 15% of services had rates above 20%. Those 15% of services generated 73% of production incidents.

Without per-service decomposition, engineering leaders see a healthy 8.3% and miss the team that's deploying broken code one in five times.

What good looks like:

Scope	Top Quartile	Median	Action Threshold
Organization-wide	< 5%	8.3%	> 12%
Individual service	< 3%	7.1%	> 15%
Critical path services	< 2%	4.8%	> 8%

Implementation tips:

• Tag every deployment with service name and team in your CI/CD pipeline
• Include rollbacks triggered within 24 hours as failures (even if automated)
• Review services above the action threshold monthly in engineering leadership meetings
• Pair high change failure rate services with increased code review requirements — not as punishment, but as a diagnostic tool

"We had a microservice with a 24% change failure rate that nobody noticed because org-wide we were at 7%. That service handled payment webhooks. Once we saw the number, we understood why our finance team kept asking about 'those intermittent payment issues.'" — Engineering Manager, e-commerce platform

---

6. Metric #5: Developer Onboarding Time

How long until a new engineer ships production code to a meaningful codebase area? This metric predicts long-term team performance more reliably than any hiring metric — and almost nobody tracks it rigorously.

How to measure it:

Define "meaningful production code" as a PR merged to a primary codebase (not documentation, not config-only changes) that required understanding existing system architecture. Track days from start date to first such merge.

What good looks like:

Company Stage	Top Quartile	Median	Bottom Quartile
Startup (< 50 eng)	< 5 days	10 days	> 21 days
Growth (50-200 eng)	< 10 days	18 days	> 35 days
Enterprise (200+ eng)	< 14 days	28 days	> 60 days

Top-quartile teams at every stage share three practices:

1. Structured onboarding paths — Not "read the wiki and ask questions." A day-by-day plan with a dedicated onboarding buddy, specific first tasks scoped for learning, and a check-in at day 3, 7, and 14.

1. Dev environment that works on day one — Survey finding: 34% of engineers at median-onboarding-time companies reported spending more than 3 days getting their development environment functional. At top-quartile companies, that number was 4%.

1. First PR within 48 hours — Even if it's a small documentation fix or test addition. The goal is learning the PR workflow, CI pipeline, and review culture before tackling complex features.

The retention connection:

Engineers who shipped production code within their first two weeks were 2.1x more likely to remain at the company after 18 months compared to engineers who took more than 30 days. Onboarding time isn't just an efficiency metric — it's an early warning system for retention risk.

---

What to Stop Measuring

The most revealing part of our survey wasn't the metrics top teams track. It was the metrics they deliberately stopped tracking — and the damage they'd seen when those metrics were active.

Story points completed

Why it fails: Gaming is universal and creative. Teams inflate estimates, redefine "points" quarterly, and optimize for velocity rather than outcomes. Every engineering leader I interviewed who had removed story points reported improved team morale within one quarter.

What to track instead: Outcome metrics tied to product goals. Did the feature move the metric it was supposed to move?

Lines of code

Why it fails: Actively harmful. Incentivizes verbose code, discourages refactoring (which reduces LOC), and creates perverse competition. One director described it as "the only metric that gets worse as your codebase improves."

What to track instead: PR cycle time and change failure rate — they capture delivery speed without rewarding code volume.

Commit count

Why it fails: Rewards busywork and punishes engineers who batch logical changes into thoughtful commits. Also vulnerable to trivial commit splitting.

What to track instead: Deployment frequency and PR cycle time measure delivery cadence without incentivizing commit granularity.

Code coverage percentage

Why it fails: Not because testing is bad — because coverage percentage is a proxy that teams optimize instead of optimizing for meaningful test suites. 95% coverage with brittle, meaningless tests is worse than 70% coverage with tests that catch real regressions.

What to track instead: Change failure rate by service. If your tests are good, change failure rate will be low.

"We removed four metrics from our engineering dashboard in 2025: story points, LOC, commit count, and code coverage percentage. We replaced them with the five metrics in this article. Our dashboard has half the charts and twice the actionable information." — VP Engineering, developer tools company

---

Takeaways

• DORA metrics are table stakes, not differentiators. Track them, but don't stop there. The teams that outperform measure delivery system health *and* operational sustainability *and* developer experience.

• Decompose MTTR into detection, diagnosis, fix, and verify. Teams that alert within 5 minutes recover 3x faster. Most MTTR improvements come from better detection, not faster fixes.

• PR cycle time is the highest-correlation metric with developer satisfaction. Median under 24 hours. Track time awaiting review separately — it's usually the bottleneck, not CI.

• Unplanned work ratio above 30% is a systemic warning. It predicts roadmap misses and burnout before exit interviews confirm it. Pause and diagnose when it stays elevated for two quarters.

• Change failure rate must be tracked per service. Organization-wide averages hide the 15% of services generating 73% of incidents. Review services above 15% monthly.

• Developer onboarding time predicts retention. Top teams get new engineers shipping meaningful production code in under two weeks. Engineers who ship within 14 days are 2.1x more likely to stay past 18 months.

• Stop measuring story points, LOC, commit count, and coverage percentage. Replace them with outcome-oriented metrics that can't be gamed. Your dashboard will be simpler and your team will thank you.