Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
DX’s Q3 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. Read the full report.
Scott: Welcome back to Engineering Enablement. This is part two of a three-part series on building 10x organizations by our Field CTO, Justin Reock.
Two months ago, DORA announced that its 2026 annual survey and report will be the last of its kind, as the team switches to more “qualitative and observational research”. Given that news, it feels like a pertinent time to revisit the history of the defining developer measurement framework, and where it fell short.
Over to you, Justin.
Justin: Part one made the case that the original 10x finding was about environments, not individuals. This week, I want to go through the four major measurement frameworks our industry has produced, in the order they appeared, because each one is a direct response to software industry progression and evolution.
If you walk into a typical engineering organization today and ask how they measure productivity, you’ll usually get one of three answers. They’ll tell you they’re “doing DORA.” They’ll tell you they’re “starting to use SPACE.” Or they’ll tell you they don’t measure it. All three answers are signals of where they sit on the maturity curve.
DORA: Powerful for DevOps, focused on software delivery
DORA metrics came out of the DevOps Research and Assessment program led by Nicole Forsgren, Jez Humble, and Gene Kim. They’re now more than a decade old, and they remain the most widely deployed framework in the industry.
DORA’s strength is that it’s prescriptive. It tells you exactly what to measure. Where it becomes limited is that it’s scoped almost entirely to the delivery pipeline. With the exception of some subcomponents of Lead Time for Changes, it tells you little about what happens before the merge to production, i.e., the developer experience, which is where most of a developer’s time actually goes.
This is not a direct critique on DORA, but rather a perspective on the limitations and blind spots of DevOps. I’ve been writing code professionally since the late 90s and I’m intimately acquainted with what the world looked like before DevOps. The toil of manual deployments. The friction of delivering artifacts to QA teams via the SneakerNet. DevOps has profoundly improved the way we work as software professionals.
Despite these clear advantages, a widely-accepted critique of DevOps, and by extension DORA metrics, is that they borrow too heavily from manufacturing. DevOps came out of the revolutionary Lean and Toyota Production System practices, and the factory metaphor is genuinely useful for many parts of software delivery. Work in progress, batch size, cycle time, flow efficiency, the idea that small batches moving through a stable pipeline produce better outcomes than large batches moving through an unstable one all map cleanly onto software, and DORA captures it well.
The metaphor breaks down at the workstation. A factory worker on an assembly line is, by design, doing standardized, repeatable work where the value being created is external and physical. A software engineer is doing the opposite. The work is non-standardized by definition: the value being created is cognitive, and the software engineer is what management research refers to as an opinionated knowledge worker: someone whose output depends not just on their hands, but on their judgment, context, and attention.
A factory metric like cycle time looks at the external value stream: code moves from idea to production through a pipeline, and we measure how fast it moves and how often it breaks. But there’s a second value stream running in parallel, invisible to any system metric, which I call the ’internal value stream.’ It’s what happens inside the developer’s head between the moment they pick up a task and the moment they ship it. Flow state, context switches, cognitive fatigue, all of that lives in the internal value stream, and none of it shows up on a DORA dashboard.
The other limitation is that the metrics are easy to game. Deployment frequency goes up if you split your PRs in half. Lead time goes down if you stop blocking merges on tests. Change failure rate goes down if you stop deploying anything risky. Any single-metric system applied to humans will be gamed according to Goodhart’s Law, and DORA is no exception. If you’re running DORA in 2026, run it correctly: as a balanced set of signals where moving any one number at the expense of the others is treated as a regression, not a win.
SPACE: Comprehensive, flexible, with no prescriptive metrics
SPACE arrived in 2021 from Forsgren, Margaret-Anne Storey, Brian Houck, Chandra Maddila, Thomas Zimmerman, and Jenna Butler. It was an explicit attempt to broaden the productivity measurement lens beyond delivery pipelines. The core insight of SPACE is that productivity is multidimensional and that any single dimension, measured in isolation, will mislead you.
SPACE is the right answer to the question “what dimensions matter?” but it’s the wrong answer to the question “what should I measure on Monday morning?” It’s a powerful normalization framework for designing your own measurement program and scaffolding your culture, but it’s not a measurement program itself.
The SPACE framework is arranged into five dimensions of Satisfaction, Performance, Activity, Collaboration, and Efficiency. It’s meant to help organizations categorize the metrics that matter to them into a balanced set of oppositional dimensions, creating the necessary tension between metrics that prevent gamification and promote a comprehensive understanding of productivity, and the continuous improvement thereof.
This gets us much closer to understanding both the experiential and systems metrics necessary to model developer experience and its relationship to developer productivity. The internal value stream, however, is highly nuanced and so the DevEx framework arrived to help provide a more granular look at this essential part of the throughput pipeline of software organizations.
DevEx: Developer experience predicts developer productivity
The DevEx framework, published in 2023 by Forsgren, Storey, Michaela Greiler, and DX cofounder Abi Noda, was the first to put developer experience on equal footing with delivery metrics. It balances three dimensions: feedback loops, cognitive load, and flow state. These are exactly the variables DeMarco and Lister identified in 1984, now operationalized as something you can measure across a modern engineering organization with a combination of survey and system data.
DevEx is the framework I most often see catalyze DevEx improvements, because it’s the first one that takes seriously what developers themselves say is slowing them down. Long build times, flaky tests, unclear ownership, broken local environments, the friction that doesn’t show up in a DORA dashboard but eats half the workweek.
DevEx’s limitation is that it’s heavily self-reported, and self-reported data alone is not enough to create cycles of continuous improvement around developer experience. It’s powerful to have a signal that, for example, “build times are slow.” Coupling that signal with system metrics that show actual build times allows for material improvement of the root problem.
This is the gap the Core 4 was built to close, while simultaneously distilling the best parts of DORA, SPACE, and DevEx into a single unified framework for improving developer experience and increasing productivity.
Core 4: The distillative framework with prescribed metrics
The DX Core 4 is not a replacement for DORA, SPACE, or DevEx. It’s a distillation. If you’re running Core 4, you’re running pieces of all three.
Core 4 organizes measurement into four dimensions, each with one primary metric and a few supporting ones.
The first is Speed. The primary metric is weighted PR Throughput, sometimes called PRs per engineer. This is the most controversial choice in the framework, and we (DX) have always been clear that it must never be applied at the individual level or tied to performance reviews. As an aggregate signal of flow through the system, balanced against the other three dimensions, it works.
The second is Effectiveness, measured by the Developer Experience Index, or DXI. This is a single aggregated score from fourteen standardized survey items covering everything from code review quality, to focus time, to confidence in the deployment process. The DXI is where DevEx gets folded into Core 4, and provides an anchor for continuous improvement of various aspects of developer experience.
The third is Quality, measured by change failure rate or defect ratio, which is borrowed directly from DORA and serves as the counterweight to Speed. If Speed goes up and Quality goes down, you don’t have a 10x organization, you have a fragile one.
The fourth is Impact, measured by the percentage of engineering time spent on new capabilities versus keep-the-lights-on work. This is the metric that translates engineering investment into business outcomes. A team that’s shipping fast, has a happy developer base, and a low change failure rate, but spends 80% of its time on toil, is not a 10x organization.
Implementing Core 4 at different maturity levels
Because the Core 4 blends the strengths of its predecessor frameworks, organizations can stand on the shoulders of giants and adopt a comprehensive measurement strategy at any existing maturity stage.
If you’re not measuring anything today, you can start with the DXI and the minimum viable system signals necessary to calculate DORA metrics.
If you’ve been running DORA for a year or more and your leadership is asking what else matters, layer DevEx on top through a survey instrument like the DXI.
If you’re ready to brief a CFO or a board on engineering performance and want something defensible top-to-bottom, the Core 4 is the framework with the cleanest line from engineer friction all the way through to business impact.
What you should not do is invent your own framework from scratch. We have forty-one years of cumulative research starting from the Coding War Games and ending at Core 4. None of it is hypothetical anymore. The frameworks exist. The benchmarks exist. The choice is which one to start with, not whether to start.
Next week, in the third and final installment, I’ll close the series with the operational piece: what it actually looks like to run one of these frameworks across an engineering organization, the failure modes to watch for, and the role AI is playing in changing which of these metrics matters most.
Until then.
-Justin