Engineering managers love metrics. Story points, commits per week, bug counts, they look like simple ways to measure progress. But used the wrong way, they do more harm than good. Instead of helping, they push teams to chase numbers instead of value.

The Illusion of Control

On paper, metrics look neat. In reality, they’re easy to game. Story points get inflated, commits get split up, bug numbers rise without real improvement. Leaders think they’re tracking progress, but often they’re just tracking noise.

Some of the worst offenders are lines of code written, commit counts, hours logged, and raw bug counts. Lines of code can reward unnecessary complexity instead of clean design. Commit counts can push developers to break work into meaningless chunks. Hours logged encourage attendance over efficiency. Bug counts can punish teams unfairly or reward rushing fixes instead of preventing issues in the first place. These measures often give leaders a false sense of control, while pushing teams toward unhealthy behaviour.

What Really Matters

The real signals aren’t in charts. They’re in outcomes. How fast can an idea reach production? Do developers feel trusted and motivated? Are users seeing fewer problems? Is the team working together or stuck in silos? These tell us more than any velocity chart.

Cycle time and lead time show whether a team can deliver ideas quickly without getting bogged down. Developer satisfaction reveals if the culture is healthy or if burnout is brewing. Customer feedback and defect rates are direct reflections of product quality, telling us whether users are actually benefiting from the work being done. Collaboration indicators—like reduced knowledge silos, smoother handoffs, and peer learning—highlight whether the team is building long‑term strength.

These are harder to measure than story points or commit counts, but they actually map to what matters: delivering value and building sustainable, resilient teams.

The Cost of Bad Metrics

When the wrong numbers dominate, developers optimise for metrics, not results. Trust erodes, creativity shrinks, and burnout creeps in. The focus shifts from solving problems to looking productive.

Good leaders don’t micromanage numbers. They set clear goals, explain why the work matters, and use metrics as mirrors, not hammers. Context, trust, and shared purpose make teams effective—not chasing story points.

Better Metrics and Tools

If we want metrics that actually help, there are better options out there. Flow and quality metrics like cycle time, lead time, test coverage, and mean time to recovery (MTTR) give a more honest picture of progress. Tools like SonarQube provide insights into code quality, technical debt, and resilience. Companies that adopt smarter frameworks—like DORA metrics—see big improvements in both delivery speed and reliability.

The DORA metrics come from the DevOps Research and Assessment group and are widely regarded as the gold standard for measuring software delivery performance. They focus on four key areas: deployment frequency (how often you release changes), lead time for changes (how quickly code goes from commit to production), mean time to recovery (how fast you can recover from incidents), and change failure rate (how often deployments cause problems). Together, these metrics balance speed and stability, helping leaders understand both how fast their teams move and how reliable their systems are.

Here’s a quick overview:

Metrics aren’t useless, but they’re not the whole story. Success is measured in strong teams, happy users, and real impact. The rest is just noise.