Deployment frequency is filed as an engineering preference. It is nothing of the kind. It is the rate at which the business is able to respond to a competitor, a regulator, or a customer who has just asked for something.
Ask a mid-market board how quickly the business can change its product and you will get an answer expressed in quarters. Ask the engineering team the same question and you will get an answer expressed in constraints — the release window, the testing cycle, the fact that the last deployment broke something and everyone is now more careful.
Both answers describe the same number, and almost nobody treats it as a business metric. It is one. It sets the upper bound on how fast the organisation can do anything that touches its systems, which in most businesses is now everything.
The gap is not incremental
The DORA research programme has spent more than a decade measuring software delivery through four indicators: how often you deploy, how long a change takes to reach production, how often a change causes a failure, and how quickly you recover when it does.
The spread between the best and worst performers is the part that tends to stop conversations. Elite performers deploy on demand, with lead times under a day and change failure rates around 5%. Low performers can take between one and six months to ship a single change, with reported failure rates of 46% or higher — in the weakest cases approaching two thirds.
5% vs 46%+
change failure rate for elite versus low-performing delivery teams — the difference between a routine release and a coin toss
That failure rate is the number worth sitting with. A team whose changes fail nearly half the time is not slow because it is careless. It is slow because it has learned, correctly, that changing things is dangerous. The caution is rational. It is the consequence of the failure rate, not the cause of it — and it is why “just release more often” is such useless advice.
Why this is a business conversation, not a technical one
The instinct in most mid-market businesses is that release cadence belongs to engineering, alongside language choice and tooling. That instinct survives because the cost of a slow cadence is diffuse and never appears as a line item.
It shows up instead as things that look like other problems.
A competitor ships something and you cannot answer for a quarter. That is recorded as a product strategy failure. It is a delivery constraint.
A regulatory change requires a system amendment, and the timeline is uncomfortable. That is recorded as a compliance risk. It is the same delivery constraint.
A large customer asks for something modest and is quoted twelve weeks. That is recorded as a commercial disappointment. Same constraint.
Changes get batched, because releasing is expensive. This is the one that compounds. Batching increases the size of each release, which increases the probability that something in it fails, which increases the caution, which increases the batching. The failure rate and the cadence are the same problem observed from two directions.
Large, infrequent releases are not safer. They are the same risk, accumulated and deferred, then taken all at once on a Thursday evening.
What actually moves it
The uncomfortable finding from the research is that the constraints are rarely the ones being discussed. Teams debate tooling and pipelines; the binding constraints are usually structural.
Whether a change can be tested without a full environment. If verifying anything requires the whole estate assembled, the cost of each change is fixed and high regardless of how small the change is. That single fact drives batching more than any other.
Whether a failed change can be reversed. Teams that can roll back in minutes behave differently from teams that cannot, because the cost of being wrong is different. Recovery time is not a disaster-recovery statistic; it is the thing that governs everyday appetite.
Whether approval is proportionate to risk. Many mid-market change processes apply the same governance to a text change and a schema migration, because the process was written after an incident and never differentiated. The result is that low-risk changes are expensive, so they queue, so they arrive in batches with the risky ones.
Whether anyone owns the number. Most organisations cannot state their current deployment frequency or change failure rate. Not because it is hard to measure — the data is in the deployment and incident records — but because nobody has been asked.
Four questions for the next board pack
- How many times did we change our production systems last month, and how many of those changes caused a problem?
- When something fails, how long does it take to get back to working — measured, not estimated?
- What is the smallest change we can make and release on its own, and what does that cost us?
- If a regulator or our largest customer required a change in three weeks, would we make it — and what would we skip to do so?
Two honest caveats
First, elite performance is not the target for most mid-market businesses. Deploying on demand suits organisations whose product is software. For a business where software supports the operation, the useful goal is usually not maximum frequency but a low failure rate and a short recovery time — being able to change things safely when it matters, rather than continuously.
Second, the measures themselves are under strain. DORA’s own researchers added a fifth indicator, deployment rework rate, on finding that change failure rate was largely acting as a proxy for rework. And where AI tools now generate a substantial share of committed code, the four keys alone no longer describe delivery performance accurately. Both are reasons to treat these as a diagnostic conversation rather than a scorecard.
The underlying point survives either caveat. The rate at which a business can safely change its systems is a business capability, it is measurable from data you already hold, and in most mid-market organisations nobody has looked.