How to Measure Developer Productivity in 2026: DORA, SPACE, DevEx and the DX Core 4

Sooner or later every engineering director gets the question from a CFO or a board: "how productive is the engineering team, and is the headcount paying off?" There is no honest single number to hand back, and the instinct to invent one is exactly how measurement programmes turn toxic. But "you can't measure it" is not an acceptable answer either - it cedes the conversation to whoever is willing to count the wrong things. This is a guide to measuring developer productivity in 2026 the way senior teams actually do it: with a small system of complementary frameworks - DORA, SPACE, DevEx, and the DX Core 4 that unifies them - rather than a leaderboard.

Diagram of engineering productivity pillars: speed, effectiveness, quality and business impact, spanning delivery metrics and developer experience

Can you actually measure developer productivity?

In August 2023 McKinsey published "Yes, you can measure software developer productivity" and set off one of the sharpest debates the field has had. Kent Beck and Gergely Orosz answered with a detailed two-part rebuttal, and their core objection is the one worth carrying into any measurement effort: McKinsey optimised for measuring effort and output instead of outcomes and impact. As they put it, "the earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences" (Pragmatic Engineer, 2023).

That is not a philosophical quibble. Beck recounts watching output-style scores at Facebook get "rolled up" until directors pressured managers and managers negotiated with individual contributors for better numbers - the metric consumed the behaviour it was meant to observe. So the honest answer to "can you measure it?" is: yes, at the level of teams and systems, if you measure several things that hold each other in check and you never turn them into an individual ranking. The moment a single metric becomes a target, Goodhart's law takes over and it stops measuring anything real.

Why lines of code and commit counts mislead

The metrics that are easiest to pull from a version-control system - lines of code, commit counts, pull requests per developer - are the ones that reveal the least. They measure activity, not value, and they are trivially gamed: a developer told that PR count matters will split one change into five. Worse, they punish exactly the work you want more of. Deleting 2,000 lines of dead code, mentoring a junior through a hard bug, or spending a day removing a deployment bottleneck all show up as low output while creating disproportionate value. Any framework built on raw activity counts is measuring motion and calling it progress.

DORA, SPACE and DevEx: what each framework measures

Three research-backed frameworks dominate serious practice, and they answer different questions rather than competing:

DORA measures delivery performance at the system level: deployment frequency and lead time for changes (throughput) balanced against change failure rate and failed-deployment recovery time (stability). It is the industry scorecard for "how well do we ship," backed by one of the largest ongoing studies in the field.
SPACE, published by Nicole Forsgren and colleagues, is a deliberate corrective to single-metric thinking. It spans five dimensions - Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow - and its central rule is that you should measure across several dimensions at once and never reduce productivity to one number.
DevEx, from the same research lineage (Abi Noda, Nicole Forsgren, Margaret-Anne Storey and Michaela Greiler, 2023), shifts the lens to the lived experience of the developer - the day-to-day friction that determines whether talented people can actually get work done (InfoQ, 2023).

DORA tells you about the output of the delivery system. SPACE reminds you to look at the human and collaborative dimensions too. DevEx explains why the numbers move. Used together they triangulate; used alone, each has a blind spot.

What does DevEx actually measure? Feedback loops, cognitive load, flow state

DevEx distils a large set of sociotechnical factors into three dimensions that engineering leaders can act on directly:

Feedback loops - the speed and quality of responses to a developer's actions. Slow CI, flaky tests, and multi-day code-review latency are all long feedback loops that quietly tax every change.
Cognitive load - the mental effort required to get something done. Sprawling services, poor documentation, and confusing internal tooling raise it; a well-built internal platform with paved paths lowers it.
Flow state - the ability to work with deep focus. Fragmented calendars, ambiguous priorities, and constant interruptions destroy it.

The argument for taking this seriously is economic, not sentimental: the DevEx authors note that "even a small reduction in wasted time, when multiplied across an engineering organization, can have a greater impact on productivity than hiring additional engineers." The market has noticed - Gartner found that 78% of surveyed organisations have a formal developer-experience initiative established or planned (InfoQ, 2023).

What is the DX Core 4?

The practical problem with running DORA, SPACE and DevEx side by side is that stakeholders drown in metrics and no two teams measure the same way. The DX Core 4, published in late 2024 by Abi Noda, Laura Tacho, Margaret-Anne Storey and Michaela Greiler, is an attempt to resolve that by encapsulating DORA, SPACE and DevEx into four counterbalancing dimensions (DX, 2024):

Speed - how quickly work reaches production (throughput).
Effectiveness - how well developers can actually do their work, drawn largely from DevEx.
Quality - the stability and reliability of what ships.
Impact - the share of engineering effort that reaches real business value rather than toil.

The design intent is the counterbalance: you cannot game speed without effectiveness, quality and impact exposing the cost. DX reports the framework has been deployed across more than 300 tech, finance, retail and pharmaceutical companies, with outcomes including a 3% to 12% increase in engineering efficiency and a 14% increase in R&D time spent on feature development. For a regulated Benelux organisation, that last figure is the one to internalise: most productivity gains come not from pushing people harder but from clawing back time lost to friction and unplanned work.

Does AI make developers more productive?

This is now the first question executives ask, and the data counsels caution. The 2025 DORA report, based on nearly 5,000 respondents, found that 90% of professionals use AI at work and most report productivity gains - but it also frames AI as "the great amplifier" that magnifies whatever discipline a team already has (Google Cloud / DORA, 2025). The prior year's data was blunter, tying AI adoption to a measurable drop in delivery stability (InfoQ, 2024). The lesson for measurement is direct: individual "AI made me faster" claims are worthless in isolation. If generated code raises change volume while quietly eroding stability, only a balanced framework - speed checked by quality, activity checked by outcome - will catch the trade before it reaches production.

How to start without breaking your team

Three principles separate a useful programme from a harmful one. First, always measure across balancing dimensions; a single headline number is an incentive to game, not a measurement. Second, improve against your own history, not an external benchmark - the goal is your trajectory, not a league position against companies with different constraints. Third, pair system metrics with developer-reported experience: the largest gap in most organisations is between what leaders assume the friction is and what engineers actually hit every day, and a quarterly DevEx survey closes it faster than any dashboard. Keep the results at the team and system level, never rank individuals, and treat the numbers as the start of a conversation rather than a verdict. Measured that way, developer productivity stops being a stick and becomes what it should be: a map of where the friction is, so you can go remove it.