Engineering Team KPIs: DORA and What Else to Measure

Engineering has better-researched metrics than almost any other function, and most teams still measure the wrong things — usually because the wrong things are the easiest to extract from a ticket system.

Start with DORA. Add two or three. Measure nothing at the individual level.

The four DORA metrics

From the DevOps Research and Assessment programme, and the closest thing engineering has to an evidence-backed default. They work because they arrive as two pairs that constrain each other.

The pairing is the point. Speed metrics alone reward shipping recklessly. Stability metrics alone reward shipping nothing. Together they describe a team that ships often and safely, which is the actual goal.

If you track only two, track deploy frequency and change failure rate.

What to add

Review turnaround time. From pull request opened to first substantive review. In most teams this is the single largest component of lead time, and it stays invisible unless measured specifically — the work isn't slow, the waiting is.

Defect escape rate. Bugs found in production versus caught before release. A rising escape rate is the earliest signal that delivery pressure is eating quality, and it moves well before anything user-visible does.

Unplanned work percentage. The share of a sprint consumed by things nobody planned. Sustained above roughly 30%, the team is running an incident-response function with a roadmap attached, and no planning process will survive contact with it.

On-call load. Pages per engineer per week, and what share fall outside working hours. A reliability problem and a retention problem, measured by one number.

What not to measure

Lines of code. Rewards verbosity and punishes deletion — and deleting code is often the highest-value work available.

Commits per developer. Rewards commit-splitting. Measures nothing.

Individual velocity or story points per person. The most damaging item on this list. It punishes helping a colleague, reviewing carefully, mentoring, and picking up unglamorous work — precisely the behaviours that make a team faster than the sum of its individuals. Velocity is a team planning aid, and it stops working even as a planning aid the moment it becomes a performance measure.

Story points as a productivity metric at all. They are relative estimates. The unit inflates the moment it is targeted, which makes it the cleanest demonstration of Goodhart's Law available in software.

Setting targets

DORA benchmarks describe performance bands rather than universal targets. The sensible use is direction of travel against your own baseline, not a race toward a published number. A team deploying monthly should aim for weekly before it thinks about daily.

Measure for a month before setting anything. Most teams are surprised by their own lead time, and the surprise is almost always in the waiting rather than the working.

Keep one number honest

Whatever set you choose, make sure at least one number in it gets worse when the team cuts corners. That is what separates a target from a lever.

For engineering the natural constraint is change failure rate. For a team also measured on throughput, add defect escape rate.

How these ladder upward

Engineering KPIs translate a company priority rather than repeating it. If the company priority is reducing churn caused by reliability, the department measure is availability and time-to-restore, and the team measure might be on-call load and escape rate — not deploy frequency, which is a means rather than the end in that particular year.

See how the levels connect and the KPI examples hub for other functions. The four tests for setting team KPIs catch most bad engineering metrics immediately.