I stumbled upon a blog post on Hacker News that I wanted to write about for a while. In it, Dan North, a consultant from the UK, talks about the importance of measuring developer productivity and how managers try to use it to identify bad programmers.
Dan shares a story about the worst programmer he knows, Tim Mackinnon, who consistently scored zero in productivity metrics. However, Tim’s productivity score was zero because he never signed up for user stories. Instead, he spent his day pairing with different teammates and helping them learn and grow.
Tim wasn’t just delivering software but was delivering a team that was delivering software. So when a manager at a Big Bank decided to let Tim go because of his zero productivity metrics, Dan fought to keep Tim and, eventually, made the team drop individual productivity metrics in favor of team accountability.
The Problems with Individual Productivity Metrics
As a manager, I understand why managers are tempted by individual productivity metrics. Story points, lines of code, number of bugs fixed — these concrete numbers make it seem easy to measure how much each developer is contributing.
But in reality, those metrics are flawed. They don’t actually measure a developer’s full impact. I don’t know of any single metric that is not flawed.
Let’s take code quality as an example. Bob might crank out 1,000 lines of code daily, so his productivity score looks fantastic! But if that is a spaghetti code full of bugs, Bob is creating more work for the whole team down the road.
On the flip side, Sarah might spend extra time designing reusable frameworks and carefully refactoring code. Her lines of code will be lower, but she’s saving the team tons of time in the long run with resilient, high-quality code.
Or what about spending time on mentoring? Tim from Dan’s post above took time every week to explain tricky concepts, review code, and pair-program with less experienced developers. That means zero individual work completed for Tim, but it’s leveling up that dev way faster.
Activities like collaborating on meetings, code reviews, documenting domain knowledge, researching and advocating for best practices — none of that shows up on individual metrics, even though it greatly impacts the team’s effectiveness.
When developers are measured only by story points and output, they’re incentivized to cut corners, skip collaboration, and ignore things that don’t directly boost their personal stats.
Even well-meaning developers will start gaming the system to maximize their score rather than doing what’s best for the team. It fractures groups instead of bringing them together.
So, individual metrics end up rewarding all the wrong behaviors. They measure the things that are easiest to measure rather than the things that matter for building great software efficiently.
Measuring What Matters
To understand how well our engineering team is performing, we must look at what truly impacts the business, not just individual developer stats.
For the business side, let’s track things like:
- Are users happy and sticking around? Customer satisfaction is so key.
- How quickly can we ship new features users want? Faster delivery means we’re creating more value.
- Is the product stable and reliable? Nothing erodes trust like bugs!
- What’s the revenue per engineer? That helps us understand overall productivity.
- Where have we found cost savings from engineering automation? Hard dollar impacts matter.
Metrics like these keep us focused on the outcomes that engineering delivers.
Then, we also need to look at the health of our engineering culture and process:
- Are developers doing thorough code reviews for each other? More eyes will catch more bugs.
- How do the test coverage and test quality look like? That’s crucial for resilience.
- Does our architecture follow consistent principles? That will boost our velocity.
- Is critical knowledge being spread across the team? We want to minimize duplicate work and avoid siloed development.
- Are developers collaborating and pairing frequently? Teamwork makes the dream work!
- Is morale high? Happier teams mean better retention.
This gives us insight into the foundation that lets our engineers deliver consistently over time. An unhealthy culture will eventually degrade output.
Zoom Out to See the Big Picture
The big takeaway here is we gotta change how we look at things as managers. Hyper-focusing on individual stats incentivizes the wrong behavior. Instead, we should be measuring what truly moves the needle for the business and our engineering squad overall, and if we see areas that need attention, drill down to an individual level.
That means keeping an eye on the big-picture outcomes and processes that highlight our engineering culture’s health.
We can make better calls by zooming out from hyper-specific individual metrics to higher-level team and business outcomes. We can spot gaps in our process, improve teamwork, and give our developers room to focus on what’s gonna have the most significant impact.
Excellent engineering management is about nurturing a culture that delivers results, not squeezing individual metrics for everything they’ve got. That deeper focus will lead to way better outcomes in the end.
Originally published on Medium.com
