Green Numbers, Rotting Pond: The Engineering Metrics That Flatter While Your Team Drowns
There's a special kind of dashboard that every engineering org seems to build eventually. It's green from edge to edge. Uptime: 99.98%. Velocity: trending up. Commits: through the roof. Leadership looks at it and feels warm inside.
Meanwhile, deployments take four hours, customers are quietly churning, and your best engineer just rage-quit a refactor halfway through. The dashboard says healthy. The pond says otherwise.
The problem isn't that these metrics are fake — it's that they measure effort and appearance, not outcomes. Here are five of the worst offenders, and what belongs on your dashboard instead.
1. Commit Count: The Busy Bee Fallacy
The lie: More commits equals more progress. In practice, commit counts measure how often someone pressed a button. A developer who commits 40 times a day might be shipping brilliantly granular work — or thrashing, or padding, or splitting one change into forty pieces to look productive. Meanwhile, the engineer who spent three days deleting 10,000 lines of dead code — arguably the most valuable work of the quarter — shows up as a flat line.
Track instead: Deployment frequency paired with change failure rate. Did code reach users, and did it work when it got there? That's the whole game. Everything else is theater.
2. Sprint Velocity: A Number That Only Compares Itself
The lie: Velocity feels scientific because it has a number and a trend line. But story points are invented by the team, estimated inconsistently, and gamed relentlessly. The moment velocity appears on a management dashboard, teams start inflating estimates. Within two quarters, your velocity is up 40% and nothing about your actual output has changed. You've just redefined your units.
Track instead: Lead time for changes — how long from 'code written' to 'running in production.' It's hard to game, it reflects real friction, and it directly correlates with your ability to respond to customers and incidents.
3. Uptime Percentage: The Averaging Trap
The lie: 99.95% uptime sounds stellar until you realize it averages out your worst moments. A five-hour total outage during your biggest product launch of the year, offset by months of quiet, gets rounded into the same green number. Uptime also says nothing about degradation — the API that's technically up but takes nine seconds to respond is failing your users while technically counting as 'available.'
Track instead: Customer-impacting incident minutes — time-weighted, severity-weighted, and segmented by what users actually experienced. Add p95 and p99 latency for your critical paths. Averages hide the pain your users feel; percentiles put it on the record.
4. Lines of Code: The Classic Zombie Metric
The lie: It shouldn't still be alive, but it is — lurking in performance reviews and quarterly reports at companies that should know better. Code volume measures typing. Software quality is mostly measured in what you don't type: the abstractions that prevented duplication, the edge case you handled before it became a support ticket, the third-party library you adopted instead of building from scratch.
Track instead: Change failure rate and mean time to recovery. When something breaks, how often is it your fault, and how fast do you fix it? Teams that score well on these two are the ones shipping sustainably — regardless of how many lines they wrote.
5. Ticket Closure Rate: The Illusion of Momentum
The lie: 'We closed 120 tickets this sprint!' Sounds great. But ticket counts reward small, shallow work and punish deep work. It also says nothing about whether the tickets should have existed at all. Teams drowning in technical debt close tickets furiously while the swamp beneath them keeps rising. You're bailing water and calling it swimming.
Track instead: Escaped defects — bugs found by customers rather than your own team. This is the single most honest quality signal you can put on a wall. High escaped defects means your testing, review, or observability is broken, no matter how pretty the closure rate looks.
The Pattern Behind All Five
Notice what the lying metrics have in common: they're all inputs or activity. They measure motion, not arrival. And they share a dangerous side effect — teams optimize whatever gets measured, so a bad metric doesn't just misreport reality, it actively reshapes behavior toward the wrong things.
The honest metrics — lead time, deployment frequency, change failure rate, MTTR, escaped defects — are essentially the DORA research framework, and they've held up across thousands of teams for good reason. They measure the delivery system, not the individuals poking at it.
Tearing Down the Vanity Wall
If your dashboard is all green and nobody's nervous, it's probably not measuring anything important. Good metrics should occasionally make you wince. They should surface tension between speed and stability, and they should track the experience of the customer — the only judge whose opinion ultimately pays the bills.
A pond can look gorgeous from the shore while the oxygen levels underneath are collapsing. Pull up the real numbers. Your team — and your customers — already know the truth. Your dashboard should catch up.
