You can hit every DORA target and still be losing ground. Deploy frequency up, lead time down, change failure rate and MTTR both healthy, but underneath it could be hiding an organization slowly getting worse at turning work into reliable software. New services shipping without clear owners, an attack surface widening faster than anyone is tracking, on-call rotations quietly filling up, a migration that was supposed to close last quarter still limping along. Delivery health still matters, and leaders should keep watching it closely, but it describes one part of a much larger system. Reading the health of the whole engineering organization takes a broader framework than four delivery signals can provide.
DRIVE is the broader framework. DRIVE does not replace DORA. It carries all four of DORA's signals inside it, adds the context leaders need to steer an entire organization broken into five pillars, Delivery, Reliability, Initiatives, Vigilance, and Efficiency, and pairs them with a recurring review that turns the readings into action.
Where DORA’s coverage ends
For most of software's history we measured the individual developer: how much they wrote, how fast, how they felt about the work. DORA moved the unit of measurement up a level, onto the delivery of software rather than the output of the people writing it. DORA's signals span two things well: how fast code moves, and how reliably it runs once it does. That work goes back more than a decade, to DORA's first State of DevOps study in 2014, and delivery performance has been the center of gravity of the research ever since. Its key signals, deploy frequency, lead time for changes, change failure rate, failed deployment recovery time, and deployment rework rate, have lasted because they measure outcomes rather than activity.
When writing code was a binding constraint, watching delivery and reliability told teams most of what they needed to know. However, that constraint no longer exists. Agents can now write, review, and merge code with little human involvement, and the slack that used to act as backpressure is gone. DORA's own 2025 research names the dynamic precisely: AI behaves as an amplifier, making the strong parts of a delivery process stronger and the weak parts weaker. When generation stops being the bottleneck, pressure relocates to the parts of the system nobody was watching closely: security exposure that widens as more code ships, cross-team initiatives that stall, and the cost of running an increasingly autonomous software factory.
DORA measures delivery well. The health of the organization around that delivery is what goes unmeasured.
How DRIVE builds on DORA
The design principle behind the DRIVE framework is addition. Every DORA signal is included, with additional critical metrics that are important for understanding the effectiveness of AI-accelerated organizations.
DRIVE: Delivery
Delivery keeps two DORA signals as critical metrics, deploy frequency and lead time, and adds a third: on-call pager volume. The first two describe the structural side of delivery, whether code moves through the system. Pager volume describes the human side, whether the people and systems orchestrating that movement can keep absorbing the output without wearing down. Deploy frequency tells you that you shipped fast this week. Pager volume tells you whether next week looks the same, or whether the pace is being borrowed against burnout.
Read the full Delivery deep dive here.
DRIVE: Reliability
This pillar carries two additional DORA signals, change failure rate and failed deployment recovery time, but reads them as secondary drill-downs. Its primary signals are functional SLO status and Sev0/Sev1 incident counts, the true breaches of the promises made to customers.
Where DRIVE goes further
Initiatives tracks progress on cross-team improvement programs. Vigilance watches security posture and vulnerability exposure, including the risk introduced by AI-generated code. Efficiency looks at how capacity splits between building new things and maintaining old ones, including token spend as agentic workflows scale.
DORA's fifth and newest metric, deployment rework rate, is defined as the share of deployments that turn out to be unplanned fixes, and is grouped with change failure rate as a measure of instability. The unplanned-maintenance side of rework shows up in DRIVE’s Efficiency pillar, where DRIVE measures the share of capacity spent on new work rather than keeping the lights on.
The OpEx review as a governance mechanism
A final distinction between DRIVE and DORA sits one level above the metrics, in the discipline that acts on them. A number changes nothing until someone is accountable for reading it and empowered to move resources in response. DORA produces a delivery reading, but DRIVE adds a forum to consume it: a recurring Operational Excellence review where the organization's most senior engineers read the whole system against the five pillars and reallocate time, people, and budget toward whatever has turned red.
The review is also what keeps the numbers honest. Any single one of these signals can be gamed, deploy frequency most easily of all, since splitting deploys to inflate a count is trivial. Read as isolated figures on a dashboard they invite exactly that; read as a set, in a room, with judgment applied, they are far harder to fake. The cadence and the human reading of it are the point.
Putting the signals together
Signal is often scattered. Deploy frequency lives in CI/CD, lead time in version control, on-call load in the pager, and DORA itself in whichever dashboard happens to track it. Assembling the org-level picture by hand is most of the work.
Cortex consolidates those sources into org-level Engineering Intelligence and powers the Operational Excellence review that turns them into action. One Skyscanner team used the DORA dashboard in Cortex to cut cycle time on a traveler-facing system by 50% from one quarter to the next.
To see where your organization stands across all five DRIVE pillars, the DRIVE maturity assessment is a practical place to begin.
