There's a particular kind of organizational dysfunction that looks, from the outside, like rigor. You've got dashboards. Trend lines. Weekly velocity reports color-coded by squad. Leadership can point at a number and say we shipped 340 story points last quarter with the same confidence they'd quote a revenue figure. It feels like accountability. What it actually is, most of the time, is a measurement apparatus that has decoupled itself entirely from the thing it claims to measure—and in doing so, has started actively degrading it. we shipped 340 story points last quarter I've watched this happen more than once. A fintech team I consulted with had a beautiful JIRA setup. Burndown charts that would make a project management consultant weep with joy. Their velocity was climbing quarter over quarter. Their defect rate was also climbing, their onboarding time had nearly doubled, and two of their best engineers had quietly started interviewing elsewhere. The metrics said everything was fine. The metrics were lying. The foundational problem is ontological, not methodological. Software development produces value through a long, tangled causal chain—conception, refinement, implementation, integration, deployment, adoption—and most of the intermediate nodes in that chain resist quantification in any honest sense. What a commit represents is almost always opaque to an observer who didn't write it. A three-line change that fixes a subtle race condition in a payment processor might be the most valuable work a team does all year. A 2,000-line pull request adding a dashboard nobody asked for might be the least. Lines of code as a metric doesn't just fail to distinguish these; it inverts the signal. Kent Beck said it decades ago, and it still hasn't fully landed: more code is usually more liability. Every additional line is a future maintenance burden, a potential fault site, another surface area for the next engineer to misunderstand. The best code I've ever seen merged into a production codebase made the repository smaller. The developer who wrote it probably looked terrible on any output-based metric that week. Kent Beck smaller Story points are a subtler trap because they have the vocabulary of something more sophisticated. They're supposed to be relative estimates of effort and complexity—not output, not hours, not value. The Agile literature is actually pretty clear that story points should never cross team boundaries, should never be used for performance comparison, and should definitely not be used to evaluate individual engineers. And yet. In practice, velocity becomes a target the moment it becomes visible to anyone with hiring and firing authority. Teams start over-pointing tickets. Not always consciously—this is important—but the cognitive pressure to seem productive is so persistent that estimates drift upward over time, almost like a ratchet. Six months later, the numbers look great, and the actual throughput is indistinguishable from before. Agile Gaming isn't always cynical, either. That's what makes this hard. A developer who splits a large ticket into five smaller ones might genuinely believe they're being rigorous about scope decomposition. Maybe they are. But if they're doing it in a context where velocity is watched, the organizational incentive has already contaminated the engineering judgment, and you can't easily separate the two after the fact. The collaboration damage is where I think the conventional critique undersells the severity. Software teams aren't pools of interchangeable labor executing independent tasks. They're closer to improvisational ensembles—the quality of the output depends on how well people listen to each other, how freely they share half-formed ideas, how willing someone is to spend two hours helping a colleague debug something that won't show up in their personal metrics at all. That last part is the killer. When individual output is what's being measured, helping someone else is economically irrational from a personal standpoint, even if it's the obviously correct team-level decision. I've seen senior engineers stop doing informal code reviews because they were being measured on their own ticket throughput. I've seen architects stop writing internal documentation because documentation doesn't close stories. I've seen on-call engineers start routing incidents to whoever was "slower" that week rather than whoever had the most relevant context. None of this is malicious. All of it is rational behavior in a metric-poisoned environment. The silos that form aren't organizational chart silos—they're subtler. People start hoarding problem context because sharing it takes time. They start optimizing their work queue for visibility rather than importance. They start writing code that's easier to demo than code that's easy to maintain. The architecture of the codebase starts reflecting the measurement apparatus rather than the actual problem domain. This is Conway's Law operating in its most pathological register. What does careful look like, then? Not abandoning measurement. That's the wrong conclusion and it hands the argument to the people who want to replace judgment with dashboards. The answer is being precise about what you're actually trying to learn. If you want to know whether your deployment pipeline is healthy, measure deployment frequency and mean time to restore. These are system properties, not people properties—they tell you something about your infrastructure and your incident response culture without attaching a productivity label to any individual. If you want to know whether your team is delivering value, look at the outcomes on the other side of the feature: activation rates, error rates, support ticket volume, customer retention. These are inconveniently slow to feedback, which is exactly why organizations reach for the faster proxies, but the proxies are what cause the problem. The DORA metrics—deployment frequency, lead time for changes, change failure rate, time to restore—have become something of a standard here, and for reasonably good reason. They measure flow and stability at the system level. They're harder to game than story points because they involve actual deployments, not estimates. They're not perfect. Lead time can be gamed by batching work until it's nearly done and then moving it through the pipeline quickly. Change failure rate can be gamed by reclassifying failures. But they're less susceptible to Goodhart's Law than most alternatives, and they keep the measurement focused on the system rather than on individuals. The harder prescription is cultural, and it's the one that organizational leadership is most reluctant to hear: trust is the substrate. Everything else is downstream of it. A team of engineers who trust that their judgment is respected, that doing the right thing for the codebase won't be punished by a metrics dashboard, that pair programming and mentorship and careful refactoring are valued even when they're invisible—that team will outperform a metrics-saturated team on every dimension that actually matters, over any time horizon longer than a sprint. This isn't soft. It's the actual mechanism. Cognitive safety, autonomy, and investment in mastery are the conditions under which engineers make the kind of long-horizon decisions that keep software systems healthy. Metrics programs that rank individuals or celebrate velocity above all else destroy exactly those conditions. They're not neutral. They're actively destructive, in proportion to how seriously they're taken. Monday morning, practically speaking: if you're running a team with individual velocity tracking, turn it off. Not "de-emphasize it"—turn it off. Replace it with a weekly team retrospective focused on blockers and on work that didn't make it onto the board at all (the maintenance, the incident response, the documentation, the mentorship). Start measuring one outcome metric downstream of your work—pick whichever one most directly reflects whether users are getting value. Give it three months. The discomfort you feel not having a dashboard will be inversely correlated with how much the dashboard was actually helping you. The engineers who feel like numbers usually are being treated like numbers. Fixing the metric is just cosmetic. Fixing the treatment is the work.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

How Developer Productivity Metrics Are Sabotaging Dev Teams

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Beyond the Demo: Why LLM Applications Crash in Production

10 Best JetBrains IDEs Plugins to Boost Your Productivity in 2021

4 Steps to Actually Finish your Side Project

5 Fantastic Developer Tools for Asynchronous Communication 🎯

Supercharge your Software Development Productivity by Using these 5 Tools

9 Fun Command-Line Tools to Make Your Life Easier

Beyond the Demo: Why LLM Applications Crash in Production

10 Best JetBrains IDEs Plugins to Boost Your Productivity in 2021

4 Steps to Actually Finish your Side Project

5 Fantastic Developer Tools for Asynchronous Communication 🎯

Supercharge your Software Development Productivity by Using these 5 Tools

9 Fun Command-Line Tools to Make Your Life Easier

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps