Tech debt impact on engineering velocity: the DORA gap

The Four Keys

What DORA actually measures

DORA, the DevOps Research and Assessment programme (now part of Google Cloud), has been measuring software delivery performance annually since 2014. The four keys are the framework that has emerged as the industry-standard productivity instrument. Each measures a different dimension of delivery. The 2024 report groups respondents into four clusters that emerge from the survey data each year rather than being set in advance.

Cluster values from DORA, Accelerate State of DevOps 2024, p.13. Share of respondents: elite 19%, high 22%, medium 35%, low 25%. The medium cluster reports a lower change failure rate than the high cluster; DORA publishes the clusters as they emerge from the data, so the bands move between editions.

Why Debt Is the Bottleneck

The mechanism, in concrete terms

The metrics gap is not an artefact of measurement or process maturity alone. It tracks closely to accumulated tech debt because each of the four keys has a debt-sensitive failure mode. Deploy frequency falls when the cost of deployment is high because the deployment system is brittle. Lead time grows when changes require coordination across multiple poorly-decoupled systems. MTTR explodes when incident diagnosis requires reverse-engineering systems whose documentation has drifted. Change-failure rate spikes when test coverage cannot keep pace with the changing surface area of the codebase.

Each failure mode has a debt-shaped cause. A team can paper over individual failures with workarounds, on-call rotations, and heroic last-minute fixes, but the four metrics taken together expose the underlying debt because they all degrade simultaneously when the codebase deteriorates. This is why DORA scores have become a useful proxy for tech debt severity even though DORA itself does not explicitly measure debt.

DORA's 2024 report found that industry is rarely a predictor of delivery performance: high-performing teams appear in every vertical. What separates the clusters is how the system is built and run. Teams that keep investing in delivery-system hygiene tend to find each metric easier to move; teams that defer it find each metric harder to move as the debt compounds.

The Strategic Translation

What 182x means in product terms

A 182x gap in deployments per year sounds abstract until it is translated into product capacity. A low-performer team deploys somewhere between once a month and once every six months; an elite team deploys on demand, several times a day. The elite team can run product experiments, ship incremental fixes for a user-research finding, and respond to a competitor's release many times over while the low performer is still preparing a single release. The aggregated strategic capacity gap is enormous.

For a CEO evaluating competitive position, the DORA bands are a useful diagnostic. If the company's most relevant competitors are clustered in higher DORA bands, the velocity gap is itself a strategic position the CEO is fighting against, regardless of headcount or budget parity. The fix is not headcount; the fix is the structural tech-debt remediation that DORA scores are a proxy for. Hiring into a low-performer team often produces no measurable velocity gain because the bottleneck is not capacity.

For a CFO evaluating engineering spend, the DORA scores are a useful efficiency proxy. Two teams with identical opex lines can be operating at very different levels of effective capacity depending on their DORA band. The CFO who knows the team is in the low band has a defensible reason to fund a debt-reduction initiative rather than adding headcount; the dollar return on the debt initiative is typically larger and faster than the dollar return on hiring.

The Improvement Path

Moving up the bands

The first step up does not usually require expensive structural change. DORA's capabilities catalogue lists practices such as trunk-based development, continuous testing and deployment automation as drivers of delivery performance. Three operational changes cover a lot of that ground: trunk-based development with feature flags (replacing long-lived branches), automated test infrastructure that runs on every PR, and on-call ownership by the team that wrote the code (replacing centralised ops teams). None of them requires a major code rewrite.

The harder step is medium to high. Moving from monthly-to-weekly deploys into daily-or-better deploys requires structural changes to the codebase itself: service decomposition where the monolith blocks small-batch deployment, dependency-injection patterns where tight coupling prevents safe partial deployments, and observability investment so issues are caught in production within minutes rather than days. This is where the substantive debt work appears.

The transition from high to elite is genuinely hard and most teams never make it. Elite performance requires a culture of continuous deployment, mature progressive-delivery practices, and a codebase architected for high-frequency small-batch change. Few engineering organisations reach this band without sustained multi-year investment, and the band's defining characteristic is that debt accumulation is actively prevented through ongoing engineering hygiene rather than periodically remediated.

Cross-Reference

Velocity sits inside the business-impact stack

Velocity is the most visible business-metric impact. The companion pages cover the less-visible impacts: onboarding time-to-productive, cost of revenue (COGS), gross margin, and burn rate. The pitch pages translate velocity into stakeholder-specific framing: CFO, CEO, board.

For the engineering-practitioner version of the velocity story, including the specific tooling and patterns that move the four keys, see the sister site technicaldebtcost.com. The cicdcost site (a portfolio sibling) covers the CI/CD-specific cost arithmetic that intersects with the lead-time metric.

Field Notes

Frequently asked questions

Adjacent Reading