---
id: business/industry-benchmarks/engineering-productivity-benchmarks-2026/2026
canonical_question: "What are engineering productivity benchmarks 2026 — DORA metrics, cycle time by team size?"
aliases:
  - "DORA metrics benchmarks 2026 deployment frequency change failure rate"
  - "Software engineering cycle time benchmarks by team size"
  - "Developer productivity metrics and benchmarks 2026"
  - "PR review time and merge frequency benchmarks 2026"
  - "Engineering team performance benchmarks elite vs low performers"
entity_type: benchmark
domain: business > industry-benchmarks > Engineering Productivity Benchmarks
region: global
jurisdiction: global
temporal_scope: 2026

last_verified: 2026-03-11
confidence: 0.83
version: 1.0
first_published: 2026-03-11

temporal_validity:
  status: volatile
  last_breaking_change: "2025 DORA report replaced elite/low performer tiers with nuanced profile clusters. AI adoption improved throughput but increased delivery instability. Fifth metric (failed deployment recovery time) officially added."
  next_review: 2026-09-07
  change_sensitivity: high
  data_vintage: "H2 2025"

constraints:
  - "Team size specificity — small teams (<10) show 15-20% better per-engineer metrics due to reduced coordination overhead. Normalize by team size."
  - "Tech stack matters — deployment frequency benchmarks assume CI/CD capability. Teams with manual deployment processes cannot meaningfully compare."
  - "AI adoption bias — teams using AI coding assistants show 30-40% improvement in cycle time but increased change failure rates. Separate AI-assisted vs non-AI baselines."
  - "Methodology — DORA 2025 uses profile clusters, not tiers. Legacy 'elite/high/medium/low' classifications are outdated."
  - "Vintage warning — data from H2 2025. AI-assisted development is shifting benchmarks faster than any previous tooling change."

skip_this_unit_if:
  - condition: "User needs professional services delivery benchmarks"
    use_instead: "business/industry-benchmarks/professional-services-benchmarks-2026/2026"
  - condition: "User needs startup salary data to complement productivity metrics"
    use_instead: "business/industry-benchmarks/startup-salary-benchmarks-2026/2026"

inputs_needed:
  - key: team_size
    question: "How large is the engineering team?"
    type: choice
    options: ["Small (1-10)", "Medium (11-50)", "Large (51-200)", "Enterprise (200+)"]
  - key: ai_adoption
    question: "Does the team use AI coding assistants?"
    type: choice
    options: ["Heavy AI adoption", "Moderate AI adoption", "No AI tools"]
  - key: metric_focus
    question: "Which metrics?"
    type: multi_select
    options: ["DORA metrics (deploy, lead time, CFR, recovery)", "Cycle time & PR metrics", "Developer experience", "Quality & reliability"]

canonical_source: "https://knowledgelib.io/business/industry-benchmarks/engineering-productivity-benchmarks-2026/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-11, data vintage: H2 2025)"

related_kos:
  referenced_by: []
  related_to:
    - id: "business/industry-benchmarks/startup-salary-benchmarks-2026/2026"
      label: "Startup salary benchmarks — what these productivity levels cost"
    - id: "business/industry-benchmarks/professional-services-benchmarks-2026/2026"
      label: "Professional services benchmarks — external team comparison"
  depends_on: []
  often_confused_with: []
  alternative_to: []

sources:
  - id: src1
    title: "DORA 2025: Measuring Software Delivery After AI"
    author: DORA / Google
    url: https://dora.dev/
    type: primary_research
    published: 2025-12-01
    data_period: "2025"
    sample_size: "30,000+ professionals globally"
    reliability: authoritative
  - id: src2
    title: "2025 Engineering Benchmarks: Insights from 6.1M+ Pull Requests"
    author: LinearB
    url: https://linearb.io/blog/2025-engineering-benchmarks-insights
    type: primary_research
    published: 2025-09-01
    data_period: "H1 2025"
    sample_size: "6.1 million pull requests"
    reliability: authoritative
  - id: src3
    title: "2025 Employee Productivity Score Benchmarks for Software Engineering Teams"
    author: Worklytics
    url: https://www.worklytics.co/resources/2025-employee-productivity-score-benchmarks-software-engineering-teams
    type: primary_research
    published: 2025-08-01
    data_period: "2025"
    sample_size: "3.4 million pull requests"
    reliability: high
  - id: src4
    title: "RDEL #115: 2025 Benchmarks for DORA 4 Metrics"
    author: RDEL Newsletter
    url: https://rdel.substack.com/p/rdel-115-what-are-the-2025-benchmarks
    type: industry_report
    published: 2025-10-01
    data_period: "2025"
    sample_size: "Industry aggregate"
    reliability: high
  - id: src5
    title: "Engineering Metrics Benchmarks: What Makes Elite Teams?"
    author: LinearB
    url: https://linearb.io/blog/engineering-metrics-benchmarks-what-makes-elite-teams
    type: industry_report
    published: 2025-07-01
    data_period: "2024-2025"
    sample_size: "5,000+ engineering teams"
    reliability: high
  - id: src6
    title: "2025 Engineering Performance Benchmarks"
    author: DevDynamics
    url: https://devdynamics.ai/blog/the-ultimate-guide-to-dora-software-metrics-what-they-are-and-why-they-matter
    type: industry_report
    published: 2025-06-01
    data_period: "2024-2025"
    sample_size: "Industry aggregate"
    reliability: high
---

# Engineering Productivity Benchmarks 2026

## Summary

Comprehensive engineering productivity benchmarks covering DORA metrics (deployment frequency, lead time, change failure rate, failed deployment recovery time), cycle time, PR metrics, developer experience, and quality indicators segmented by team size and AI adoption level. The 2025 DORA report replaced the elite/low performer tier system with nuanced profile clusters and added a fifth official metric. AI adoption improved throughput metrics by 30-40% but increased delivery instability across all team sizes. [src1]

**Data vintage**: Based on H2 2025 data from 30,000+ professionals (DORA) and 6.1M+ pull requests (LinearB).
**Key shift**: AI is a double-edged sword for engineering — faster code output but higher change failure rates. The old "elite performer" framework is officially dead; use profile-based benchmarking instead.

## Constraints
<!-- Agents: read before citing any benchmark number. -->

- These benchmarks represent software engineering teams at technology companies. Do not apply to embedded systems, hardware, or non-software teams without adjustment.
- Team size significantly impacts metrics — small teams (1-10) show 15-20% better per-engineer output. Always normalize by team size before comparing.
- AI adoption creates a bimodal distribution. Teams with AI coding assistants show 30-40% better cycle time but 15-25% higher change failure rates. Separate baselines.
- Legacy DORA tiers (elite/high/medium/low) are outdated. The 2025 DORA report uses profile clusters. Apply profile labels cautiously.
- Data from H2 2025. AI-assisted development benchmarks are shifting faster than any previous tooling transition.

## DORA Metrics

### Deployment Frequency

**Definition**: How often code is deployed to production. Measures throughput capability of the delivery pipeline.

| Profile | Frequency | % of Orgs |
|---------|-----------|-----------|
| On-demand (multiple/day) | Multiple times per day | 16.2% |
| Daily to weekly | Once per day to once per week | 21.9% |
| Weekly to monthly | Once per week to once per month | 28.4% |
| Monthly to quarterly | Once per month to once per quarter | 22.8% |
| Infrequent | Less than once per quarter | 10.7% |

**Trend**: On-demand deployment growing slowly. AI-assisted teams deploy 25-30% more frequently but with higher rollback rates. [src1]
**Red flag threshold**: Deploying less than once per month signals significant delivery pipeline friction.
**Action trigger**: If below weekly, invest in CI/CD automation, feature flags, and deployment confidence before trying to increase frequency.

### Lead Time for Changes

**Definition**: Time from code commit to running in production. Measures delivery pipeline efficiency.

| Profile | Lead Time | Benchmark |
|---------|-----------|-----------|
| Elite | < 1 hour | Top 10% of teams |
| High | 1-24 hours | 75th percentile |
| Medium | 1 day - 1 week | Median |
| Needs improvement | 1 week - 1 month | 25th percentile |
| Low | > 1 month | Bottom 10% |

**By team size**:

| Team Size | Median Lead Time | 75th Pct | Top Decile |
|-----------|-----------------|----------|------------|
| Small (1-10) | 2.9 days | 1.2 days | < 6 hours |
| Medium (11-50) | 3.8 days | 2.1 days | < 12 hours |
| Large (51-200) | 5.2 days | 3.5 days | < 1 day |
| Enterprise (200+) | 8.5 days | 5.0 days | < 2 days |

[src1, src2]

### Change Failure Rate (CFR)

**Definition**: Percentage of deployments that cause a failure in production requiring remediation (hotfix, rollback, patch). Measures delivery stability.

| Range | CFR | % of Teams |
|-------|-----|-----------|
| Excellent | < 2% | 8.5% |
| Good | 2-8% | 24.3% |
| Moderate | 8-16% | 26.0% |
| High | 16-30% | 25.7% |
| Critical | > 30% | 15.5% |

**AI impact**: Teams with heavy AI adoption see 3-5pp higher CFR than non-AI teams at the same deployment frequency. [src1]
**Red flag threshold**: CFR above 25% means one in four deployments causes a production issue — shipping speed is creating more problems than it solves.
**Action trigger**: If CFR rising while deployment frequency increases, invest in automated testing, code review quality, and staging environments.

### Failed Deployment Recovery Time (FDRT)

**Definition**: Time to restore service when a deployment causes a failure. Formerly MTTR, renamed and reclassified to throughput category in 2025.

| Profile | Recovery Time | % of Teams |
|---------|--------------|-----------|
| Fast | < 1 hour | 12.8% |
| Good | 1-4 hours | 18.5% |
| Moderate | 4-24 hours | 25.4% |
| Slow | 1-7 days | 28.5% |
| Very slow | > 7 days | 14.8% |

**Red flag threshold**: Recovery taking more than 24 hours indicates insufficient observability, runbook documentation, or rollback capability.
**Action trigger**: If FDRT > 4 hours, invest in automated rollback, improved monitoring/alerting, and incident response playbooks.

[src1, src4]

## Cycle Time & PR Metrics

### Cycle Time

**Definition**: Time from first commit to merge for a unit of work. Includes coding time, review time, and rework time.

| Team Size | Median | 75th Pct | Top Decile |
|-----------|--------|----------|------------|
| Small (1-10) | 26 hours | 15 hours | < 8 hours |
| Medium (11-50) | 48 hours | 28 hours | < 14 hours |
| Large (51-200) | 72 hours | 48 hours | < 24 hours |
| Enterprise (200+) | 120 hours | 72 hours | < 36 hours |

**With AI tools**: Cycle time reduced 30-40% across all team sizes when AI coding assistants used effectively. [src2]
**Red flag threshold**: Cycle time exceeding 7 days (167 hours) indicates process bottlenecks — typically code review queues or unclear requirements.
**Action trigger**: If cycle time > 5 days, decompose into coding / review / rework phases to identify the bottleneck.

### PR Review Time

**Definition**: Time from PR opened to first substantive review. Not time to merge — just time to get initial feedback.

| Performance | Review Time | Target |
|-------------|------------|--------|
| Elite | < 4 hours | Same-day feedback |
| Good | 4-12 hours | Within business day |
| Acceptable | 12-24 hours | Next business day |
| Needs improvement | 24-48 hours | Review queue buildup |
| Poor | > 48 hours | Significant blocker |

**Red flag threshold**: PR review time > 24 hours consistently signals review bandwidth problems. [src2, src5]
**Action trigger**: If > 24 hours, implement review SLAs, reduce PR size, and consider rotating review duty.

### PR Size

**Definition**: Number of code changes (additions + deletions) per pull request. Smaller PRs correlate with faster review, lower defect rates, and better knowledge sharing.

| Category | Lines Changed | Merge Rate |
|----------|--------------|------------|
| Small (ideal) | < 85 lines | 95%+ merge rate |
| Medium | 85-200 lines | 88% merge rate |
| Large | 200-400 lines | 75% merge rate |
| Very large (avoid) | > 400 lines | 60% merge rate |

**Red flag threshold**: Median PR size exceeding 200 lines indicates PRs are too large for effective review. [src2]

[src2, src3]

## Developer Experience Metrics

### Focus Time

**Definition**: Hours per day of uninterrupted work time (no meetings, no context switches). Measured via calendar analysis and tool usage patterns.

| Percentile | Focus Hours/Day |
|------------|----------------|
| 90th (top) | 6.5+ hours |
| 75th | 5.8 hours |
| Median (50th) | 4.2 hours |
| 25th | 3.1 hours |
| 10th (bottom) | 2.0 hours |

**By team size**: Small teams average +15% more focus time than median (4.8 vs 4.2 hours/day). [src3]
**Red flag threshold**: Focus time below 3 hours/day correlates with 30-40% lower output and significantly higher burnout risk.
**Action trigger**: If median focus time < 3.5 hours, implement meeting-free blocks, reduce recurring meetings, and audit interrupt sources.

### PR Velocity per Engineer

**Definition**: Number of merged pull requests per engineer per month.

| Percentile | PRs/Month |
|------------|-----------|
| 90th (top) | 22+ |
| 75th | 18.5 |
| Median (50th) | 12.4 |
| 25th | 7.8 |
| 10th (bottom) | 4.2 |

**By team size**: Small teams show +20% PR velocity above median (14.9 vs 12.4 PRs/month). [src3]
**Red flag threshold**: Below 6 PRs/month per engineer may signal blockers, unclear priorities, or excessive non-coding work.

### Engineering NPS (eNPS)

**Definition**: Net Promoter Score measuring developer satisfaction and engagement. Survey-based.

| Rating | eNPS | Interpretation |
|--------|------|----------------|
| Excellent | > 50 | Highly engaged, strong retention |
| Good | 20-50 | Healthy team, minor friction |
| Neutral | 0-20 | Average satisfaction |
| Concerning | -20 to 0 | Disengagement signals |
| Critical | < -20 | Retention risk, culture problems |

[src3, src5]

## Composite Metrics & Rules of Thumb

| Rule | Formula / Threshold | Interpretation |
|------|---------------------|----------------|
| Deploy frequency > 1/day | Deployments per day | High-performing delivery pipeline |
| Lead time < 24 hours | Commit to production | Fast, reliable delivery |
| CFR < 10% | Failed deploys / total deploys | Stable delivery quality |
| FDRT < 4 hours | Time to restore service | Strong incident response |
| PR review < 12 hours | Time to first review | No review bottleneck |
| PR size < 100 lines | Lines changed per PR | Reviewable, low-risk changes |
| Focus time > 4 hours/day | Uninterrupted work hours | Sufficient deep work capacity |
| Cycle time < 3 days | First commit to merge | Healthy development flow |

**Constraint**: DORA metrics optimize for throughput and stability but do not measure value delivery. A team can score "elite" on DORA metrics while building the wrong features. Combine with product metrics (feature adoption, user impact) for a complete picture. AI-boosted metrics may mask quality degradation — always pair speed metrics with CFR and defect rates. [src1]

## Segment Definitions

| Segment | Definition | Typical Characteristics |
|---------|-----------|------------------------|
| Small Team (1-10) | Early-stage startup engineering | Low coordination overhead, high per-person output, less specialization |
| Medium Team (11-50) | Growth-stage startup or small product team | Emerging processes, team leads, beginning specialization |
| Large Team (51-200) | Scale-up or enterprise product org | Formal processes, platform teams, significant coordination cost |
| Enterprise (200+) | Large company engineering org | Complex governance, multiple teams/squads, highest coordination overhead |

## Year-over-Year Trend Summary

| Metric | 2024 | 2025 | 2026 (proj.) | Direction |
|--------|------|------|--------------|-----------|
| % deploying daily+ | 34% | 38% | 40-43% | Up 4-5pp |
| Median lead time | 4.5 days | 3.8 days | 3.2-3.6 days | Down (improving) |
| Median CFR | 14% | 16% | 15-18% | Up 2pp (AI-driven) |
| Median FDRT | 6 hours | 5 hours | 4-5 hours | Down (improving) |
| Median cycle time | 56 hours | 48 hours | 40-46 hours | Down 15-20% |
| Median focus hours/day | 4.0 | 4.2 | 4.3-4.5 | Up 0.2-0.3 hrs |
| Median PR size | 125 lines | 110 lines | 95-105 lines | Down (improving) |

[src1, src2, src3]

## Common Misinterpretations

- **Treating DORA metrics as the complete picture**: DORA measures delivery capability, not value delivery. A team deploying 10 times per day with low CFR may still be building features nobody uses. Always pair with product impact metrics. [src1]
- **Comparing across radically different team sizes**: A 5-person team deploying 3x/day is not more productive than a 200-person org deploying 1x/day. Normalize metrics by team size and coordination complexity.
- **Conflating AI speed gains with productivity gains**: AI tools reduce cycle time by 30-40% but increase change failure rates by 15-25%. The net productivity impact depends on how quickly failures are caught and resolved.
- **Using individual metrics for performance reviews**: Engineering productivity metrics are team-level and system-level measures. Using PR count or cycle time to evaluate individual engineers incentivizes gaming (tiny PRs, rushing reviews) and damages team culture.

## When This Matters

Fetch when a user asks about engineering team performance benchmarks, needs to set DORA metric targets, is evaluating developer productivity tools, or needs to benchmark cycle time and deployment practices by team size.

## Related Units

- [Startup Salary Benchmarks 2026](/business/industry-benchmarks/startup-salary-benchmarks-2026/2026)
- [Professional Services Benchmarks 2026](/business/industry-benchmarks/professional-services-benchmarks-2026/2026)
- [SaaS Industry Benchmarks 2026](/finance/industry-benchmarks/saas-industry-benchmarks-2026/2026)