DX Core 4: the framework for measuring developer experience
Length:
6 min
Published:
June 9, 2026
What is DX Core 4?
DX Core 4 is a framework for measuring developer experience and engineering productivity across four dimensions. It was published in 2024 by the team behind DORA, SPACE, and the original DevEx research, and it folds those earlier models into one practical system that an engineering leader can actually report on.
The four dimensions are:
- Speed: how fast work moves from idea to production. Think delivery throughput and lead time, not lines of code.
- Effectiveness: how easily developers get work done. Time lost to waiting, context switching, unclear requirements, and broken tooling.
- Quality: how reliable the output is. Change failure rate, incidents, and the share of time spent firefighting instead of building.
- Impact: how much of the engineering effort reaches the business. The percentage of capacity that goes into customer-facing value rather than maintenance and overhead.
The point of having four dimensions is balance. Push only on speed and quality slips. Optimise quality alone and delivery stalls. DX Core 4 forces you to look at the tradeoffs together, the way the business actually experiences them.
In plain words
Most "developer productivity" numbers measure activity, not value. Commits, story points, and hours tell you people are busy, not that the right things are shipping. DX Core 4 swaps activity for outcomes and looks at them from four angles at once: are we fast, is the work smooth, is it reliable, and does it reach customers. Each dimension pairs a hard metric (from system data) with a perceptual one (from a developer survey), so the number and the human reality stay connected.
Why it matters for engineering leaders
Engineering is usually the largest and most expensive function without a clear productivity number, which makes it hard to defend headcount, justify tooling spend, or explain a slow quarter to the board. DX Core 4 gives you a defensible answer.
The framework matters for three concrete decisions:
- Where to invest. A low effectiveness score points at friction (slow builds, flaky tests, approval bottlenecks) that you can fix with budget rather than pressure. You stop guessing which improvement pays off.
- Whether a change worked. Roll out a new CI pipeline, an AI coding assistant, or a platform team, and the four dimensions tell you if speed went up without quality going down. Investments stop being acts of faith.
- How to talk to the business. Impact translates engineering work into the language leadership already uses. "62% of our capacity reaches customers" is a board-level sentence; "we closed 340 tickets" is not.
The original research links a strong developer experience to faster delivery, lower attrition, and higher retention. The number itself is less important than the trend and the conversation it starts.
How to start measuring
You do not need a data platform to begin. A useful first pass takes a few weeks.
- Run a developer survey. Ask teams to rate the perceptual side of each dimension: how often tooling slows them down, how confident they are in deploys, how much time goes to real product work. This is the fastest signal and the hardest to fake.
- Pull the system metrics you already have. Deployment frequency and lead time from your CI/CD, change failure rate from incidents, and a rough split of work into product versus maintenance. Use what exists before buying anything.
- Pick one headline metric per dimension. Resist the urge to track twenty things. One number per dimension keeps the report readable and the team focused.
- Report at the team and org level, never the individual. DX Core 4 is a tool for improving systems, not ranking people. The moment a metric is used to rate someone, the data turns to noise.
- Set a cadence and look at the trend. Measure quarterly, compare against your own baseline, and treat a single reading as a question, not a verdict.
If you want a deeper read of where the friction actually sits, a focused DX audit maps the full developer journey and tends to surface the issues a survey only hints at.
Common pitfalls
- Measuring people instead of systems. The fastest way to ruin the data is to put a developer's name next to a number. Teams will optimise the metric, not the work.
- Tracking too much. Twenty metrics is a dashboard nobody opens. Four dimensions, one or two metrics each, reviewed regularly, beats a wall of charts.
- Ignoring the perceptual half. System data shows what happened, not why. Without the survey you see a slow deploy but miss that it is caused by a manual approval step everyone dreads.
- Chasing the score. The goal is better delivery and happier developers, not a higher number. If the metric improves while teams feel worse, you are measuring the wrong thing or measuring it wrong.
- Comparing across companies. A "good" score depends on your context, stack, and stage. Compare against your own past, not someone else's benchmark.
Related articles:
- What is Developer Experience and why you should care - What DX means and how it changes the way your business works.
- The 5-Step Process and Benefits of a DX Audit - How we map the full developer journey to find where the friction sits.
- The ROI of Investing in Developer Experience - Why better DX is a smart business decision, not just a nice-to-have.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.