arrow_backAll articles
developer productivitydora metricssoftware company managementctospace framework

How to measure developer productivity without breaking your team

· Josef Chmel

Commit counts and lines of code won't tell you whether your engineering team earns its keep. What DORA, SPACE and DevEx actually measure, and how to use them as the head of a software company.

Sooner or later every owner or CEO of a software company asks the same question: "Am I getting a fair return on what I pay my developers?" In sales the answer is easy – closed deals. In engineering it is tempting to count commits, pull requests or hours logged. That is exactly where most companies make a mistake that costs more than it saves.

Why counting activity does not work

In 2023 McKinsey published an article claiming that developer productivity can be measured, proposing a set of metrics that included individual performance. Kent Beck (creator of Extreme Programming) and Gergely Orosz (The Pragmatic Engineer) responded, and their analysis became one of the most widely read pieces on engineering management.

Their argument rests on a simple model: engineering work moves through effort → output → outcome → impact. Effort (hours, planning) and output (commits, lines of code, number of PRs) are the easiest to measure. But as soon as people know they are judged by them, they optimise the metric instead of the business. More, smaller PRs, more lines, less time spent reviewing other people's code. The act of measuring changes the behaviour being measured.

Sales and recruiting measure successfully precisely because they track outcome and impact – signed contracts, filled positions. Engineering needs to do the same: measure teams and what they delivered to customers, not individuals and their activity.

DORA: four (now five) delivery metrics

The most widely used framework comes from the DORA research programme (DevOps Research and Assessment, now part of Google Cloud). It splits its metrics into two groups:

Throughput

  1. Change lead time – how long a change takes to get from version control to production.
  2. Deployment frequency – how often you deploy.
  3. Failed deployment recovery time – how quickly you recover from a deployment that went wrong.

Instability

  1. Change fail rate – the share of deployments that need immediate intervention.
  2. Deployment rework rate – how many deployments are unplanned, forced by an incident in production.

DORA itself warns about two traps. The first is Goodhart's law: once a metric becomes a target, it stops being a good metric. The second is comparing teams against each other – the metrics make sense for a specific application or service, not as a league table. A team maintaining a legacy system for a bank will never deploy as often as the team behind an internal website, and that does not mean it is doing worse work.

DORA metrics – 5 numbers that tell you how well a team delivers

SPACE: productivity has more than one dimension

In 2021 Nicole Forsgren (co-author of DORA) and researchers from Microsoft and the University of Victoria published the SPACE framework in ACM Queue. Its central claim: developer productivity cannot be captured in a single number. It breaks productivity into five dimensions:

  • Satisfaction and well-being – how happy and how burned out people are,
  • Performance – outcomes (quality, customer impact),
  • Activity – commits, reviews, deployments,
  • Communication and collaboration – teamwork and knowledge sharing,
  • Efficiency and flow – work moving without unnecessary waiting.

The practical advice: track metrics from at least three dimensions at once. Activity on its own is only a fifth of the picture – and the easiest part to game.

DevEx: what actually slows developers down

In 2023 the DevEx framework (Noda, Storey, Forsgren, Greiler) built on SPACE. Instead of asking "how much do people get done", it asks what gets in their way. Three core areas:

  1. Feedback loops – how long people wait for builds, tests and code review.
  2. Cognitive load – how hard it is to find your way around the system, the documentation and the processes.
  3. Flow – how much uninterrupted time people actually get.

The authors combine two kinds of data: surveys (how developers perceive their work) and workflow data from tools (real build, review and deployment times). Neither is enough on its own.

What about AI?

The productivity question is even more pressing now that companies are rolling out AI tools and want to know whether they pay off. The 2024 DORA report brought a sobering figure: for every 25% increase in AI adoption, documentation quality improved (+7.5%), code quality improved (+3.4%) and code review got faster (+3.1%), but delivery throughput dropped by 1.5% and delivery stability by 7.2%. The report's conclusion: AI does not automatically improve delivery – it only works where teams stick to the fundamentals, meaning small batches of work and robust testing.

What +25% AI adoption does to an engineering team – DORA 2024

For a company leader, this means you cannot judge AI by how much code it generates. Look at the same metrics you use for people: delivered tasks, lead time, change fail rate.

How to start in a small software company

You do not need an expensive analytics platform. A few steps are enough:

  1. Measure teams, not individuals. Leave individual performance to conversations with team leads.
  2. Pick 3–4 numbers – for example lead time, deployment frequency, change fail rate and a short satisfaction survey once a quarter.
  3. Watch the trend, not the absolute value. What matters is whether a team improves against itself, not against another team.
  4. Make tasks smaller. Small, clearly specified tasks with acceptance criteria shorten lead time and review and reduce the risk of defects – for humans and for AI alike.
  5. Connect tasks with code and time. When you know which commit and which PR belong to which task and how much time went into it, you have data about outcomes, not just activity.

Where mcptask.online helps

mcptask.online started as a tool for running a software company – tasks in an Epic → Story → Task hierarchy, sprints, scrum points with hour estimates, and timesheets exported to JSON, CSV or PDF. A commit that references a task (for example "#Task-47 2h") logs time and updates the task, and merging the PR can complete it. You see what the team actually delivered without manual reporting. And if an autonomous AI developer works alongside your team, its tasks, time and actions show up in the same overview as everyone else's.

Want a clear view of what your team really delivers? Sign up at mcptask.online – the first 30 days are free, no credit card required.

Sources