Few topics generate more heat and less light than engineering productivity. Leaders want to understand whether their investment in delivery is paying off, yet most attempts to measure it either reduce engineers to a line count or produce dashboards so abstract that no one acts on them. Metrics such as DORA and flow can give leaders a trustworthy view of delivery performance, but only if they are used to understand the system rather than to rank the people working within it. The moment a metric becomes a target for individuals, it stops telling you the truth.
What productivity metrics are actually for
The purpose of delivery metrics is to surface where work flows smoothly and where it gets stuck, so that leaders can invest in removing friction. They are diagnostic instruments, not performance reviews. A healthy set of metrics answers questions such as how quickly a change reaches production, how often deployments fail, and where work waits longest in the pipeline. Those answers point to systemic improvements: better testing, smaller batches, faster environments, clearer ownership.
Used this way, metrics build trust between leadership and engineering because they describe shared reality rather than apportion blame. Used the wrong way, as a scoreboard for comparing individuals or teams, they corrode that trust and invite gaming. The intent behind the measurement determines whether it helps or harms.
The DORA metrics and what they reveal
The four DORA metrics have endured because they balance speed and stability, and they resist easy gaming when used at the system level. Deployment frequency and lead time for changes capture how quickly you can deliver. Change failure rate and time to restore service capture how safely you do so. Together they prevent the classic distortion where a team looks fast because it is shipping recklessly, or looks stable because it is shipping nothing.
The insight is in the relationships between them, not the absolute numbers. A short lead time paired with a high change failure rate suggests testing and quality gaps. A low deployment frequency paired with a long time to restore suggests fragile, infrequent releases that are painful to recover. Reading the four together gives a balanced picture that any single metric would distort.
Flow metrics show where work waits
DORA tells you about the output of your delivery system, while flow metrics tell you about its internals. Flow time, the elapsed time from when work starts to when it is delivered, almost always reveals that the bottleneck is waiting rather than working. Most of the delay in delivering a change is time spent queued, blocked, or waiting for review, not time spent in active development.
This is liberating, because waiting is usually easier to fix than coding is to speed up. Flow load shows when teams are overloaded with too much work in progress, which slows everything down. Flow efficiency, the ratio of active time to total time, frequently exposes how little of a change's life is spent being worked on. These metrics direct attention to the queues and handoffs that quietly consume most of your delivery time.
- Measure the four DORA metrics at team and system level, never to rank individuals.
- Pair speed metrics with stability metrics so that no team can look good by being reckless or by shipping nothing.
- Track flow time and flow efficiency to expose where work waits rather than only where it is worked on.
- Review metrics in retrospectives as prompts for improvement, not in performance reviews as judgements.
- Combine quantitative metrics with qualitative signals such as developer experience surveys.
- Watch for gaming and treat any sudden, unexplained improvement in a single metric with healthy suspicion.
How metrics get gamed and how to prevent it
Any metric tied to reward or punishment will eventually be optimised for directly, often at the expense of the outcome it was meant to represent. If deployment frequency becomes a target, teams will split deployments artificially to inflate the count. If lead time is the target, they will start the clock later. If lines of code or story points are measured, both will balloon without any increase in value. This is not dishonesty, it is a predictable human response to incentives.
The defence is to keep metrics at the level of teams and systems, to use balanced sets that make gaming one metric visible in another, and above all to keep the conversation focused on improvement rather than judgement. When engineers understand that the metrics exist to help them remove friction, not to grade them, they have no reason to game and every reason to engage honestly.
Combine numbers with experience
Quantitative metrics describe the behaviour of the delivery system, but they cannot explain why it behaves that way, and they miss aspects of productivity that resist measurement. A team can have excellent DORA numbers and be quietly miserable, burning out, or accumulating debt that will surface later. Numbers alone give a partial and sometimes misleading picture.
Pair the metrics with the lived experience of the people doing the work. Developer experience surveys, regular retrospectives, and simply listening to teams reveal the friction that dashboards cannot, such as flaky tests, slow environments, unclear requirements, or constant context switching. The richest understanding comes from triangulating between what the metrics show and what the engineers report.
Common pitfalls
The most damaging pitfall is using productivity metrics to compare or rank individuals, which destroys trust and guarantees gaming. Close behind is fixating on a single metric, which always distorts behaviour, and reaching for proxies such as lines of code or hours worked, which measure activity rather than value. Each of these turns a diagnostic tool into a weapon and gets the opposite of the intended result.
Another frequent error is collecting metrics and never acting on them, which trains teams to ignore the dashboards entirely. Metrics earn their keep only when they lead to changes that make delivery smoother. If a quarter of measurement produces no improvement actions, the measurement is theatre rather than insight.
Productivity metrics that leaders can trust are those used to understand and improve the delivery system, not to judge the people inside it. Read DORA and flow together, keep them at the team level, pair them with the experience of engineers, and always act on what they reveal. Done this way, they build trust rather than erode it. Need support applying this approach? Email sales@halfteck.com.