Measure engineering productivity as a system, not by individual. Track DORA's five delivery metrics, split into throughput (lead time, deployment frequency, recovery time) and instability (change fail rate, rework rate). Add an anonymous developer survey, and review trends monthly against one bottleneck.
AI coding assistants make commit counts look better than ever. DORA's research suggests delivery stability can fall at the same time, which activity metrics conceal.
Judging an engineering team by its commits is like judging a hospital by its prescriptions. The number moves and is easy to count, yet it says little about whether patients recover. This guide shows you how to choose engineering productivity metrics that describe the system rather than individuals. It also covers calculating DORA's five delivery metrics from existing data and running a monthly review that produces fixes.
Why activity metrics backfire
Commits, pull requests, story points and lines of code measure activity. They rise when work is split smaller or code grows more verbose. None of that means customers received more value.
Four habits cause most failures: measuring individuals rather than the system, relying on one number, setting metrics as targets and comparing unlike teams. DORA warns that targets invite gaming, a direct application of Goodhart's law. It advises improving each team against its own trend rather than staging a competition.
AI assistants sharpen the problem. DORA's 2024 report associated rising AI adoption with an estimated 1.5% fall in delivery throughput and a 7.2% fall in stability. Its 2025 report, covering nearly 5,000 professionals, found 90% using AI at work. AI now showed a positive link with throughput, but still a negative one with stability.
Measure one system through three lenses
Useful metrics describe how work flows from idea to a change running safely in production. They also describe how the people inside that system experience it.
| Lens | Question it answers | Metrics | Data source |
|---|---|---|---|
| Delivery throughput | How quickly do changes reach users? | Lead time, deployment frequency, recovery time | Version control, release logs, incidents |
| Delivery instability | How often do changes hurt users? | Change fail rate, deployment rework rate | Deployment logs linked to incidents |
| Developer experience | Is the work sustainable? | Survey scores for satisfaction, flow and friction | Quarterly anonymous survey |
The first two lenses are DORA's five metrics, split so that speed is never read without its cost. The third comes from the SPACE framework, published in ACM Queue in 2021. Its authors recommend at least three dimensions, including one perceptual measure such as a survey, and only anonymised, aggregate reporting.
Calculate DORA metrics from data you already hold
No new platform is needed to begin. DORA itself advises against elaborate data integrations before acting. What you need are written definitions, agreed before anyone looks at a number.
- Change lead time: from commit to production deployment, reported as the median and 85th percentile.
- Deployment frequency: production deployments per period.
- Failed deployment recovery time: time to recover from a deployment needing immediate intervention.
- Change fail rate: share of deployments needing a rollback or hotfix.
- Deployment rework rate: share of deployments that were unplanned and caused by a production incident.
Consider a hypothetical team with 63 production deployments in 20 working days, about 3.2 a day. Six needed a rollback or hotfix, a change fail rate of 9.5%. Three were unplanned incident fixes, a rework rate of 4.8%. Median recovery took 95 minutes.
The insight lies in lead time: a 2.6-day median, but 9 days at the 85th percentile. Roughly one change in seven waits more than a week, usually behind a scarce reviewer or a manual approval. That tail, not the average, deserves next month's attention.
Run a monthly review that changes something
Hold the review with the team, not about it. Collect four to eight weeks of baseline data before setting any goals. Then choose one bottleneck, test one change, and read every throughput gain against a stability metric.
| Symptom in the data | Likely constraint | First experiment |
|---|---|---|
| Long lead time tail, normal median | Review queues or large batches | Smaller pull requests and a reviewer rota |
| Rising fail rate after faster delivery | Thin automated testing or rushed review | A required test gate on the riskiest services |
| Low deployment frequency, low fail rate | Fear of release or manual approvals | Automate one approval step; add fast rollback |
| Long recovery time | Weak observability or unclear on-call ownership | Deployment markers on dashboards and a recovery runbook |
| Healthy delivery metrics, falling survey scores | Hidden toil or unsustainable pace | Ask which task wastes most time; remove it |
Close the loop with the quarterly survey. If lead time fell but flow scores dropped, understand why before celebrating.
Judge AI assistants by outcomes
Compare the same teams before and after adoption, since early adopters are rarely typical. Track lead time and deployment frequency for throughput, and change fail and rework rates for stability. Add review time per pull request, because faster authoring often moves the bottleneck to reviewers.
DORA's 2025 findings describe AI as an amplifier. Teams with loosely coupled architectures and fast feedback gain, while tightly coupled ones see little benefit. In our view, if throughput rises while stability falls, the next pound or rupee belongs in test automation and smaller batches, not more licences.
Delivery discipline is also evidence. Enterprise buyers often ask suppliers how changes are tested, released and rolled back, because a supplier's bad release becomes their outage.
The bottom line
Conclusion
A hospital is judged by whether patients recover, not by prescriptions written. Engineering deserves the same standard: metrics that show how safely and quickly changes reach users, read in pairs so that speed never hides its cost.
This week, export last month's deployment log and incident list, and agree written definitions for the five DORA metrics with your leads. Calculate them in a spreadsheet, then examine the lead time tail before anything else.
Frequently asked questions
Why are lines of code a poor productivity metric?
Lines of code count activity rather than value. They can rise while software gets worse, particularly when AI coding assistants generate more code.
What are the five DORA metrics?
Change lead time, deployment frequency and failed deployment recovery time measure throughput. Change fail rate and deployment rework rate measure instability.
Should I compare delivery metrics across teams?
Comparing teams that run very different systems misleads. DORA recommends improving each team against its own trend rather than ranking teams against one another.
How do I measure the impact of AI coding tools?
Compare the same teams before and after adoption on lead time, deployment frequency, change fail rate, rework rate and review time, reading throughput and stability together.
What is the SPACE framework?
SPACE describes developer productivity across satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. It recommends at least three dimensions, including one perceptual measure.
References
Disclaimer: General information only, not legal, security, compliance or financial advice. Check the cited sources and seek professional advice. Names belong to their owners; no endorsement implied.