Every technology leadership meeting has a metrics slide. It shows velocity, throughput, cycle time, maybe a burndown chart. The numbers look reasonable. The trends are stable or improving. Everyone nods. The meeting moves on. And yet the business is still asking the same questions it asked last quarter: why isn't anything changing? Why are customers still experiencing the same problems? Why does our technology investment feel like it disappears into a machine that produces activity but not results?
The answer is uncomfortable but straightforward. The metrics measure the machine, not the outcome. The technology function is measuring itself — its own busyness, its own throughput, its own internal performance — rather than the value it creates for the organisation it serves. The dashboard is green. The impact is invisible.
The hierarchy of delivery metrics
Not all metrics are equal, and understanding the distinction is the first step towards measurement that actually informs decisions. There are three levels, and they are fundamentally different in what they tell you.
Level 1: Activity metrics. Story points completed, velocity trends, number of deployments, lines of code, pull requests merged. These metrics tell you one thing: the team is busy. They confirm that human beings are sitting at desks and producing artefacts. They say nothing about whether the artefacts matter. A team with perfect velocity could be delivering features that no customer will ever use, and the metric would look identical to a team transforming the business.
Level 2: Output metrics. Features shipped, throughput per team, cycle time from commit to production, lead time for changes, deployment frequency. These are better. They tell you the team is producing — that work is moving through the system and arriving in the hands of users. But they still do not answer the question that matters. A feature shipped is not a customer outcome achieved. Output is necessary but not sufficient.
Level 3: Outcome metrics. Customer experience improvement, revenue impact, operational cost reduction, time-to-value for new capabilities, customer retention changes, reduction in failure demand. These metrics tell you the work mattered. They connect technology delivery to business results. They answer the only question leadership should care about: did the investment create the value it was supposed to create?
Most organisations measure extensively at Level 1 and Level 2. Almost none measure meaningfully at Level 3. The result is a leadership team with excellent visibility into how much work is being done, and almost no visibility into whether the work is creating value. They can tell you how fast the engine is running. They cannot tell you whether the vehicle is heading in the right direction.
Why activity metrics are dangerous
Velocity and story points are not merely unhelpful at the leadership level — they are actively dangerous. They create perverse incentives that degrade the quality of decision-making across the entire technology function.
When velocity becomes the metric that leadership watches, teams respond rationally. They inflate estimates to appear more productive. Work is structured to maximise point completion rather than customer value — small, easily completable stories are preferred over larger, more impactful work that carries more uncertainty. Refactoring, technical debt reduction, and architectural improvement are deprioritised because they do not produce impressive velocity numbers. The metric becomes a game rather than a signal.
Leadership receives a number that feels like progress. It trends upward. It is presented on charts with satisfying gradients. It means nothing. Worse than nothing — the metric itself drives behaviour that reduces the quality of decisions being made at the team level. The measurement distorts the thing being measured, and the distortion is invisible to the people reviewing the dashboard.
The most dangerous metric in technology leadership is one that looks healthy while the outcomes it claims to represent are deteriorating. Activity metrics are precisely this: a green dashboard masking a failure to create value.
The missing metric: customer outcome
Ask any technology leadership team a simple question: Are customers experiencing better results because of the work we shipped last quarter? In most organisations, the room goes quiet. Not because the answer is negative — but because nobody knows. The data does not exist. The connection between delivery and customer experience has never been drawn.
This is the only question that matters, and it requires a fundamentally different kind of measurement. It requires understanding the causal chain between technology delivery and customer experience. Which features actually changed customer behaviour? Which platform improvements reduced the friction that was driving complaints? Which operational changes made the service more reliable in ways that customers noticed and valued?
Most organisations have no line of sight between what was shipped and what customers experienced. The delivery team knows what they built. The product team knows what they requested. The customer experience team knows what customers are saying. But nobody has connected these three perspectives into a coherent view of whether the investment created value. The data exists in silos, and the measurement framework that would connect them has never been designed.
Designing a measurement framework that works
The fix is not to add more metrics. Most organisations are already drowning in data. The fix is to start from the right end of the problem.
Start with the outcome. What business or customer result are we trying to achieve? Be specific. Not "improve customer experience" — that is too vague to measure. Instead: reduce the average time to complete a mortgage application from fourteen days to three. Increase the percentage of customers who can resolve their query without contacting support from forty per cent to seventy per cent. Reduce the operational cost per transaction by twenty per cent.
Work backwards. What capabilities need to exist for that outcome to be achieved? What systems, processes, and integrations need to be in place? What delivery work is required to build those capabilities?
Now measure at all three levels — but report differently to different audiences. Outcome metrics go to the leadership team. They see customer results, time-to-value, and capability delivery against the strategic plan. Output metrics go to delivery leadership — heads of engineering, delivery managers — who need to understand flow and throughput. Activity metrics stay with the delivery teams themselves, as internal signals for managing their own work.
The leadership team should never see a story point. They should see customer outcomes, revenue impact, and the gap between intended value and realised value. If the leadership dashboard contains velocity charts, something has gone structurally wrong with how the organisation communicates about delivery.
The governance implication
Metrics are not neutral. They drive governance, which in turn drives behaviour. If you measure velocity, governance becomes about velocity — reviews focus on whether teams are hitting their velocity targets, and every conversation is shaped by that frame. If you measure outcomes, governance becomes about outcomes — reviews focus on whether customers are experiencing better results, and conversations shift towards impact.
The choice of metric is itself a structural decision that shapes how the entire technology function behaves. It determines what gets discussed in leadership forums, what gets escalated, what gets celebrated, and what gets challenged. A technology organisation that governs by activity metrics will optimise for activity. A technology organisation that governs by outcome metrics will optimise for outcomes. The metric is the message.
This is why measurement frameworks cannot be delegated to delivery teams or data analysts. The choice of what to measure at the leadership level is a strategic decision. It shapes the operating model. It determines what the technology function optimises for. Choose carefully, because whatever you measure is what you will get — and if you are measuring the wrong thing, you will get the wrong thing with extraordinary efficiency.
The bottom line
The question is not whether your delivery teams are productive. They almost certainly are. Engineers are working hard. Sprints are completing. Code is being deployed. The machine is running. The question is whether that productivity is connected to outcomes that matter — whether the effort, the investment, and the organisational energy being consumed by technology delivery are producing results that customers and the business can see, feel, and value.
If you cannot draw a direct line from the metrics on your leadership dashboard to a customer or business result, you are measuring the wrong thing. And if you are measuring the wrong thing, you are governing the wrong thing. And if you are governing the wrong thing, the entire technology function is optimising for a target that does not matter. Fix the measurement, and the governance, the behaviour, and the outcomes will follow.