DORA: From DevOps experiment to industry-defining metrics
Forget vanity metrics and fuzzy productivity measurements. DORA metrics, born out of a direct need to link software delivery to business impact, have become the gold standard for technical leaders. The initiative started over a decade ago with one question: What does high performance in software engineering really look like, and how can you prove it? This wasn’t just academic curiosity.
In the early 2010s, as DevOps took off, teams struggled to measure their effectiveness without falling back on gut feeling or output-based proxies. Dr. Nicole Forsgren, Gene Kim, and Jez Humble set out to change that, launching DORA (DevOps Research and Assessment) and delivering the first State of DevOps Report in 2014. Their work was about one thing, objectivity, and it became the empirical foundation for how we now link engineering practices to real business results. By 2018, their research, productized and popularized through the book Accelerate, had spread globally and was acquired by Google, making DORA metrics not just insightful, but inescapable.
The impact? DORA metrics quickly became the lingua franca for engineering organizations intent on removing bottlenecks, benchmarking against the best, and driving relentless improvement, a framework so robust that even regulated industries have adopted its principles.
Why your team can’t afford to ignore DORA in 2025
If you think DORA metrics are just a DevOps thing, it’s time to update your model. In 2025, DORA metrics sit at the intersection of technical capability and regulatory requirement:
- In technology: They define elite software teams by deployment frequency, change lead time, failure rate, and recovery speed. “High performers” deploy code to production multiple times a day and can recover from failures in under an hour (State of DevOps Report).
- In financial services (EU): DORA now means the Digital Operational Resilience Act, a sweeping regulation demanding organizations track, improve, and report digital resilience. Compliance is mandatory and includes metrics like incident response time, system uptime, third-party performance, and live scenario-based testing (EIOPA DORA summary).
What’s changed? Two things: scope and urgency. Software engineering metrics are now integral to risk management and regulatory reporting. In the EU, non-compliance isn’t an option, it’s a legal risk.
The evolution: DORA metrics aren’t standing still
Today’s DORA metrics are lightyears from the early “four keys.” Engineering leaders now face a landscape shaped by:
- AI-powered, real-time analytics: Machine learning platforms spot bottlenecks, predict failures, and recommend optimizations before incidents happen (Waydev on AI in DORA).
- Expanded definition of “performance”: Modern dashboards don’t just show deployments and outages, they measure developer experience, burnout risk, and even workflow friction, integrating both DORA and frameworks like SPACE.
- Cross-pollination between DevOps and compliance: Operations and engineering teams are converging; metrics are now a mutual language across technical and governance domains.
Leaders who don’t know how to interpret these numbers, or only use them for superficial scorecards, are missing the point.
What engineering leaders get wrong about DORA
The data is clear, but the interpretation often goes awry. Many organizations, eager to optimize, fall into common traps:
- Chasing metrics, not outcomes: As BlueOptima’s research points out, teams can “game” DORA metrics, for example, by splitting work into tiny PRs or superficial deployments, without any real improvement in system resilience or customer value (DORA Metrics: Strengths and Weaknesses).
- Ignoring context: DORA metrics work best in high-cadence, DevOps-focused environments. Legacy, waterfall, or highly regulated teams may need supporting frameworks, and metrics must be calibrated accordingly.
- Letting compliance drive culture: As DORA regulation expands, especially in finance, there’s a real risk that metrics become a check-box for audits, losing their value as levers for continuous improvement.
Literal metric fixation (Goodhart’s Law in action: “When a measure becomes a target, it ceases to be a good measure”) leads to tunnel vision, gaming, and, ultimately, worse business results.
Regulations are pushing DORA from IT best practice to boardroom priority
The EU’s Digital Operational Resilience Act (DORA) is a game-changer, not just for banks, but for software organizations everywhere. Here’s what matters for your leadership strategy:
- Resilience isn’t negotiable: Boards must demonstrate continuous digital resilience, reporting incident response times, system uptime, and vendor compliance (BitSight’s DORA compliance checklist).
- Third-party risk just got real: Financial entities must track not only their internal metrics, but also those of their vendors and cloud providers. Vendor selection and contract language now hinge on provable resilience data.
- Information-sharing is mandatory: Threat intelligence and incident data must be collected and shared, meaning metrics agility is critical.
DORA compliance is driving investment in AIOps, automated resilience testing, and unified observability platforms. This isn’t theory, these are audit requirements.
Practical steps: what top technical leaders should do now
Ready to move from DORA theory to impact? Start here.
1. Assess your maturity, then automate everything
- Where are you on the DORA spectrum (elite, high, medium, low)?
- Inventory manual handoffs, deploys, recovery scenarios, aim for maximal automation.
2. Integrate metrics across domains
- Build dashboards that aggregate DORA, developer experience (e.g., SPACE), and risk metrics.
- Connect engineering metrics to business risk for the board, break down silos between ops, finance, and compliance.
3. Map metrics to outcomes
- Don’t use DORA numbers as a stick or badge.
- Set improvement targets tied to customer experience, security, and operational stability.
4. Train teams against gaming
- Educate teams and managers on Goodhart’s Law.
- Build a culture of learning, not blame; investigate the “why” behind the numbers.
5. Prepare for regulatory scrutiny (if in scope)
- Understand upcoming deadlines, reporting requirements, and scenario-test drills under DORA.
- Evaluate vendors and cloud providers for their own resilience and DORA reporting readiness.
Beyond compliance: how DORA can give your organization a real edge
Stop thinking about DORA as a reporting hassle or a DevOps-only tool. Used strategically, DORA metrics can:
- Unlock meaningful benchmarks to measure and motivate improvement.
- Identify invisible bottlenecks before they become showstoppers.
- Foster transparency and trust between engineering, business, and risk functions.
- Power incident learning and real, data-driven risk reduction.
- Give you a competitive edge, customers, regulators, and investors all want measurable resilience.
Future-facing engineering leaders use DORA not as a scoreboard, but as an engine for sustainable excellence in both software delivery and operational health.
Resilience is the new velocity: what will your metrics say next year?
DORA metrics are no longer optional, nor static. In 2025, they’re the connective tissue between high-performing technical teams, regulatory trust, and competitive advantage. Whether you lead a platform squad or a globally regulated enterprise, your ability to measure, interpret, and improve these metrics will define your success.
It’s not about chasing the next deployment trend or passing yet another audit. It’s about building organizations that learn, adapt, and outpace systemic risk, on your terms. The next chapter of DORA will be written by leaders who use metrics to drive meaning, not just motion.
