The Metrics Gap Between Engineering and the Business

AI coding tools have added a new generation of productivity metrics: lines generated, acceptance rates, tasks completed faster, hours estimated as saved. But faster coding is not the same as a faster organisation. If an engineer produces code twice as quickly while review and release still take weeks, very little has actually changed at the level the business cares about.

This is where DORA's recent research is more useful than any single metric, because it reframes the question entirely. AI does not make an organisation productive on its own; it amplifies the system it runs inside. A strong engineering system compounds the gains. A weak one simply moves its existing problems faster. The relevant question stops being how much quicker is the engineer and becomes is this a system worth multiplying.

Seen that way, the unit of measurement matters as much as the metric. Goldman Sachs CIO Marco Argenti has described looking at productivity at the team level—how quickly work travels from an idea towards production—rather than at individual output. It is a small shift in framing with a large shift in meaning. The question moves from what did the developer produce to what became possible for the organisation.

That reframing also exposes the limit of the whole exercise. Every metric worth having becomes a target the moment consequences are attached to it, and targets get gamed, at the team level just as readily as at the individual one. "Idea to production" can be optimised by quietly redefining what counts as an idea. There is no altitude high enough to escape this. Which means the connection between engineering metrics and business value was never going to be a clean causal line you could draw on a dashboard. It is a judgement, made by people who understand the system, that good metrics inform rather than settle.

So engineering and the business do not need the same dashboard. They need to understand how their dashboards connect, and to treat that connection as a question to keep asking, not a number to declare solved. A drop in lead time matters when important work reaches customers sooner. Lower developer friction matters when the recovered capacity moves towards more valuable work. Better reliability matters when it reduces real operational risk.

The goal is not to replace engineering metrics with business metrics. It is to use the first to keep asking honest questions about the second.