Short answer
You cannot measure developer productivity with one number. Use the SPACE framework: pick a few metrics across its five dimensions, combine short developer surveys with system data from your delivery tools, look at trends per team, and act on what you find. Never rank individuals on these metrics.
- 5 - SPACE dimensions of developer productivity
- 1 - metric is never enough: the authors warn against single measures
- 2 - data sources to combine: developer surveys and system data
- 90 days - a natural cadence for a short developer survey
Developer productivity is best measured with a balanced set of signals, not a single score. The SPACE framework, published by researchers from GitHub, Microsoft and the University of Victoria, groups those signals into five dimensions. Using it, leaders can see whether engineers are effective, sustainable and well supported, instead of counting commits that say little about value.
This guide is for CTOs, VPs of engineering and business leaders who need an honest answer to how to measure developer productivity. It covers which developer productivity metrics to track, how SPACE compares with DORA metrics and DevEx, six use cases where measurement supports a real decision, and how to report engineering productivity to a board without damaging trust.
Why single metrics fail
Every simple productivity number breaks when used as a target. Lines of code reward verbosity. Story points get inflated. Tickets closed reward splitting work. Even good delivery metrics can be gamed if they are tied to individual performance reviews. The SPACE authors put it directly: productivity cannot be captured by a single metric or dimension.
There is a second reason. Productivity has a human side that system data cannot see: interruptions, unclear priorities, slow reviews and burnout. Surveys reveal those causes before they show up as attrition or slower delivery.
The five SPACE dimensions
DimensionWhat it coversExample metricsSatisfaction and well-beingHow fulfilled, healthy and happy developers are with their work and toolsSurvey scores, intent to stay, burnout signalsPerformanceThe outcomes of the work, such as quality and impactChange fail rate, customer-reported defects, reliabilityActivityCounts of actions and outputsDeployments, pull requests, reviews (as context only)Communication and collaborationHow people and teams work togetherReview turnaround, onboarding time, knowledge sharingEfficiency and flowAbility to make progress with minimal interruptions and delaysChange lead time, focus time, hand-off wait time
A practical starting point is three to five metrics drawn from at least three dimensions, for example a satisfaction survey score, change lead time and review turnaround. Delivery metrics from DORA cover much of performance and flow already.
The most common question after choosing dimensions is which framework to use. DORA vs SPACE is a false choice. They answer different questions, and DevEx adds a third lens, so most engineering organizations end up combining parts of all of them.
Combine surveys with system data
- System data shows what happens: lead time, deployments, review times, incidents. It is objective but blind to causes.
- Surveys show why: friction in tools, unclear requirements, too many meetings. They are subjective but explain the numbers.
- Together they let you spot a problem in the data and understand it from the people closest to it.
Keep surveys short, perhaps ten questions, anonymous and stable over time. Ask about the friction points you can act on: build and test speed, review delays, environment setup, documentation, interruptions and clarity of goals.
The DevEx authors make the same point with two kinds of measure: perceptions, meaning how developers feel about their work, and workflows, meaning how systems and processes behave. Neither tells the whole story alone. Builds may look fast in your tools while developers still find them disruptive, because the wait always lands at the wrong moment. When the two disagree, treat that as the finding worth investigating.
For a decision maker, the useful part of that research is the direction. Protected focus time, understandable code, clear tools and quick reviews are all things leaders can change through priorities and budget. None of them needs developers to work longer hours.
How to report developer productivity to the board
Executives rarely need the full engineering dashboard. They need to know whether engineering can deliver the plan, what is getting in the way and what the next investment should be. A one-page view works well: delivery speed and stability from your DORA metrics, one developer experience score such as perceived ease of delivering software, and engagement or intent to stay.
Report the trend, not the raw number, and put a sentence next to each one explaining why it moved. Then link every movement to a decision: what you funded, what you stopped and what you expect next quarter. That turns engineering metrics from a status report into a basis for investment, and it removes the temptation to compare teams whose systems and constraints differ.
Measuring AI developer productivity
AI is now the most common reason leaders ask about developer productivity, and it is where perception and data can differ most. In a 2025 randomized controlled trial by METR, 16 experienced open-source developers took about 19 percent longer on tasks when AI tools were allowed, yet estimated afterwards that they had been about 20 percent faster. The authors caution that this describes one setting: early-2025 tools, mature projects the developers knew well. It does not show that AI tools fail to help in general.
At organization level, the 2025 DORA report, based on nearly 5,000 technology professionals, found 90 percent AI adoption and described AI mainly as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. It linked adoption to higher delivery throughput, with stability still a concern. The lesson for leaders is that neither licence usage nor self-reported speed is enough. Measure AI like any other investment, with a baseline first, then delivery, quality and developer experience together.
A 90-day rollout for leaders
Mistakes that destroy trust
- Using the metrics in individual performance reviews. Data quality and honesty collapse immediately.
- Ranking teams with different contexts against each other.
- Surveying without acting. Engineers stop answering when nothing changes.
- Measuring only activity because it is easy to collect.
- Ignoring well-being until attrition rises.
AI coding assistants make balanced measurement more important: activity metrics can rise sharply while quality or understanding drops. Our guide to managing engineers in the age of AI coding assistants covers how to adapt reviews and policies, and our article on global engineering teams covers the collaboration side for distributed teams.
Questions to ask your engineering leaders
Do we understand our developer experience?
- Which metrics do we use across the five SPACE dimensions, and why those?
- What did the last developer survey say were the biggest sources of friction?
- What did we change as a result, and did the next survey or the data improve?
- How do we make sure the metrics are never used to judge individuals?
- How is AI-assisted coding changing our activity and quality signals?
Engineering leadership
Want to measure productivity without gaming it?
We design a balanced SPACE and DORA measurement set with your teams, run the first developer survey and turn the findings into a 90-day improvement plan.
Sources
- The SPACE of Developer Productivity (ACM Queue, 2021)
- Publication page and authors (Microsoft Research)
- DORA software delivery performance metrics (dora.dev)
- DevEx: What Actually Drives Productivity (ACM Queue, 2023) (ACM Queue, 2021)
- DevEx in Action: A study of its tangible impacts (ACM Queue, 2023) (ACM Queue, 2021)
- Measuring the impact of early-2025 AI on experienced open-source developer productivity (METR, 2025) (ACM Queue, 2021)
- How are developers using AI? Inside the 2025 DORA report (Google) (ACM Queue, 2021)
Originally published at phpscientist.com.
Top comments (0)