Let me tell you a story you've probably lived. Two developers are up for review. Developer A has an incredible month: 50 commits, 10,000 new lines of code, and 25 story points crushed. Developer B looks like a slacker in comparison: 5 commits, a negative 2,000 lines of code, and only 8 story points completed.
Who gets the praise? In most organisations, it’s Developer A.
But here’s the reality Developer A’s manager missed: those 10,000 lines were bloated, inefficient code for a minor feature. Those 50 commits were mostly trivial tweaks. Meanwhile, Developer B spent the month painstakingly refactoring a critical, buggy legacy service, reducing its complexity, eliminating technical debt, and making it 10x faster. Developer B created immense value, but the metrics made them look unproductive.
This isn't a hypothetical; it's the toxic reality of how we measure engineering work. We've become so obsessed with the metrics that we've forgotten the mission: to build great software.
Our traditional methods for measuring developer productivity are fundamentally broken. They are a relic of the industrial age, built for the factory floor, not for the creative, complex, and collaborative craft of software development. It's time for a revolution.
The Old Way is a Dead End: A Scathing Critique
For decades, management has clung to a set of metrics that are not just flawed, but actively harmful. They create perverse incentives, burn out our best people, and reward busywork over impact.
Let's dismantle these sacred cows, one by one.
Lines of Code (LOC): This is the original sin of productivity metrics. Praising a developer for writing more lines of code is like praising a novelist for using more words. It incentivises verbose, complex, and unmaintainable garbage. The best developers often write less code to solve a problem. As Bill Gates famously said, measuring progress by lines of code is like "measuring aircraft building progress by weight." It’s an absurdity we should have abandoned decades ago.
Commit Frequency: A developer's commit log should tell a story of thoughtful progress. Instead, we've turned it into a high-score board. This metric encourages developers to make tiny, insignificant commits just to "look busy." It penalises deep work on hard problems that might result in a single, elegant commit. It fosters a culture of performative work that actively sabotages real progress.
Velocity / Story Points: Oh, velocity. Born from the noble intentions of Agile for estimation and planning, it has been twisted into a managerial whip. Story points are relative estimates, unique to each team. Using them to compare individuals or teams is statistically meaningless. When velocity becomes a target, it encourages "point inflation," rushed work, and a focus on closing tickets rather than delivering quality. Your obsession with velocity is killing your team's agility.
Bug Counts: This one is particularly insidious. Judging a developer by the number of bugs they introduce creates a culture of fear. It discourages developers from tackling risky, complex, but necessary projects. It stifles innovation and collaboration because no one wants their name attached to a bug report. The reality is, if you're not creating bugs, you're probably not writing anything important.
The result of this measurement madness? A workforce of anxious developers, a mountain of technical debt, and managers flying blind with dashboards full of vanity metrics.
A Better Way Forward: Introducing a Human-Centric Framework
So, if the old way is so bad, what's the alternative? It's not about finding a single new magic metric. It's about shifting our entire mindset from output to outcomes.
We need a more holistic, human-centric approach. Thankfully, brilliant minds at Google, Microsoft, and across the industry have forged the path. The two most powerful frameworks to emerge are SPACE and DORA.
The SPACE Framework: A Multidimensional View of Productivity
Productivity isn't one number; it's a complex state of being. The SPACE framework, developed by researchers from Microsoft, GitHub, and the University of Victoria, gives us a vocabulary to understand it.
SPACE is an acronym for the five dimensions that matter:
S - Satisfaction and Well-being: How happy and fulfilled are your developers? Are they satisfied with their tools, their team, and the company culture? This is the most crucial leading indicator. Unhappy developers don't write good code. Period.
P - Performance: This is the ultimate outcome. Is the software high quality? Is it delivering value to customers? Is it achieving business goals? This is what we're actually paid to do.
A - Activity: Yes, we can still look at commit and deployment counts. But they are signals, not goals. They provide context for the other dimensions, not a grade for the developer.
C - Communication and Collaboration: How effectively does the team share knowledge? How good are the code reviews? How quickly can a new hire become effective? Great software is built by teams, not individuals.
E - Efficiency and Flow: How easily can work move through the system without delays or hand offs? Can developers get into a state of deep work ("flow"), or are they constantly interrupted by meetings and context switching?
The power of SPACE is that it forces you to acknowledge that productivity is a blend of all these things. You can't have high performance for long without developer satisfaction. You can't be efficient if collaboration is broken.
The DORA Metrics: The Gold Standard for High-Performing Teams
While SPACE provides the "what," the DORA metrics provide the "how." Born from years of rigorous research by Google's DevOps Research and Assessment (DORA) team, these four metrics are the definitive indicators of an engineering organisation's performance. They are focused entirely on team capabilities and system outcomes.
The four DORA metrics are:
Deployment Frequency: How often do you release to production? Elite teams deploy on-demand, multiple times a day.
Lead Time for Changes: How long does it take for a commit to get into production? For elite teams, it's less than an hour.
Mean Time to Recovery (MTTR): When a failure occurs in production, how long does it take to restore service? Elite teams recover in under an hour.
Change Failure Rate: What percentage of your deployments cause a failure? Elite teams keep this under 15%.
Notice a theme? These metrics are about speed and stability. They measure the health of the entire development and delivery pipeline. They are impossible for one individual to game and require the whole team to improve together.
SPACE and DORA are the peanut butter and jelly of modern engineering metrics. DORA gives you hard, outcome-based numbers for the Performance and Efficiency dimensions of SPACE. Combined, they give you a rich, 360-degree view of your team’s health and effectiveness.
Putting it into Practice: From Theory to Reality
This isn't just academic theory. You can start this shift today.
For Individual Developers:
Start conversations with your manager. When you discuss your work, frame it in terms of impact, not activity. Talk about how you improved system performance, simplified a complex process, or helped a teammate. Share the DORA metrics with your team and ask, "How can we get better at this, together?"
For Engineering Leaders:
Throw away your dashboards that track individual commits and story points. Start a new one with DORA metrics.
But don't stop there. Start measuring what really matters.
Here’s a starter kit of questions to ask your team, inspired by the SPACE framework:
(Satisfaction): On a scale of 1-10, how happy are you with your tools? How fulfilling is your work right now?
(Collaboration): How easy is it to get a helpful code review? Do you feel you can ask anyone on the team for help?
(Efficiency): What is the biggest thing that pulls you out of a state of flow? How much of your day is spent fighting the system vs. building features?
Start by asking these questions. Listen to the answers. Focus on the trends, not the absolute numbers. Your goal is not to grade your people; it's to build a system where your people can win.
The Call to Action: Let's Start a Revolution
For too long, we have accepted a broken definition of productivity. We've allowed our work to be reduced to meaningless numbers on a spreadsheet, and it's driving our best and brightest out of the industry.
True productivity isn't about writing more code. It's about creating an environment of psychological safety, high trust, and seamless collaboration where developers can solve complex problems and deliver incredible value. It's about building healthy teams that build healthy software.
Be the agent of change in your organisation. Share this article. Start a conversation. Challenge the old way of thinking.
Let’s stop counting and start mattering.
Now, I turn it over to you. What's the one traditional productivity metric you would banish forever, and what would you replace it with? Let's debate in the comments below.
Top comments (0)