Measuring developer productivity
What works (and what doesn't) when tracking developer productivity
“How productive is your team?”
If you’re an engineering manager, you’ve probably been asked this. And if your team isn’t clearly underperforming, answering can be tricky.
Measuring developer productivity is hard. Many frameworks have been invented to help, like DORA, SPACE, DevEx and now DX Core 4, but they often leave us with more questions than answers.
I’ve tested these frameworks at both startups and large companies. Here’s what I learned about measuring productivity.
If you enjoy posts like this, consider supporting my work and subscribing to this newsletter.
As a free subscriber, you get:
✉️ 1 post per week
🧑🎓 Access to the Engineering Manager Masterclass
As a paid subscriber, you get:
🔒 50+ templates and playbooks (worth $79)
🔒 A weekly "What would you do?" scenario & breakdown from real challenges EMs face
🔒 Full access to the complete archive
The Problem With Measuring Productivity
What is productivity, anyway?
Ask five people, and you’ll likely get five different answers.
Developers will say it’s time spent coding or the number of commits.
Managers will mention project delivery (speed & quality).
My view? How productivity is and should be defined depends on context.
A two-person startup team trying to find product-market fit should have a different definition of productivity compared to a 50-person team maintaining a massive codebase. The scope of team ownership relates to how productivity should be defined.
After years, I have found five key pillars that should be considered in any good productivity framework, no matter the size or team setup:
Speed: How fast can the team ship value?
Quality: Are we building reliable, maintainable code?
Business Impact: Does our work move the needle?
Individual Growth: Are team members learning and improving?
Care: Do people care about the work, the team, and the mission?
Frameworks That Tried to Solve It
1. DORA Metrics
Under pressure at a fast-paced startup, I implemented DORA metrics in our team. It promised data-driven answers by tracking:
Deployment Frequency
Lead Time for Changes
Change Failure Rate
Time to Recovery
As a result, we improved our CI/CD pipelines and sped up releases. On paper, the numbers looked great.
But then I saw some problems:
The team optimised for throughput. Focused on quick wins. Simple tasks that boosted metrics but didn’t add real value.
We all started burning out.
Key takeaway: DORA captures speed and quality in some ways but misses out on important areas like business impact, growth, and care and can create friction on the work the team is happy to tackle.
2. SPACE Framework
At a larger company, I wanted something that measured more than just speed. Something that factored in team well-being.
That’s when I found the SPACE framework.
Satisfaction & Well-being
Performance (of the software)
Activity
Collaboration & Communication
Efficiency & Flow
It felt more holistic. We mixed hard data with surveys, trying to balance people and performance. And it checked most of my pillars:
But SPACE had issues:
It was too broad. We spent months arguing over what to track.
Surveys led to vague answers. Different people read questions differently.
Comparing results over time became hard.
Key takeaway: SPACE highlights the human side but can get lost in complexity and still misses business impact.
3. DX Core 4: The New Contender (Is It The Answer?)
Then I found DX Core 4, released in December 2024. It aims to combine the best of DORA and SPACE.
It focuses on four dimensions:
Speed
Effectiveness
Quality
Impact
Finally, a framework that directly considers business impact.
Here’s a detailed view:
It is a refreshing change. DX Core 4 is clear about what to measure, no endless debates. It tracks everything from pull requests per engineer (controversial, I know) to deployment health and team sentiment.
Is it perfect? Too early to say. But it checks more boxes than previous frameworks.
So, What Actually Works?
Here’s what I’ve learned after years of testing these frameworks:
No one-size-fits-all solution. Every team is different. No framework can fully capture that (yet).
Mix data with human insight. Metrics alone don’t tell the whole story. Talk to your team.
Focus on outcomes, not outputs. Shipping lots of code doesn’t matter if it doesn’t help the business.
Avoid metric obsession. People will optimize for what you measure. Be careful.
Listen to your team. Motivation and alignment are hard to quantify, but they matter most.
How I Answer: “How productive is your team?”
When my manager asks, I go back to my five pillars and back them up with data:
Speed & Quality: DORA-style metrics
Business Impact:
Qualitative: Product Manager and engineer feedback
Quantitative: % time spent on new features (DX Core 4 inspired)
Individual Growth: Surveys & SMART goal tracking
Care: Team surveys and input from 1:1s
The result? A balanced view that respects data but values people.
Until there’s a framework I am happy with, my focus stays simple: Create an environment where great work happens.
Some useful links from me
👨💻 Become a better Software Engineer with CodeCrafters (use my partner link to get 40% off and build your own Redis, Git, Kafka and more from scratch).
🎯 Book a mock interview with me (System design or Behavioural & Leadership) to smash your next real interview!
👋 Let’s connect on LinkedIn!
Interesting read, thanks for sharing.
I'm with you in that I believe business impact is a massive one to measure. If anything, delivery of value to the business (and ultimately end users) is what really matters here. Business value can include things like:
- cost saving (e.g. optimising infra usage/cost)
- revenue growth (e.g. building features that drive customer acquisition or retention)
- reducing tech debt (e.g. making the systems more maintainable)
- improving operational efficiency (e.g. creating automations or enhancing tooling to reduce waste)
As you say, there's no one size fits all and that's the problem. Even with the above in mind, how would one quantify someone being more or less productive if they tackled tonnes of tech debt vs. shaving $1m off infra costs?
As for using PRs as a measure, I won't open that can of worms just yet.
Thanks for putting this review together, it’s very helpful.
I think that the most important place to start is by asking the most important question: “What problem are you trying to solve?” As you mentioned at the start, different people will have different answers.
The problem is that whatever system you end up using, is the system that everyone will latch on to. So, how you frame and communicate the metrics is extremely important.
In my mind, one of the key pillars is different than the others: Business Impact.
All the other pillars are upstream of Business Impact.
- Slow to deliver? Then slow to create business impact.
- Low quality? Then less business impact.
- Doesn’t provide individual growth? Then less growth and less business impact.
- Low care? Lower retention and morale, hence less business impact.
And on the flip side, you can have a fast, high quality dev team that works on challenge projects that they love. And they create absolutely no business impact.