Engineering Metrics Worth Tracking Beyond DORA

DORA measures the pipeline from code being written to code being safely in production. It has nothing to say about what happens before code exists, how long an engineer waited for a design decision, how much of their week went to meetings or interrupt work, or how long a pull request sat waiting for review before anyone looked at it.

How your team actually tracks against DORA's own deploy frequency clusters is itself worth knowing before layering more metrics on top: a team stuck releasing only once a month has a very different bottleneck to diagnose than one already deploying daily, and the additional metrics worth prioritizing differ accordingly¹.

Time from a pull request being opened to first review, and separately, time from approval to merge, surfaces a bottleneck DORA doesn't capture at all: work that's finished but stuck waiting on another human. This is usually one of the easiest bottlenecks to fix once it's visible, since it's often solved by a review SLA norm rather than any process overhaul.

Track it at the team level, not the individual level. The moment this becomes an individual scorecard, it stops measuring review bottlenecks and starts measuring who's fastest to rubber-stamp things, which is the opposite of what you actually want.

Ask engineers to roughly tag their time, planned roadmap work versus unplanned interrupts, production incidents, urgent bug fixes, ad hoc requests, for a couple of sprints, and the resulting split is often more revealing than any other metric on this list. A team that believes it's spending most of its time on the roadmap and is actually spending a third of it on interrupts has a very different problem than a team whose estimates are simply optimistic.

This doesn't need precise time tracking to be useful. A rough, honest self-report captured consistently over a few sprints tells you more than a perfectly accurate measurement nobody bothered to take.

Lines of code, commit count, and individual story points completed per engineer all correlate weakly with actual value delivered and strongly with how easy they are to inflate. An engineer who splits one unit of work into ten small commits, or pads a pull request with unnecessary changes, looks more productive on paper without having delivered anything more.

If a metric is easy to move without actually changing the underlying work, engineers under any kind of pressure will eventually find that shortcut, not out of bad faith, but because that's what the metric is rewarding. Avoid tracking anything at the individual level that has an easy, low-effort way to inflate it.

The value in any of these metrics comes from a team looking at its own trend and asking why, not from comparing engineers or teams against each other on a leaderboard. Review time creeping up might mean the team's grown faster than its review capacity; a rising interrupt-work share might mean a specific system needs investment, not that anyone's underperforming.

Bring these numbers to retrospectives as a discussion prompt, not a performance evaluation input. The moment a metric is tied to individual evaluation, the incentive to report it honestly starts competing with the incentive to look good on it, and honesty usually loses first.

A starting set that adds signal without becoming a scoreboard:

• Track time from pull request opened to first review, and from approval to merge, at the team level rather than per person.
• Have engineers roughly tag time as planned roadmap work or unplanned interrupts for a couple of sprints, and look at the split.
• Review trends in team retrospectives and ask why they moved, instead of comparing engineers or teams on a leaderboard.
• Skip lines of code, commit count and story points per engineer, since they are easy to inflate without doing more real work.