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 high value post per week

As a paid subscriber, you get:

• 🔒 50 Engineering Manager templates and playbooks (worth $79)

• 🔒 The Engineering Manager’s Field Guide (worth $29)

• 🔒 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:

1. Speed: How fast can the team ship value?

2. Quality: Are we building reliable, maintainable code?

3. Business Impact: Does our work move the needle?

4. Individual Growth: Are team members learning and improving?

5. Care: Do people care about the work, the team, and the mission?

---

Frameworks that tried to solve It

1. DORA

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

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: A new way (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:

1. Speed

2. Effectiveness

3. Quality

4. 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

• 📂 Get 50 Engineering Manager Notion Templates to streamline your workflow.

• 📕 Read The Engineering Manager’s Field Guide for practical leadership insights.

• 👨‍💻 Become a better Software Engineer with CodeCrafters – build Redis, Git & more from scratch (40% off with my partner link).

• 🎯 Book a mock System Design or Behavioral interview with me to prep for your next interview.

• 👋 Connect with me on LinkedIn for more Engineering Management tips.