Which suite-health indicators would you publish as team targets, and how do you keep them from being gamed?

### Start by separating an indicator from a gate Two different objects get called "a metric" and conflating them causes most of the damage. A **gate** is a threshold that blocks something: a run, a merge, a release. Gates must be few, unambiguous and cheap to satisfy honestly, because a gate that is expensive to satisfy honestly gets satisfied dishonestly. An **indicator** is a number published to start a conversation. It is not a threshold, nothing is blocked by it, and its job is to make a trend visible to the people who can act on it. Suite health belongs almost entirely in the second category. The instant an indicator becomes a target with consequences attached, you have invoked **Goodhart's law** — in Strathern's widely quoted formulation, *when a measure becomes a target, it ceases to be a good measure* — and every number below has a cheap, dishonest way to move it. ### Leading and lagging **Lagging indicators** report an outcome after the fact. They are trustworthy but arrive too late to steer: pipeline pass rate, time to repair a broken shared branch, how much rework a release caused. **Leading indicators** move before the outcome does, so they are steerable, and precisely because they are steerable they are gameable: flake-rate trend, quarantine list size and age, suite runtime against its budget, review latency, the share of changes that arrive with tests, and coverage *trend* on changed code rather than coverage level over the whole codebase. Publish both. A leading set alone tells you what people are doing; a lagging set alone tells you what happened but not what to change. ### Pair every indicator with the thing its gaming would break This is the practical answer to Goodhart, and it is what separates a principal answer from a list of metrics. For each number, name the cheap distortion and publish the counterweight in the same view: | Indicator | Cheapest way to move it dishonestly | Publish alongside | | --- | --- | --- | | Flake-rate trend | Exclude cases from the counted set | Quarantine list size and age of oldest entry | | Suite runtime vs budget | Delete or skip cases; weaken assertions | Count of blocking cases; coverage trend on changed code | | Pipeline pass rate | Retry until green; move checks off the blocking path | Flake rate; number of blocking checks; escapes past the pipeline | | Coverage trend | Execute code without asserting anything | Change-level review; trend restricted to changed lines | | Review latency | Approve without reading | Change size distribution; rework rate on merged changes | | Time to repair | Reclassify a red branch as "known issue" | Count and age of known-issue exclusions | No pairing is airtight. What pairing buys is that the dishonest move stops being *invisible*: it shows up as an odd shape somewhere else in the same dashboard, and someone asks about it. ### The governance that decides whether any of this works - **Aggregate at the team level, never the individual.** Individual attribution converts every indicator into a performance instrument within a quarter, and the distortion follows immediately. - **Direction, not thresholds.** "Flake rate falling over the last two quarters" is a conversation. "Flake rate below 1%" is a target, and targets get met by relabelling. - **Comparison against yourself, not across teams.** A team owning an integration-heavy dispatcher service and a team owning a small library have incomparable numbers, and ranking them teaches both to optimise presentation. - **Review the metric set itself on a cadence.** Retire indicators that have saturated or gone flat. A set that never changes is a set nobody is reading. - **Never attach the numbers to compensation or promotion.** This is the single strongest predictor of whether the set survives contact with the organisation. ### A concrete read Nine teams on a ride-hailing dispatcher platform report against a 27-minute shared-branch budget. One team's flake rate falls from 4.1% to 1.2% across a quarter — the best movement on the board. Read alongside its pair, the quarantine list went from 14 entries to 63, oldest entry 71 days. The suite got quieter, not better, and one of those entries was the case asserting that a support-desk role cannot reassign another operator's ride; a **permission escalation** shipped and was found 12 days later. Nobody involved acted in bad faith: they were told flake rate was the number that mattered, and they moved it the cheapest available way. That is Goodhart operating exactly as advertised, and the fix is structural — publish the pair — not a conversation about integrity. ### What to say when pushed Be honest that no metric set is un-gameable, and that the choice is *which distortion you can live with*. Then say what you would actually do first: pick a small set — three to five — that a team can hold in its head, pair each one, review them in a retrospective rather than a status report, and change the set when it stops producing arguments. An indicator that never provokes a disagreement has either been solved or is being managed for presentation, and both mean it is time to retire it.