Measure the team. Not the people in it.

Two questions that keep getting conflated

Is this team shipping, and is that changing? This is what a leader is accountable for, and it is answered entirely by aggregates. Nobody needs to be named, and naming them adds nothing.

Is this person doing well? This is a management question answered by someone with context: what they were assigned, what they were blocked on, what they were quietly holding together. A dashboard gets it wrong in a predictable direction: it undervalues the reviewer, the mentor, and the person whose contribution was noticing early that a project should stop.

Nearly every failure in this category comes from using an instrument built for the first question to answer the second.

Metrics worth tracking

Throughput and its direction. Whatever your team actually finishes: changes shipped, tickets resolved, deals closed, filings accepted. The absolute number is nearly meaningless across teams and highly meaningful against the same team last quarter.

Lead time. How long something takes from started to done, and how much of that is waiting rather than working. It maps onto a question every executive already has: if we decided today, when would a customer see it?

Failure rate with recovery time. Always together. Alone, failure rate rewards caution, and caution is expensive.

Unplanned work as a share of the total. The most commercially useful number and the one most often missing. “Forty per cent of last quarter went on interruptions” is an argument; “the team is stretched” is not.

Metrics that break when they become targets

Lines of code, commit counts, story points, tickets touched, calls logged, and anything at all measured per individual. A metric that determines how somebody is perceived stops describing reality within about two months, not through cynicism, but because that is what any group of intelligent people does when told what counts. Units of work get smaller, quality gets thinner, the unglamorous maintenance gets deferred, and nobody volunteers for the six-week project nobody can see.

Aggregate measurement degrades far more slowly, because gaming a team-level number takes coordination, and coordinated gaming tends to show up as an obvious anomaly rather than a quiet drift.

What this looks like outside engineering

The same four shapes work for most knowledge work, with different nouns. Support: tickets resolved, time to first meaningful reply, reopen rate, and what share of the week went to escalations nobody planned for. Sales: deals moved a stage, cycle time, slippage rate, and how much of the quarter went to renewals that were supposed to be automatic. Finance and operations: filings or close tasks completed, cycle time, error and rework rate, and unplanned work.

Notice that the fourth is the same everywhere and is nearly always missing. Throughput without unplanned work tells you a team did less this quarter; throughput with it tells you why, and that is the difference between a number that starts an argument and one that ends it.

The trap is different per function but always the same in kind: support measured on ticket count rewards closing fast rather than solving, sales measured on activity rewards logging calls, and engineering measured on volume rewards small changes. In every case the fix is a second metric that the first one cannot be traded against.

Getting started without poisoning it

1. Pick two metrics, not six. A dashboard nobody can hold in their head gets ignored, and every extra number is another thing to game.
2. Define them in writing, including the edge cases, and leave the definitions alone for at least two quarters.
3. Report at team level from day one. Retrofitting privacy onto a system that started by naming people does not work. People remember what it was.
4. Give every team its own numbers before anyone above them sees them.
5. Say out loud, once, that these will not be used in performance reviews, and then do not use them in performance reviews.

How to keep it from reading as surveillance

Default to the team. Make individual visibility an explicit, reversible, recorded decision. Enforce that where the data is rather than in the interface, or the first API call goes around it. Let people see their own numbers first. And measure what was already visible: a closed ticket or a shipped change is something the team can already see, so counting it reveals nothing new. Reading somebody’s messages or inferring focus time from calendar gaps is a different activity wearing the same word.