What Good KPI Scoring Actually Measures

Commits per day. Lines of code. Tickets closed. These numbers are easy to collect, which is exactly why so many teams end up measuring them — and exactly why they're bad KPIs. They reward activity, not the thing the team actually cares about, and engineers figure out which one you're optimizing for faster than you'd think.

The metric you can count isn't always the metric that matters

Lines of code punishes the engineer who deletes 200 lines to simplify a function. Tickets closed rewards splitting one piece of work into five small tickets. Commits per day says nothing about whether the commits moved anything forward. None of these are wrong to look at — they're wrong to score against, because a score changes behavior, and these particular numbers change it in the wrong direction.

The better question isn't "what can we measure easily" — it's "what would we want to be true about this person's week, and how close can our numbers get to that." That's a harder question, but it's the one that actually produces a useful score.

What a more honest score looks like

A few principles that hold up better than raw activity counts:

• Consistency over volume. Did the person show up and communicate clearly, day after day, or was it silence followed by a scramble? Reliability is a real signal, and it's one raw output counts miss entirely.
• Blocked time, not just completed time. Someone who spent three days stuck and said nothing is a different story than someone who spent three days stuck and flagged it immediately. The second person should score better, even though the ticket took the same time either way.
• Context over comparison. A senior engineer debugging a gnarly production issue and a new hire shipping their first small feature both look "slow" by raw output. Scoring in a vacuum, without the context of what the work actually was, produces numbers that are technically accurate and practically useless.

Where this fits into the bigger picture

A KPI score is only as good as the raw material behind it. If the input is a rushed one-line Slack message, no scoring model can extract much signal from it. This is why KPI scoring works best paired with structured daily updates — when someone writes what they did, what's next, and what's blocking them in a consistent shape every day, there's enough real signal to score against, instead of guessing from commit timestamps.

Strova's scoring pulls directly from structured daily updates — consistency, blocker resolution time, and communication quality — rather than proxying performance through raw git activity that was never designed to represent it.