I am a massive fan of the DORA metrics. I use them every single day. I use them to evaluate how well my teams perform, to spot bottlenecks before they become fires, and to have honest conversations with leadership about where we actually stand. But here’s the thing nobody wants to admit in 2026: DORA alone is no longer enough. It’s capturing your deployment pipeline while completely ignoring nearly half of what your developers actually do all day.
Let me break this down.
The DORA Foundation Still Matters
DORA gives you four metrics. Deployment frequency, which is how often code ships to production. Lead time for changes, meaning the time from commit to production. Change failure rate, the percentage of deployments causing production failures. And mean time to recovery, how long it takes to restore service after something breaks.
You can see all of these metrics right inside your sprint board. Whether you’re running Kanban, Scrum, Jira, or whatever tool your org has standardized on. Deployment frequency shows up when you track how long a story sits in the „resolved“ column waiting for someone to review it and push it out. If stories are piling up in resolved for days, that’s your first red flag. The team isn’t reviewing fast enough. A story isn’t done when the PR is up. A story is done when it’s in production and creating value for the customer.
If deployment frequency is painfully low, it usually means the team is scared to ship. And I get it. Nobody wants to be the person who takes down production on a Friday afternoon. But fear-driven engineering is slow engineering. The fix isn’t to tell people to „just deploy more.“ The fix is to build the safety nets that make deploying feel safe. Set up unit tests, integration tests, end-to-end tests. Introduce canary deployments where you roll out with 0% of traffic, run your E2E suite against that canary, then slowly bump it to 10%, then 20%. If errors spike, roll it back automatically. The team doesn’t need to have a heart attack every time they push code because the system catches problems before customers ever see them. And even when something slips through, you have the metrics to prove the blast radius was tiny and the rollback was fast.
Mean time to recovery is genuinely hard to measure well. We do it with restore tests. We spin up the entire app and the infrastructure underneath it from scratch and measure how long it takes. Right now we can do it in about 40 minutes, including ordering new cloud services which always adds some lag. If it takes longer than that, your runbooks need work. You need step-by-step documentation that tells an on-call engineer exactly what to do in what order. Every team member should run through the restore process at least once so they have confidence when that 3 AM page comes in.
Change failure rate is the trickiest one. Random failures happen all the time because of your dependencies, because of infrastructure flakiness, because some VM decided today was a good day to act up. You can’t always draw a clean line between „this deployment caused the failure“ and „the database decided to be slow for no reason.“ Sometimes there’s a correlation between a rollout and a spike in alerts, but correlation isn’t causation. Track it, watch the trends, but be very aware that you’re going to get false positives.
Where DORA Falls Apart
Here’s where it gets interesting. DORA has real gaps, and they’ve been hiding in plain sight.
47% of development time goes to communication and coordination activities. That’s nearly half the workday spent in meetings, Slack threads, cross-team negotiations, and chasing down dependencies. In large organizations, this communication overhead is both unavoidable and necessary. Every team owns their own domain, so you have to talk to the people responsible for the systems you depend on. You have to push them to deliver what you need. You have to escalate when things are stuck. This can easily eat 50% of your day and DORA says absolutely nothing about it.
Developer experience, cognitive load, and satisfaction are completely invisible to DORA. The only way to measure these is to actually talk to your engineers. Ask them what they’re doing all day. If the answer is „I don’t know where things are, the system is too complicated, it takes forever to find bugs, and I keep working on things that aren’t even my team’s responsibility,“ that’s a screaming indicator that developer experience has gone off a cliff. As a senior engineer, this is where you step in. Simplify the system. Talk to other teams and push them to own the functionality they provide. A team should never reimplement what another team already built and maintains. And if no solution exists yet, go to your leadership and convince them to build one that helps every team across the org. Leaders often don’t know about these problems until someone raises the flag. This is also, by the way, exactly the kind of work that earns promotions.
Code quality beyond test coverage is another blind spot. I actually think this criticism of DORA is a bit overstated because you can measure quite a lot with SonarQube. How many TODO comments are rotting in your codebase. How many vulnerabilities and security findings you’re carrying. How many linter violations exist. What your cognitive complexity numbers look like. We can absolutely measure code quality to a meaningful degree. It’s just not part of the DORA framework itself.
Business value of features delivered is completely ignored. Sometimes a single-line change saves the business $50 million a year. Other times a team spends two weeks building infrastructure-as-code that’s essential for reliability but doesn’t directly move a revenue needle. DORA treats both the same, and that’s a problem.
The last gap is collaboration overhead and context switching. In a big organization running „agile“ (heavy air quotes), you’ve got meetings scattered across every day. Your lead time for changes metric tanks not because the engineering is slow but because developers can’t get four uninterrupted hours to actually think. DORA sees the slowdown and misinterprets the cause entirely.
Enter the SPACE Framework
This is why researchers from GitHub, Microsoft, and the University of Victoria developed the SPACE framework back in 2021. It measures five dimensions that DORA doesn’t touch.
Satisfaction and well-being. Developer happiness, fulfillment, and health. This drives retention, motivation, and creativity. Burnout, toxic culture, and poor work-life balance directly crush long-term productivity. If you’re a leader, you need to include this in performance reviews. We do it for our senior managers and directors because we know that people perform dramatically better when they feel psychologically safe. And honestly, this is what I cannot understand about the big tech companies running aggressive PIP programs where people get fired constantly and expectations are impossibly high. Engineers in those environments have genuine anxiety and sometimes even panic attacks, and they stay because the money is great. But if you actually care about team performance, you care about well-being first.
Performance and effectiveness. This goes beyond output volume to include quality and impact. It means every task should have a business value attached to measure the impact of the change. Most organizations struggle with this because how do you even define effectiveness? Is it fewer people delivering the same project? Is it less time to delivery? Is it some correlation of people times time? There’s no clean answer.
Activity levels. Coding, testing, debugging, collaboration. Understanding activity patterns helps you find bottlenecks. But measuring this is brutally hard. How do you measure pair programming? How do you measure the conversation that happens at someone’s desk? You can check how many bug tickets move through your board, but that doesn’t capture the full picture. You can send questionnaires and talk to engineers, but you’re never getting exact numbers.
Communication and collaboration quality. Poor communication causes 57% of project failures. This is where senior engineers and managers earn their keep by bridging teams and stakeholders, gathering requirements, and making sure information flows correctly. I see it constantly. A product owner gets a new requirement from leadership but never passes it to the engineering team. Information just evaporates. It absolutely belongs in a measurement framework but good luck getting a clean number.
Efficiency and flow. Uninterrupted focus time, the ratio of productive work versus waiting time. Most teams find their efficiency hovering between 15% and 25%. That means 75% to 85% of time is spent waiting. You see this clearly in Kanban environments. When stories keep bouncing back to „on hold,“ your flow is terrible. DORA partially captures this through lead time for changes, but it doesn’t tell you whether the bottleneck is PR review, dependency waits, or poorly defined stories. SPACE calls this out explicitly.
DX Core 4: The Unified Framework
All these frameworks got synthesized into DX Core 4, which combines DORA, SPACE, and DevEx research into a practical system you can actually deploy in weeks instead of months. It measures four dimensions: speed (DORA velocity metrics), effectiveness (developer experience index as the cornerstone), quality (code quality, stability, maintainability), and business impact (value delivered to customers).
The developer experience index is a composite score from 14 standardized survey items covering code quality, focus time, CI/CD processes, and more. The research says each one-point increase in the DXI saves 13 minutes per developer per week. That’s 10 hours annually per engineer. And top-quartile DXI teams show 4-5x higher performance across speed, quality, and engagement.
I believe these metrics genuinely improve productivity. But here’s the hard part that nobody talks about: identifying the actual shortcomings in your teams is the most crucial step, and it’s the one that’s nearly impossible to automate. Some of these metrics you simply cannot measure without sitting down with your engineers and having real conversations. And sometimes you can’t fix the problems even when you find them. How do you speed up a dependency team that won’t deliver? You can raise awareness. You can escalate. But at the end of the day, they decide their own priorities.
The best you can do is raise awareness of all these metrics, put everything into a central monitoring system, build a clean dashboard, and run regular retrospectives where engineers tell you what’s actually going wrong.
The AI Elephant in the Room
Now let’s talk about the thing that’s making all of this exponentially more complicated.
84% of developers are using AI tools in 2026. AI now writes 41% of all code. Developers report saving 30% to 60% of their time on coding, testing, and documentation. Specific tasks like code restructuring and test writing show up to 90% speedup. So our previously mentioned metrics are going through the roof. Coding and delivering features has never been this easy or this fast. Velocity is up like crazy.
But the quality numbers are terrifying.
Code churn is expected to double in 2026. Code duplication is up 4x. Purposeful refactoring dropped from 25% to under 10% of changed lines between 2021 and 2025. Copy-pasted clone code went from 8.3% to 12.3%. And delivery stability already decreased 7.2% according to Google’s 2024 DORA report.
The code duplication part is what scares me the most. In large codebases, the AI has no idea what shared libraries you’ve already built. So it reinvents the wheel over and over and over again. And the reviewer? The reviewer doesn’t care. The reviewer is looking at whether the ticket is done and the feature is delivered, because that’s the metric we’re all measured on. Our unified framework is actually encouraging us to ship bad code faster.
But we have tools to fight this. SonarQube can catch duplication. Add it as a quality gate in your CI pipeline and reject PRs that cross the threshold. It has never been more important to have hard quality guardrails in place. When AI is generating code at machine speed, you need machines checking that code at machine speed too.
The delivery stability drop has everything to do with teams not setting proper boundaries. They’re missing the tests we already talked about: unit tests, integration tests, end-to-end tests, canary deployments. Roll out a canary with 0% traffic, run your E2E suite, verify the new deployment works with your actual production config that can’t be replicated in staging, then slowly increase traffic while monitoring performance. If something’s wrong, roll it back. Most of these issues should be caught in development or staging, and I suspect most teams just don’t have these environments properly set up. That’s why stability is dropping.
Measuring AI Impact Separately
There’s a framework specifically for this: the DX AI Framework. It tracks three dimensions.
Utilization: tool usage and adoption rates. If you have an enterprise contract, you can see exactly how many tokens each developer is consuming across models.
Impact: time savings and developer satisfaction. This one is slippery. Sure, if an AI writes a batch script in 30 seconds, the developer saved real time. But how much time do they spend verifying that script actually works? Nobody measures the verification tax.
Cost: ROI and efficiency gains. This is where it gets really weird. These AI models aren’t cheap. Right now they’re subsidized through subscriptions where you pay $200 and get $5,000 worth of tokens. But that won’t last forever. At some point we’ll need to think about whether a developer is actually cheaper than the AI for certain tasks. Maybe you route the trivial work to cheaper models and save the expensive ones for genuinely complex problems. But measuring the actual ROI? Tracking which tasks were done by AI versus by a human? We’re nowhere close to having that figured out.
The 2026 Playbook for Engineering Leaders
Start with DX Core 4 to balance speed, effectiveness, quality, and impact. Measure flow efficiency to understand where time is actually being wasted. Track AI impact separately using the DX AI Framework, pairing quantitative data with qualitative surveys. Monitor code churn closely as AI adoption increases.
For platform teams specifically, measure flow time, sustained focus periods, friction points (both cognitive and systemic), throughput patterns from commit to deployment, and capacity allocation between new work and maintenance.
And please, for the love of all that is holy, avoid these pitfalls. Don’t optimize for a single metric because people will game it. Don’t measure output without quality because those are vanity metrics. Don’t ignore developer satisfaction because it’s the leading indicator of attrition. Don’t assume AI equals productivity without measuring carefully. And don’t forget that technical metrics must ultimately tie back to business outcomes.
The metrics game has changed. DORA was the foundation. It still is. But if you’re running a team in 2026 and you’re only tracking deployment frequency and lead time, you’re flying blind through a storm with half your instruments turned off. Layer in SPACE, adopt DX Core 4, and build a measurement culture that actually captures the full picture of what your engineers do all day. Not just the code they push, but the conversations they have, the waiting they endure, and the well-being that keeps them showing up tomorrow.
The teams that figure this out will run circles around the ones still pretending four metrics tell the whole story.