The gap between elite and average software delivery teams is not what most people think it is. The annual State of DevOps report gives you the headline numbers — elite performers deploy 973 times more frequently than low performers, recover from incidents 6,570 times faster. These numbers are accurate and almost entirely useless for a CTO trying to improve a specific team at a specific company in the next quarter.
Over the past three years, I've benchmarked delivery performance at 30 scaleups — Series A through Series C, ranging from 8 to 120 engineers. The gap I actually observed between the top third and the bottom third was not primarily about tooling, cloud provider, or engineering talent. It was about three specific organisational habits that either existed or didn't.
What the DORA Framework Actually Measures
For context: DORA measures four metrics across two dimensions — throughput (how fast you ship) and stability (how reliable what you ship is).
| Metric | What It Measures | Elite Benchmark | Industry Median |
|---|---|---|---|
| Deployment Frequency | How often code reaches production | On-demand (multiple/day) | Weekly to monthly |
| Lead Time for Changes | Commit to production, in hours | Less than 1 hour | 1 week to 1 month |
| Change Failure Rate | % of deployments causing an incident | Less than 5% | 15–30% |
| Mean Time to Restore (MTTR) | Time to recover from a failure | Less than 1 hour | 1 day to 1 week |
The trap is treating these as independent targets to optimise individually. They are not. They are consequences of a system. Pushing deployment frequency without also working on lead time and change failure rate just accelerates the rate at which broken code reaches production. The organisations that actually moved the dial worked on the underlying system, not the metrics themselves.
What I Found Across 30 Scaleups
When I benchmarked these teams, the companies sorted into three rough tiers with repeatable characteristics. The top third deployed multiple times per week, sometimes per day, with change failure rates below 10% and MTTR measured in hours. The bottom third deployed once every two to four weeks, with failure rates above 25% and MTTR measured in days.
The middle third — the most interesting group — had usually made partial investments in automation but hadn't yet achieved the compounding effect that comes from the full system working together.
What distinguished the tiers was not:
- The cloud provider or the CI/CD tool (GitHub Actions, GitLab CI, Buildkite — the top tier used all of them)
- The programming language or framework
- Engineering headcount (I had top performers at 15 engineers and low performers at 80)
- The amount spent on tooling
What distinguished the tiers was consistent across the sample.
Habit 1: The Deployment Pipeline Was Owned by Someone
In every top-tier company I benchmarked, there was a named human — a senior engineer, a platform team lead, a CTO — who considered the deployment pipeline their responsibility. Not a committee. Not "everyone." A person.
This ownership manifested in three observable ways. First, the pipeline had an SLA — someone cared if builds were slow, and slow builds were treated as a bug, not background noise. Second, when the pipeline broke, it was a P1. Not "we'll get to it after the sprint." A broken pipeline blocked the entire engineering team and got fixed before anything else. Third, pipeline metrics — build time, flakiness rate, deployment success rate — appeared on an engineering dashboard somewhere.
In the bottom tier, the pipeline was infrastructure that existed, not infrastructure that was operated. Build times had crept from 8 minutes to 22 minutes over 18 months and nobody had noticed because nobody was watching. Flaky tests had accumulated to the point where a 30% false-failure rate was accepted as normal, which meant the signal had been completely destroyed. Engineers were routinely bypassing the pipeline for "urgent" deploys.
A slow pipeline is a cultural problem disguised as a technical one
When a build takes 22 minutes, engineers stop running it locally. They push speculatively. They batch changes to amortise the cost. Batch sizes go up, lead time goes up, change failure rate goes up. The pipeline slowness is a root cause, not a symptom — and it compounds every week it is left unaddressed. The fix is not always technical: sometimes it's simply making pipeline performance a metric that someone is accountable for.
Habit 2: Production Incidents Were Treated as System Failures, Not Human Failures
The top-tier teams had a post-incident review process that was genuinely blameless and genuinely used. Not a policy document. An actual practice, where a written PIR appeared within 48 hours of a significant incident, identified systemic contributing factors, and produced at least one action item per incident that changed either code, process, or on-call configuration.
In the bottom tier, incidents were managed. The immediate problem was fixed. Occasionally someone wrote a Slack message about what happened. The system that allowed the incident was not changed. Six weeks later, a variant of the same incident occurred.
The compounding effect of this difference is dramatic. A team that runs 40 post-incident reviews per year and implements one system improvement per review is a fundamentally different organisation after 18 months than a team that fixes incidents without learning from them. The top-tier teams had clearly accumulated those improvements: on-call runbooks that were actually used, alerting configurations that had been tuned through real incidents, deployment rollback procedures that had been practiced.
The metric this produces is a lower Change Failure Rate and dramatically lower MTTR — not because the teams were more careful, but because they had systematically removed the conditions under which failures occurred.
Habit 3: Deployment Was Decoupled From Release
This is the single most underused lever in engineering delivery, and it explains more of the deployment frequency gap than almost anything else.
In the bottom tier, deployment and release were synonymous. When code was deployed, it was live for all users. This created natural pressure against frequent deployment: every deployment was a release event, every release event carried risk, and carrying risk frequently felt irresponsible. So deploys became infrequent, which made each deploy larger, which made each deploy riskier, which made deploys even more infrequent. The spiral is familiar.
The two models contrast sharply:
In the top tier, deployment and release were separated by feature flags. Code was deployed continuously to production, but features were released to users through a flag system — gradually, to a percentage of users, with the ability to disable instantly without a new deployment. A deployment failure in this model is a rollback of a small change. A feature flag mistake is a one-click disable, not a revert-and-redeploy cycle.
The infrastructure investment is modest: LaunchDarkly costs a few hundred dollars a month. Flagsmith and Unleash are open-source. The discipline investment is higher: every new feature needs to be wrapped in a flag, which requires a small amount of planning discipline. But the payoff is a team that can deploy a dozen times per day without sweating, because no single deployment is a high-stakes event.
The Measurement Trap
A specific caution about measuring DORA metrics without understanding what drives them.
I've seen engineering leaders set targets like "we will achieve elite deployment frequency by Q3" and then watch their teams game the metric. Deployment frequency goes up because engineers start deploying tiny, inconsequential changes. Lead time goes down because the definition of "deployment" is expanded to include things that don't actually deliver value. Change failure rate stays flat because nobody changed the underlying system.
The metrics are useful as diagnostic instruments. They tell you where you are relative to the performance distribution. They are not useful as management targets if they are not connected to the underlying habits.
Goodhart's Law applies here too
When a DORA metric becomes a target, it ceases to be a good measure of delivery performance. The goal is not to improve the metric — the goal is to build the organisational habits that high metrics are a consequence of. Measure DORA to understand your system. Do not set DORA metrics as KPIs for engineering managers.
The Cost of Staying in the Bottom Third
The framing I use with CEOs and boards is this: low delivery performance is not a developer experience problem. It is a business velocity problem.
When your engineering team deploys once every three weeks, your response to market feedback is three weeks slower than it needs to be. When your MTTR is two days, a production incident costs two days of revenue. When your change failure rate is 30%, roughly one in three deployments requires an incident response, which means a significant fraction of your engineering capacity is spent on remediation rather than value creation.
The business case for investing in the three habits above is not that your engineers will be happier — though they will be. It is that your product iteration speed will increase measurably, your incident recovery will be faster and cheaper, and your ability to respond to competitive pressure or regulatory change will be structurally better.
The gap between a team deploying weekly and a team deploying daily is not a 7x difference in delivery speed. In the product exploration phase, it is closer to a 7x difference in learning rate. And compounded over 18 months, that difference is often the difference between finding product-market fit and not finding it.
Where to Start
If I were walking into a new scaleup engagement tomorrow and the DORA numbers were poor, the sequence I'd follow is:
Not from gut feel. From deployment logs, incident records, and code review timestamps. The diagnosis has to be accurate before the intervention makes sense. Most teams are surprised by their own numbers when they measure properly.
Pull build time trends for the last 90 days. If average build time has grown or is above 10 minutes, treat it as P1. Identify the slowest stages — usually test suites or container build steps — and fix them before anything else. This is the fastest leverage point.
Don't wait for a big incident. Use the next three incidents, however small, to run a 30-minute written PIR. The discipline of the format is what matters, not the severity of the incident. Build the muscle before you need it for something serious.
Pick a medium-sized new feature and wrap it in a flag. Don't try to retrofit flags to existing features — start with something greenfield. The goal is to get the team comfortable with the workflow so it becomes the default for future work.
The metrics should have moved. If deployment frequency and lead time haven't improved, the pipeline work is incomplete. If change failure rate hasn't improved, the PIR process isn't producing action items. Use the numbers diagnostically, not punitively.
The Real Gap
The elite-vs-everyone gap in software delivery is not primarily a technology gap. The teams I've worked with that moved from the bottom third to the top third over 12 to 18 months didn't do it by buying better tools. They did it by making the pipeline someone's job, by treating incidents as system learning opportunities, and by decoupling deployment from release so that every individual deploy carried low stakes.
That's a harder thing to sell than "install this platform." It requires sustained organisational attention and a leader who is willing to make those habits non-negotiable. But the compounding returns — faster learning, lower incident cost, genuinely higher team morale — are among the highest-leverage investments an engineering organisation can make.
The gap is simple. Closing it is not easy, but it is very achievable.
If you're a founder, CEO, or engineering leader looking at delivery performance that isn't where it should be, let's talk — a focused delivery performance audit typically identifies the two or three highest-leverage interventions within the first two weeks, and I've yet to find a team where meaningful improvement wasn't achievable within a quarter.