Engineering KPIs accumulate the same way meetings do. Each was added to track something specific, the specific thing changed, the KPI stayed. The dashboard becomes a museum of metrics that nobody trusts but everyone references. Worse, individual engineers learn to optimize for the metrics on display — producing outputs that hit the numbers and fail to deliver the underlying value the numbers were supposed to indicate.
The nine KPIs below are the ones we see retained too long most often. Each one had a reason once. Each one is now either gameable, irrelevant, or actively misleading. Retire them. The dashboard space is worth more empty than full of misleading metrics.
1. Velocity (story points per sprint)
Story points were a planning tool, never a productivity metric. When velocity becomes a KPI, the team inflates estimates, plans smaller stories, and the relationship between points and effort dissolves within a quarter. The metric becomes meaningless. Retire it and use shipped work as your proxy for productivity.
2. Lines of code per engineer
The canonical bad metric. Lines of code measures keyboard activity, not value. Retire immediately; replace with no individual coding metric at all.
3. Pull request count per engineer
PR counts get gamed by splitting work into smaller PRs, encouraging exactly the wrong incentive (small ship-sized chunks regardless of architectural sense). Use cycle time at the team level instead.
4. Meeting attendance rate
Tracking meeting attendance measures presence rather than impact. Engineers who attend every meeting and ship nothing are rated highly; engineers who skip meetings to do focused work are rated poorly. The inversion is structural. Retire it.
5. Calendar utilization
Treating high calendar utilization as a positive metric rewards exactly the behavior that destroys engineering productivity — fragmented attention, interruption-driven work, no deep work blocks. Engineers with high calendar utilization are usually less productive, not more. Retire and replace with focus-time protection.
Put a context layer under your distributed team.
StandIn gives engineers a 60-second wrap at the end of every shift. The next shift wakes up knowing exactly what to pick up — no standup required.
Request early access6. Time-to-respond on Slack messages
Measuring Slack response time rewards being constantly available, which is incompatible with sustained productive engineering work. Engineers learn to keep Slack open and respond quickly, sacrificing deep work for visibility. Retire the metric; embrace longer Slack response windows.
7. Hours worked
The metric managers use when they don't trust outcomes. Time spent doesn't correlate with value in knowledge work. It sometimes inversely correlates because tired engineers produce buggy work. Retire it and trust outcomes.
8. Number of standups attended
If you're tracking standup attendance as a positive metric, you're measuring compliance with a ritual rather than productive participation in the team. Engineers who attend zero standups and ship reliably are not the problem the metric implies. Retire it.
9. Closed tickets per engineer
Tickets closed rewards ticket-volume optimization: pick easy tickets, split work into more tickets, close prematurely. The metric distorts the work toward visible ticket flow rather than meaningful engineering. Retire it.
What to track instead
The metrics worth tracking measure outcomes rather than activity. Team-level cycle time from idea-to-production tells you whether the team is shipping. Incident rate tells you whether the work is robust. Time to recover from incidents tells you whether the team handles failure well. Customer-reported issue rate tells you whether shipped work is actually working. None of these are gameable in the same way individual activity metrics are.
For team health, track 1:1 cadence consistency, employee retention, and reported satisfaction. For decision quality, track decision latency at the team level and the rate of decision reversal. These metrics are harder to dashboard but more actionable than the activity metrics they replace.
The principle underneath
Engineering metrics work when they measure outcomes and break when they measure activity. Outcomes are hard to game because they require the underlying work to actually create value. Activity is easy to game because the activity can be performed without producing value. Replace activity metrics with outcome metrics wherever possible, and the dashboard becomes useful again.
Some legitimate concerns get raised when activity metrics are retired: "How do we know engineers are working?" The answer is that you know through the work that gets shipped, the decisions that get made, and the team dynamic that develops — not through proxy metrics for activity. Trust the outcome metrics and have the harder conversations directly with engineers when concerns arise.
Frequently asked questions
What if leadership demands activity metrics?
Offer team-level outcome metrics that meet the underlying need (visibility into team performance) without producing individual surveillance. Most leadership accepts this when offered. The cases where leadership specifically demands individual activity metrics are signals of broader trust problems that the metrics are symptoms of.
How do you measure individual performance without activity metrics?
Through manager judgment based on observed work, 1:1 conversations, peer feedback, and outcomes the engineer is accountable for. This is harder than reading a dashboard but more accurate. The dashboard is a shortcut that mostly produces wrong signal.
Which of these metrics is most often hardest to retire?
Velocity. It's been written into so many planning processes and review cycles that retiring it feels like dismantling a foundation. The dismantling is worth it; the metric does more harm than good in most teams. The transition takes a quarter or two but produces noticeably better planning and execution conversations.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.