£2.76 Million of Engineering. 5% Reached a User.

A global financial institution spent £2.76 million on engineering in one year. Roughly 5% of that showed up as features anyone could use.

The number comes from ClearRoute's State of the Route to Live 2026, drawn from four years of enterprise delivery assessments across financial services, retail, healthcare, media and technology. In the same body of work: one assessed organization took an average of 266 days to ship a business-critical feature, and 158 days to fix a critical production bug. At another, new engineers needed three to six months before they could make their first production contribution.

Two hundred and sixty-six days. Not to build something. To get it from finished to live.

The obvious limitation, before it gets used against the argument: this is assessment data. These are organizations that hired a delivery consultancy, which means they're organizations that already suspected something was wrong. That's a self-selected sample, and ClearRoute sells exactly the remediation its report recommends. Treat the specific figures as illustrative of a pattern rather than as an industry average.

The pattern is still the interesting part, because it predates AI entirely.

The 80% problem

ClearRoute's framing is that AI compressed roughly the 20% of the software lifecycle spent writing code, while the 80% covering testing, security, compliance, governance and release orchestration has not moved. Code reaches completion faster. Then it waits.

Their gap between the best and the rest is enormous and it's almost entirely about that waiting. Elite performers deploy many times a day against four times a year for laggards – around 250 times more frequently. Lead time of 24 hours against months. Mean time to restore under an hour against days. Change failure rates below 5% against 20%. And organizations heavy on manual testing and release management sit at 10 to 20% change failure rates while elite teams stay under 5%, deploying multiple times daily. Large enterprises, per ClearRoute, are 2.6 times more likely to take more than a month to ship.

Notice what none of those numbers are about. Not one of them is about how fast anyone writes code.

Shipping isn't the finish line

There's a maxim I've repeated to every team I've led: you don't measure value flow by when you ship. Value is when the user experiences it.

That distinction sounds pedantic until you watch what happens without it. Teams start counting features and release-note bullets, which is output, and they cram an interface full of things nobody asked for while genuinely believing they're maximizing value delivered. The counting feels rigorous. It measures the wrong end of the pipe.

The £2.76 million figure is what that looks like with a currency symbol attached. Nobody in that organization was idle. Engineers wrote code all year, and by every measure taken at their desks they were productive. The work existed. It was finished. And 95% of what it cost never became something a person outside the building could use, which means for practical purposes it didn't happen.

Value that a user never experiences isn't value that arrived late. It's cost.

The route to live is a governance artifact

This gets framed as an engineering problem, and that's where I'd push back.

The path from finished code to a live system is not primarily technical. It's testing gates, security review, compliance sign-off, change advisory boards, release windows, environment reservations, and approvals from people whose job is to say no when something looks risky. Every one of those exists for a reason. Most were added after something went wrong, by someone acting responsibly, and each one made sense on the day it was introduced.

That system was designed for control, and it is still doing exactly what it was designed to do. The 266 days aren't a malfunction. They're the intended output of a machine optimized to prevent bad things from reaching production, running exactly as specified – and the cost of the good things it also prevents from reaching production was never on anyone's ledger, because nobody has to sign a form when a feature is late.

There's a second-order effect here that makes it worse over time. When releasing is expensive, teams release less often, and when they release less often each release carries more change. A bigger release is riskier, harder to diagnose when it breaks, and slower to roll back – so it fails more visibly. And the organizational response to a visible failure is almost never to make releasing cheaper. It's to add a review step.

So the loop closes on itself. Delay produces batching, batching produces risk, risk produces gates, and gates produce delay. Every individual decision in that sequence is defensible and the aggregate is a system that gets slower every year while everyone involved behaves responsibly.

Which is why the manual-process correlation in the data matters more than it looks. Teams heavy on manual testing and release management run change failure rates two to four times higher than elite teams. The control apparatus isn't producing more safety – it's producing the batching that makes failure more likely.

What AI did and didn't do

ClearRoute's own summary of why the gap widened rather than closed: AI amplifies existing delivery systems. Mature platforms accelerate. Manual processes, fragmented tooling and governance bottlenecks create more work, faster.

That's the same conclusion Google Cloud's DORA research reached from a different dataset, and it lands hardest in this specific context. If your constraint is the approval path, then making authorship faster increases the volume of work arriving at the approval path. The queue gets longer. The batches get bigger. The thing you bought the tool to fix gets marginally worse while the metric you're watching gets better.

None of that is an argument against the tools. It's an argument about sequencing. Speeding up a stage that isn't the constraint has never produced throughput, in any system, and this is the oldest finding in operations management being rediscovered with a new vocabulary.

Where I'd start

Map the actual path, in calendar time, from a developer marking something done to a user touching it. Not the idealized pipeline diagram – the real one, including the Tuesday release window, the ticket that sits four days waiting for a security reviewer who's on holiday, and the environment that two teams share and one of them has booked.

Most organizations I've worked with have never measured this. They measure sprint velocity and cycle time to merge, both of which stop at the boundary where the trouble starts. If you can tell me how long it takes your team to write something but not how long it takes to release it, you've instrumented the fifth of the process that AI already improved.

Then count the gates and ask, for each one, what it prevented in the last year and what it delayed. Some will justify themselves immediately. Some were added after an incident in 2019 by a person who's since left, and they persist because removing them requires someone to accept responsibility for removing them – which is a much harder ask than leaving them in place. That asymmetry is why these systems only ever accumulate.

And stop reporting shipped as done. If your delivery metrics end at deployment, they end one step before the only step that produces value.

Somewhere out there a team spent a year building things and got 5% of the money's worth in front of a human being. Everyone on that team worked hard, wrote good code, and closed their tickets. The system did what it was built to do. That's the part that should bother you.