Counting the Wrong Things: How Vanity Metrics Are Eroding Your Engineering Team's True Performance

There is a particular kind of confidence that comes from looking at a full dashboard. Green indicators, upward-trending graphs, sprint velocity holding steady at forty points per cycle—it feels like evidence of a functioning, productive engineering organization. The problem is that this confidence is often borrowed against a debt that will eventually come due.

Across the US technology sector, engineering teams are being evaluated, rewarded, and restructured based on metrics that were never designed to measure what leadership actually cares about. The result is a quiet misalignment: teams optimize for what is being tracked rather than what genuinely matters, and organizations mistake the appearance of momentum for the reality of progress.

The Allure of the Countable

Metrics like lines of code, story points completed, and pull requests merged share one important quality—they are easy to collect. Modern development tooling generates this data automatically. It flows into dashboards without friction, populates reports without interpretation, and creates the impression of measurement rigor with very little effort.

That ease is precisely what makes these numbers dangerous.

Lines of code have long been recognized as a poor proxy for productivity, yet they persist in engineering scorecards because they feel concrete. A developer who refactors five hundred lines of redundant logic into fifty clean, maintainable functions has made the codebase meaningfully better—but their line count will look worse than a colleague who wrote verbose, repetitive code to solve a simpler problem. Story points, meanwhile, measure estimation accuracy as much as they measure output, and they are notoriously susceptible to inflation over time as teams learn that higher estimates lead to less pressure.

Perhaps most insidious is the fixation on pull request velocity. Merging a large volume of PRs quickly can signal a healthy review culture, or it can signal that reviews have become perfunctory rubber-stamps that let defects slip through unchallenged. The number alone cannot tell you which scenario you are in.

What Gets Optimized When the Wrong Things Are Measured

When engineers understand that their performance will be judged by velocity metrics, they adapt. This is not cynicism—it is a rational response to the incentive structure in front of them. Stories get broken into smaller chunks to inflate completion counts. Code that should be refactored gets left alone because touching it would slow velocity without producing a visible deliverable. Reviews get rushed because a pending PR is a drag on the team's numbers.

The downstream effects compound quietly. Technical debt accumulates in corners of the codebase that metrics never illuminate. Burnout builds in engineers who feel pressure to sustain output rates that the numbers demand but that the work cannot realistically support. And the teams that look most productive on paper are sometimes the ones moving fastest toward a reckoning—a product that becomes increasingly difficult to extend, a codebase that new engineers cannot navigate, a delivery pipeline that requires heroic effort to sustain.

This is not a failure of individual engineers. It is a systems problem, and it begins with the metrics leadership chooses to treat as truth.

The Signals That Actually Matter

Shifting toward more honest measurement does not mean abandoning quantification entirely. It means being deliberate about what the numbers are actually capturing and supplementing them with indicators that resist easy gaming.

Change failure rate and mean time to recovery are two of the most revealing signals available to engineering organizations. A team that deploys frequently but recovers from failures in minutes is demonstrating something fundamentally different from a team that deploys infrequently and requires hours or days to restore service. These metrics, drawn from the DORA research framework that has become a reference point for high-performing engineering teams, correlate far more closely with actual delivery quality than sprint velocity ever could.

Code review thoroughness, while harder to quantify, can be approximated by tracking defect escape rates—the percentage of bugs that reach production despite having passed review. A team with a low escape rate is conducting reviews that add genuine value. A team with a high escape rate may be moving fast through a process that has become largely ceremonial.

Unplanned work as a proportion of total capacity tells a story about system health that planned metrics cannot. When engineers are consistently pulled away from roadmap work to address incidents, fix regressions, or untangle integration failures, that proportion will rise. Tracking it honestly forces an organization to confront the real cost of deferred quality work.

Cycle time at the task level—not the sprint level—reveals where work actually stalls. A story that sits in review for four days before being merged represents a bottleneck that aggregate velocity numbers will never surface. Granular cycle time data points directly to process friction.

The Harder Conversation About Team Health

Beyond technical metrics, the most important signals about engineering team performance are often qualitative, and they require leaders to be genuinely curious rather than simply confirmatory.

Are senior engineers spending their time on work that matches their capability, or are they trapped in operational maintenance that should have been automated or delegated? Are engineers raising concerns about architectural decisions in retrospectives, or have those conversations stopped because they have learned that concerns are not acted upon? Is onboarding time for new team members increasing—a sign that the codebase is growing more complex faster than documentation and tooling can keep pace?

These questions do not resolve into a single number on a dashboard. They require ongoing conversation, psychological safety, and leadership willing to hear uncomfortable answers. That is a harder ask than pulling a velocity report, which is precisely why so many organizations default to the report.

Building Measurement Practices That Serve the Work

For technology organizations committed to building sustainable digital solutions, the path forward involves treating measurement as a craft rather than a convenience. That means being explicit about what each metric is actually measuring, what it cannot measure, and what decisions it should and should not inform.

It means resisting the pressure to reduce engineering performance to a single composite score, because the complexity of software development does not compress cleanly into one number without losing something essential.

And it means accepting that the most important indicators of a healthy engineering team—trust, craft, honest communication about risk—will always be partially resistant to quantification. That resistance is not a failure of measurement. It is a feature of human work done well.

The organizations that figure this out will not have the most impressive velocity dashboards. But they will have engineering teams building things that last, and in the long run, that is the only metric that genuinely matters.