Counting the Wrong Things: How Engineering Metrics Mislead Leadership and Demoralize Teams

There is a peculiar comfort in numbers. When a VP of Engineering presents a dashboard showing 1,200 commits last quarter, a deployment frequency of twice daily, and 94% sprint completion rates, the boardroom tends to exhale. Something measurable is happening. Progress, presumably, is being made.

Except, often, it is not.

Across the American technology sector — from early-stage startups in Austin to enterprise software shops in the Pacific Northwest — engineering organizations have developed a quiet addiction to metrics that feel rigorous but measure almost nothing of lasting consequence. The result is a systemic misalignment between what leadership believes is happening inside an engineering team and what is actually happening. That gap, left unaddressed, compounds over time into missed deadlines, eroding code quality, and engineering talent that quietly starts updating its résumé.

The Seductive Appeal of Activity Metrics

Lines of code written. Pull requests merged. Tickets closed. Deployment frequency. These numbers are easy to collect, easy to visualize, and deeply misleading.

Consider deployment frequency. It became a celebrated benchmark after the DevOps Research and Assessment (DORA) program published research associating high-performing teams with frequent deployments. That research is legitimate. The problem is how organizations chose to respond to it. Rather than building the organizational and technical conditions that allow safe, frequent deployment, many teams simply deployed more often — pushing smaller, less consequential changes to inflate the number. The metric moved. The underlying capability did not.

Lines of code present a similar trap. A developer who refactors 800 lines of tangled legacy logic into 120 clean, well-tested lines has arguably delivered more value than a colleague who wrote 2,000 new lines of marginally tested feature code. But in any system that rewards output volume, the second developer looks more productive on paper. Over time, teams learn what the metrics reward and optimize accordingly. This is not a character flaw — it is rational behavior in a broken measurement system.

What Sprint Velocity Is Actually Telling You

Sprint velocity — the number of story points completed per sprint — has become one of the most widely misunderstood metrics in agile software development. Product managers use it to forecast delivery timelines. Executives use it to benchmark teams against one another. Neither application is appropriate.

Velocity is a relative measure, not an absolute one. Story points are calibrated internally by each team and reflect that team's collective judgment about complexity and effort. Comparing velocities across teams is roughly equivalent to comparing temperatures measured in Fahrenheit and Celsius without converting — the numbers exist in entirely different frames of reference.

Worse, velocity is trivially gameable. When teams understand that their velocity is being scrutinized, estimates tend to drift upward. Stories get inflated. The number climbs. Leadership interprets this as improvement. Engineers interpret it as theater. Neither outcome serves the organization.

The Three Structural Harms of Vanity Metrics

Beyond the obvious problem of bad data, over-reliance on activity metrics causes three specific structural harms that are worth naming explicitly.

First, they crowd out quality signals. When a team is focused on closing tickets and hitting deployment targets, there is less cognitive and calendar space for code review depth, architectural deliberation, and proactive testing. Technical debt accumulates not because engineers are careless but because the incentive structure punishes slowness, even when slowness is the appropriate response to complexity.

Second, they erode psychological safety. Engineers are perceptive professionals. When they observe that leadership is evaluating them on commit frequency rather than on the quality of their decisions, they receive a clear message: the organization does not understand the work. That perception breeds disengagement. In a labor market where experienced software engineers remain in high demand, disengagement translates directly into attrition.

Third, they produce false confidence at the leadership level. A dashboard full of green numbers creates a sense of control that may be entirely illusory. Organizations have shipped catastrophically flawed software while their engineering metrics looked excellent. The metrics were not lying in a deliberate sense — they were simply measuring the wrong things with great precision.

A More Honest Framework: The Signals That Actually Matter

The alternative is not to abandon measurement. It is to measure outcomes rather than activity, and to accept that the most important signals are sometimes slower and harder to collect.

Change Failure Rate is one of the four DORA metrics that is frequently underemphasized relative to deployment frequency. It measures the percentage of deployments that result in a degraded service or require remediation. A team deploying twice a day with a 25% change failure rate is not a high-performing team — it is a team generating constant operational noise. Change failure rate, tracked honestly, is one of the clearest indicators of engineering discipline.

Mean Time to Recovery (MTTR) matters more than mean time between failures. Systems will fail. The question is how quickly an organization can detect, diagnose, and resolve incidents. MTTR reflects the real-world quality of observability tooling, runbook discipline, and on-call culture — all of which are genuine indicators of engineering maturity.

Unplanned Work Percentage is a metric borrowed from the IT operations world that translates powerfully into software development contexts. If a significant portion of every sprint is consumed by interruptions, bug fixes, and urgent patches, that percentage tells you something critical about the health of the underlying codebase and the effectiveness of the team's quality practices. High unplanned work is almost always a symptom of deferred investment in testing, documentation, or architectural integrity.

Developer-Reported Friction deserves a place alongside quantitative metrics. Structured, anonymous surveys that ask engineers to rate the difficulty of specific workflows — deploying to production, onboarding new contributors, understanding unfamiliar code — surface qualitative signal that dashboards cannot capture. Organizations that collect and act on this data consistently report lower attrition and higher delivery consistency.

Redesigning the Measurement Conversation

Shifting an organization's metric culture is not a technical problem — it is a leadership problem. The change begins when senior engineering leaders are willing to walk into an executive review and say, plainly, that the current dashboard is measuring the wrong things.

That conversation requires credibility, preparation, and a concrete alternative. It also requires honesty about what good measurement actually demands: slower feedback loops, more qualitative inputs, and a willingness to sit with ambiguity rather than reaching for a number that feels reassuring but explains nothing.

At eRightSoft, we work with engineering organizations that are trying to build durable technical capability, not impressive-looking reports. The difference between those two goals is not always obvious from the outside. But over time, the organizations that measure honestly — even when the honest numbers are uncomfortable — are the ones that build software worth building.

The metrics mirage is seductive precisely because it offers certainty in a domain defined by complexity. Resisting it is one of the more important things an engineering leader can do.