You just joined a platform team. Or a DevEx team. Or someone said “developer productivity” in a meeting and now it’s your job. Either way, you’re staring at the same question everyone in this space eventually hits:
How do you measure something as squishy as “developer productivity”?
The good news: people have been thinking about this for years, and there are real frameworks. The bad news: no single framework captures everything, and the most important data is the kind engineers instinctively distrust.
Here’s the landscape.
DORA: the four metrics that started it all
DORA (DevOps Research and Assessment) came out of years of survey-based research by Nicole Forsgren, Jez Humble, and Gene Kim. Their book Accelerate (2018) is the canonical reference. The core finding: four metrics reliably predict software delivery performance.
| Metric | What it measures | Elite benchmark |
|---|---|---|
| Deployment frequency | How often you ship to production | On demand (multiple times/day) |
| Lead time for changes | Commit to production | Less than one hour |
| Change failure rate | % of deployments causing incidents | < 5% |
| Time to restore service | How fast you recover from failures | Less than one hour |
These are good metrics. They correlate with business outcomes. They’re hard to game individually (pushing deployment frequency up by shipping garbage will spike your change failure rate). And they give you a shared vocabulary – when someone says “we’re a low performer on lead time,” everyone knows what that means.
But. DORA measures the output of your software delivery system. It tells you how fast you ship and how often things break. It does not tell you why. It doesn’t tell you whether your developers are happy, blocked, or spending half their day fighting tooling. It doesn’t tell you whether code review is a bottleneck or a learning opportunity.
DORA is the dashboard on the car. Useful. Necessary, even. But it won’t tell you that the driver is exhausted.
The constraints-based approach
If you want to improve your DORA numbers, the Pragmatic Engineer newsletter frames it well: take a constraints-based approach. Three options:
- Algorithmic – the thing DORA (the company) commercially sells. Data-driven identification of bottlenecks.
- Value stream mapping – trace a feature from idea to production, find where time pools.
- “Ask what people are swearing at most often.”
That last one is a direct quote. And it’s often the fastest path to impact. Your developers already know what’s broken. They just haven’t been asked in a way that leads to action.
SPACE: what DORA can’t see
The SPACE framework came from a 2021 paper by Forsgren (again), Storey, Maddila, Zimmermann, Houck, and Butler. It was born from the realization that DORA measures systems, not people. And developer productivity involves both.
SPACE is an acronym for five dimensions:
| Dimension | What it captures | Example metrics |
|---|---|---|
| Satisfaction and well-being | How developers feel about their work | Survey: “How satisfied are you with your development tools?” |
| Performance | Outcomes of the work | Code review quality, customer impact, reliability |
| Activity | Observable actions | Commits, PRs merged, deployments, code reviews completed |
| Communication and collaboration | How people work together | Review turnaround, knowledge sharing, onboarding time |
| Efficiency and flow | Ability to do work without interruptions | Time in flow state, handoffs, wait time in CI |
The key insight isn’t the five dimensions – it’s the paper’s argument about what kinds of data you need to measure them.
There are two kinds of data:
- System data – what your tools can instrument. Commit timestamps, CI durations, PR cycle times, deploy frequency. Hard numbers. Easy to collect. Engineers trust this.
- Perceptual data – what developers actually experience. Whether code reviews feel blocking or educational. Whether CI wait times cause context switches. Whether the build system makes people want to quit.
You need both. This is the revelation that took me too long to internalize.
The key insight: system data alone is not enough
Here’s the example from the Pragmatic Engineer’s writeup that made this click for me:
System data may be able to tell you how long code reviews take. But without perceptual data, you won’t know whether reviews are actually blocking developers and slowing down development, or whether developers are receiving high-quality feedback.
Same metric. Two completely different realities. A 24-hour code review turnaround could mean “reviews are slow and blocking everyone” or “reviews are thorough and developers value the feedback.” The number alone can’t tell you which.
This is why surveys matter. And I say “this is why” with full awareness that most engineers – myself included – have an allergic reaction to the word “survey.” Surveys feel soft. Unscientific. Like management trying to quantify vibes.
But the SPACE paper argues (and I think correctly) that surveys are the only way to gather data about perceptions and behaviors. There are whole fields of study dedicated to doing this rigorously – psychometrics and industrial psychology. The survey your company sends out once a year with ten vague questions is not what these researchers are talking about. They’re talking about validated instruments with real statistical rigor behind them.
The companies that do developer productivity well – Google being the obvious example – collect both kinds of data and use them in complementary ways. System data tells you what is happening. Perceptual data tells you what it means.
Without system data, you’re guessing about reality. Without perceptual data, you’re guessing about impact.
Platform teams: the organizational pattern
Frameworks are nice. But someone has to actually build the tooling, maintain the systems, and own the developer experience. That’s where platform teams come in.
Adam Rogal, Director of Developer Platform at DoorDash, frames it cleanly in his interview with the Pragmatic Engineer:
Don’t bog down product engineers by mentoring them about unwritten quality standards. Create platform teams that provide clean and well-understood APIs and frameworks, and also own helping new engineers with the onboarding process.
The logic: if your quality standards are unwritten, they exist only in people’s heads. New engineers learn them through osmosis – meaning slowly, inconsistently, and at the expense of the senior engineers doing the mentoring. Platform teams encode those standards into tooling, templates, and guardrails. A good CI pipeline enforces more quality standards than any code review checklist.
This is the organizational complement to the measurement frameworks. DORA tells you how your delivery system performs. SPACE tells you how your developers experience it. Platform teams are the ones who actually improve both.
The broader industry pattern: Google’s internal developer ecosystem is widely regarded as the closest thing to “getting it right.” This is why ex-Google engineers keep trying to replicate parts of it at every company they join. But as the Pragmatic Engineer points out, most companies can’t commit to that level of investment. And there’s an integration problem – dev tools are hard to standardize across the industry because the integration layer between tools is where everything falls apart.
We don’t have a Google-scale solution for everyone yet. But platform teams, scoped to your organization’s actual pain points, are the practical starting point.
A reading list for the newly responsible
If you’ve been handed the developer productivity mandate and need to get smart fast, here’s the path I’d recommend:
The foundations:
| Resource | What you’ll get |
|---|---|
| Accelerate (Forsgren, Humble, Kim, 2018) | The research behind DORA. Why these four metrics and not others. |
| The SPACE of Developer Productivity (2021 paper) | The five-dimension framework. The system vs. perceptual data argument. |
| DORA Quick Check | Self-assessment against the four metrics. Good for establishing a baseline. |
The practitioner perspective:
| Resource | What you’ll get |
|---|---|
| Pragmatic Engineer: Developer Productivity: A New Framework | Constraints-based approach. The “ask what people swear at” insight. |
| Pragmatic Engineer: Platform Teams with Adam Rogal | How DoorDash structures their platform org. Practical patterns. |
| DevEx: What Actually Drives Productivity (2023 paper, Noda et al.) | Extends SPACE with focus on flow state, feedback loops, cognitive load. |
The deep end:
| Resource | What you’ll get |
|---|---|
| Google’s engineering practices docs | What “doing it right” looks like at scale. Aspirational but instructive. |
| Abi Noda’s DX newsletter | Ongoing research and practical insights on measuring developer experience. |
| Team Topologies (Skelton & Pais) | Platform teams as an organizational primitive. Broader than DevEx but directly relevant. |
Where to start measuring
You’re on a DevEx or platform team. You need to show impact. Where do you actually begin?
Week 1-2: Instrument what’s already there.
Your CI system, version control, and deployment pipeline already produce data. Extract it. DORA’s four metrics are a good starting set because they’re well-defined and your tools already have the raw data. Deployment frequency from your CD system. Lead time from commit timestamps to deploy timestamps. Change failure rate from incident tracking. Recovery time from alert-to-resolution.
Don’t build a dashboard yet. Just get the numbers. You need a baseline before you can show improvement.
Week 3-4: Ask the humans.
Run a lightweight developer survey. Not fifty questions. Five to ten, focused on the biggest pain points. The SPACE framework gives you dimensions to structure around, but honestly, the single most informative question is some variant of: What slows you down the most?
This is the “ask what people swear at most often” approach. It works because developers have strong, accurate opinions about what’s broken. They just need a channel that leads to action, not a suggestion box that leads to a Jira backlog.
Month 2-3: Cross-reference.
This is where it gets interesting. Your system data says code review turnaround is 18 hours. Your survey says developers don’t feel blocked by reviews. That’s useful – it means review time isn’t your bottleneck, even though it looked like one from the metrics.
Or: your system data says CI takes 12 minutes. Your survey says CI is the number one pain point. That means 12 minutes feels long to your developers – maybe because it breaks flow state, or because failures are opaque, or because they’re running it 15 times a day. The system metric alone would have told you “this is fine.” The perceptual data tells you it’s not.
Ongoing: Close the loop.
Measure. Identify the constraint. Fix it. Measure again. Show the before-and-after. This is how you build credibility for a platform team – not by shipping internal tools nobody asked for, but by demonstrating that you found what was hurting developers and made it better.
The frameworks are the compass. The work is still the work.