Beyond DORA Metrics: Why Engineering Leaders Need More Than Velocity
DORA metrics revolutionized how we measure software delivery. For the first time, engineering leaders had standardized, research-backed benchmarks for deployment frequency, lead time for changes, change failure rate, and mean time to recovery. The original DORA and SPACE research proved something counterintuitive: speed and stability aren't trade-offs. Teams can deploy frequently and maintain low failure rates. This was transformative. The industry moved away from vanity metrics like lines of code and embraced velocity as a legitimate measure of engineering health.
But there's a problem: DORA metrics measure outputs, not practices.
The Blind Spots of Velocity Alone
You can deploy frequently with terrible code review discipline. You can have a low change failure rate because you're only deploying trivial changes that touch no business logic. You can have fast MTTR because one hero developer is always on-call, working nights and weekends to fix incidents.
DORA tells you WHAT happened. It doesn't tell you WHY or HOW SUSTAINABLY. A team optimizing purely for DORA metrics might appear healthy on paper while accumulating hidden risk: skipped reviews, insufficient testing, poor incident documentation, unclear deployment gates. The burn-out might be invisible until you lose people.
This is why DORA alone is incomplete. You need a companion framework that measures the practices that enable sustainable velocity.
The Measurement Trap: Activity vs. Practice
The industry rightly abandoned lines of code as a productivity metric. But some engineering analytics platforms replaced it with equally shallow proxies: PR count, commit frequency, cycle time. These are better than LOC, but they're still activity metrics. High activity can mean high productivity OR high churn, rework, and thrashing.
A developer shipping five PRs per day might be highly productive. Or they might be shipping unfocused, poorly reviewed changes that downstream teams will have to rework. A team that takes three weeks per deployment might be slow. Or they might be enforcing rigorous quality gates that prevent production disasters.
Without understanding the practices behind the metrics, you're flying blind. This is where practice-level measurement becomes essential.
The Missing Layer: Practice Quality
What DORA needs is a companion layer that answers: Are code reviews happening AND are they thorough? Are tests running AND are they meaningful? Are deployments gated AND are the gates appropriate? Is incident response fast AND is it documented and improving the system?
Practice quality is the "how well" to DORA's "how fast." It's the difference between velocity that compounds and velocity that leads to burnout, technical debt, and brittle systems. When you combine DORA metrics with practice maturity, you get the full picture: are you moving fast sustainably, or are you trading long-term health for short-term speed?
A Framework for the Full Picture: 50 Protocols Across 6 Phases
At Concordance, we've mapped engineering practices across the complete software delivery lifecycle: Requirements, Design, Development, Testing, Release, and Operations. Each phase contains protocols that measure maturity—from foundational practices to advanced governance. Every protocol is scored 1-5, giving you a detailed view of where your team is strong and where improvement matters most.
Combined with your DORA metrics, this creates a complete engineering dashboard. You see not just velocity, but the quality and sustainability of that velocity. You can diagnose why lead time is high, why change failure rate is concerning, or whether your deployment frequency is genuine progress or a warning sign.
What This Means in Practice
A team with high DORA scores and low practice maturity is accumulating hidden risk. They're shipping fast, but they're likely building with weak foundations, poor governance, and mounting technical debt. They're optimizing for the metrics, not for the system.
A team with moderate DORA scores and high practice maturity is building on solid ground. Their velocity might be lower today, but they're compounding. They're investing in testing, documentation, and governance that will compound into sustainable speed.
The goal is both: high velocity WITH high practice maturity. That's velocity governance. That's engineering that scales.