What to Track About Engineering Productivity Besides DORA

A team can have a high deployment frequency, deploying on demand rather than in scheduled batches¹, while shipping a stream of small, low-value changes that avoid anything risky enough to matter. Deploy frequency measures throughput of the pipeline, not the value of what's moving through it.

Pair it with a rough sense of what's actually shipping: are deploys clustering around real features and fixes, or around trivial changes that pad the count without moving the product forward. That's a qualitative check, not a number, and it's worth doing periodically rather than assuming a high cadence is automatically healthy. A cadence that looks strong on a dashboard can still coexist with a roadmap that's barely moving, which is exactly the gap the rest of these metrics are meant to catch.

The time a pull request sits waiting for a first review is often the largest, most invisible chunk of your lead time, and it's rarely where teams look when lead time creeps up. Code review capacity, not coding speed, is the actual bottleneck in a lot of engineering organizations.

Track time to first review separately from total time to merge. If the gap between them is small, review isn't your bottleneck. If most of the lead time sits in that first gap, the fix is review capacity and process, not asking engineers to write code faster.

A feature that ships and then gets substantially rebuilt within a few weeks represents wasted throughput that a deploy-frequency metric counts as two successful deploys. Tracking how often recently shipped work gets significantly reworked, not just bug-fixed, surfaces a different kind of inefficiency than DORA's metrics catch.

This is harder to automate than DORA's metrics, since it usually requires someone tagging a change as rework rather than new work, but even a rough, manually maintained count over a quarter is more useful than not tracking it at all.

A short, regular survey asking engineers where they lose time, waiting on CI, unclear requirements, flaky tests, surfaces friction that no pipeline metric captures directly, because the friction happens before code ever reaches the pipeline. Keep it short enough that people actually fill it out, four or five questions, run quarterly.

The value is in the trend, not any single response. A friction point that keeps showing up survey after survey is worth fixing even if no dashboard metric points at it.

Four or five metrics tracked consistently and discussed honestly beat a dashboard with twenty metrics nobody looks at closely. Once a metric becomes something individuals are evaluated on directly, people optimize for the metric instead of the outcome it was meant to represent, which is exactly how deploy frequency turns into a stream of trivial commits.

Use these metrics at the team level to spot where to invest, in review capacity, in test reliability, in reducing rework, not as an individual performance scorecard. That distinction is what keeps the numbers honest.

A high deployment frequency next to a rising rework rate usually means the team is shipping fast and correcting course after the fact, worth knowing before you conclude the pipeline is healthy on cadence alone. A long review latency next to a low deploy frequency points at review capacity as the constraint worth fixing first, rather than asking engineers to write code faster.

Look at the set together once a month rather than reacting to any single number in isolation. A single metric moving in a bad direction is often noise, a survey complaint, a cluster of related complaints, or a slow drift across two or three of these at once is the pattern worth actually investigating.

A small metric set alongside DORA could include:

• Review latency, the time a pull request waits for its first review, which often hides the largest share of lead time.
• Rework rate, meaning how often recently shipped work gets substantially rebuilt rather than simply bug-fixed.
• A short, regular developer experience survey asking where engineers lose time.
• The four DORA metrics kept as a baseline for pipeline health and regression spotting.
• A monthly team-level review of these numbers, without using them as individual performance scores.