DX Core 4: finally! Opinionated developer productivity metrics that speak business
When DX announced another developer productivity framework, I must admit, I initially dismissed it. Like many, I’m fatigued by the industry’s tendency toward theoretical and often academic approaches to measuring developer productivity. My first thought was of the XKCD standards proliferation meme. But… I was wrong.
Source: xkcd comic on standards proliferation
DX Core 4 makes a refreshingly bold promise: here are the exact metrics you should use to measure developer productivity. No “it depends”. No lengthy workshops. No debates. No internal alignment docs to determine “what’s right for our business.” Just a very clear direction: measure exactly this.
Engineering leaders can breathe a sigh of relief. With overflowing inboxes and packed calendars, the last thing we need is more philosophical, ideological and emotionally charged debates about developer metrics—we have businesses to run and features to ship!
This article will explain:
what makes DX Core 4 unique
why it is unique compared to frameworks like SPACE and DORA
why this opinionated approach is exactly what engineering leaders need.
I’m very excited to see a framework bridge the gap between engineering metrics and business value and I’ll share why for developer productivity leaders this is a big deal.
Why another developer productivity framework?
The framework’s authors, who also authored SPACE and DORA, created DX Core 4 in response to a common question: “We’ve seen SPACE and DORA, but what’s the one way to measure developer productivity?” Like most engineers’, they’d historically answer “it depends.” But time after time they were pressed for an answer. Sure, the metrics might not be perfect, but if you had to choose a set to begin with what would it be? And so DX Core 4 was born as that starting point. Is it perfect? Probably not. But, is it a fantastic starting point for most organizations both large and small, sophisticated and not? Absolutely.
Without further ado, let me give you an overview of the framework:
Speed | Effectiveness | Quality | Impact | |
---|---|---|---|---|
Key metric | Diffs per engineer (PRs or MRs) | Developer Experience Index (DXI) | Change failure rate | % of time spent on new capabilities |
Secondary metrics | Lead time Deployment frequency Perceived rate of delivery |
Time to 10th PR Ease of delivery Regrettable attrition |
Failed deployment recovery time Perceived software quality Operational health and security metrics |
Initiative progress and ROI Revenue per Engineer R&D as % of revenue |
Source: Introducing the DX Core 4
At first glance, this might look like every other metrics framework. Possibly the inclusion of metrics like “diffs per engineer” might even make you want to throw your laptop out of the window. Yes, much ink has certainly been spilled over these types of developer “output” metrics like lines of code etc. And of course, those types of metrics can be abused. But stick with me for a second as there are some very compelling reasons for these exact metrics that I’m convinced will change your mind—as the reasoning changed mine, too.
Breaking down the DX Core 4 metrics
What makes DX Core 4 compelling isn’t only in what it measures, but how the metrics create “productive tension” with one another. And what’s even more exciting to me is how much the framework takes into consideration “flight levels” to ensure that these metrics resonate and are understood not only by engineers but are also understood by executives like CEOs and CFOs who might struggle to understand why DORA metrics like “lead time” matter in real terms.
Let’s break down each metric to understand what it means and why it matters.
Speed (Diffs per Engineer) tracks how quickly organizations deliver code changes. While controversial, this metric was chosen over technical measures like “lead time” because it is the most clear description that resonates with business stakeholders whilst also correlating strongly with delivery velocity. While diffs can theoretically be “gamed” by engineers who just arbitrarily make PRs smaller this is counter-balanced out by metrics such as effectiveness and impact that ensure changes are small and frequent but also impactful.
Effectiveness (Developer Experience Index) quantifies what engineering leaders intuitively know which is that developer experience directly impacts productivity. By surveying developers about friction points and tooling satisfaction, DXI transforms the fuzzy concept of “developer experience” into concrete data that business leaders can understand.
Quality (Change Failure Rate) is borrowed from DORA and serves as a critical counterbalance to speed. Shipping fast is great, but only if you don’t break things. Change failure rate tracks how often deployments cause problems to ensure organizations don’t sacrifice reliability in their pursuit of shipping fast..
Impact (Time Spent on New Capabilities) addresses one of software development’s most difficult and impenetrable challenges which is measuring business outcomes. While quantifying value on a feature, or even team level remains virtually impossible, we can track time spent on innovation versus maintenance. This proves to be a fantastic proxy for how much time engineers are spending on new value adding work as compared to just keeping the lights on.
At this point, you might be wondering how this relates to the other metrics that you’ve heard of like SPACE and DORA. Let’s quickly address that. While DX Core 4 builds on insights from DORA and SPACE, it takes a fundamentally different approach. Where SPACE offers a comprehensive theoretical model and DORA provides specific technical metrics, DX Core 4 is more prescriptive as it synthesizes years of research into a single practical playbook.
Why i’m excited about DX Core 4
With all of the above in mind, here are the reasons that I’m personally excited about the DX Core 4 and you should be too.
Moving beyond “vibes” to business value
The software industry has a long and complicated relationship with productivity metrics. You’d never measure a sales team based on “sales experience” so measuring a developer team on similar fuzzy metrics seems ludicrous. But the industry has been burned by crude measures like lines of code (KLOC) and the pendulum swung hard toward back to relying on “feels” and “vibes” which is frankly, unacceptable in today’s economic landscape. We must measure the business value of developers. It’s of critical importance to our business but it’s critically important for movements like platform engineering and developer experience to be perceived credibly by executives and leadership and continue to be funded rather than disbanded.
An opinionated starting point and no more “it depends”
DX Core 4’s greatest strength is its willingness to make hard choices. Instead of saying “here are all the things you could measure,” it boldly states “here are the four things you should measure.” I speak to so many engineering leaders who are truly overwhelmed. They have so many things to contend with and the last thing we need is more theoretics, I love that the DX Core 4 clearly states which metrics to start with. For many organizations I know this will be a huge step forward to creating alignment and re-focussing on more pressing matters.
Benchmarking
Finally, the framework enables meaningful industry comparisons by standardizing metrics across organizations. Without benchmarks, metrics exist in a vacuum. Is a 15% change failure rate good or bad? Should 40% time spent on new capabilities be increased? These questions need peer comparison for context. Being able to show executives how your metrics compare to industry peers is going to be far more compelling than showing improvements in isolation. This is really going to help developer experience teams to understand and justify investments into their platform and developer experience teams—something that I know first hand can be an incredible struggle when talking to non-technical stakeholders .
What next
The DX Core 4 represents a significant shift in how we approach developer productivity metrics. It’s a pragmatic synthesis of what works. For organizations looking to move beyond “vibes” and start measuring what really matters, and measuring the value of what they ship. The DX Core 4 provides a fantastic practical start point. It’s not perfect but it’s useful. And in a world where platform teams increasingly must justify themselves that’s exactly what we need.