Metrics exist to locate gaps, not to score consumers

What it is

Adoption rate, legal rate, and the bypass list are a searchlight for system maintainers: where a component is missing, where guidance is not at the point of use, where the interface is too expensive to change. They are not a performance score for consumers. Metrics for locating gaps, once turned into appraisal — adoption in team goals, misuse counts in quarterly ratings — produce a rational response: wrap a shell so the scanner sees tags, disable the scanner, or hide contested calls in unparseable generated output. The number looks better; the gap is buried deeper.

A searchlight points at a system; a score is aimed at a person. Aim at the wrong object, and behaviour walks toward the score, not toward interface consistency.

Why it happens

Appraisal turns the metric into a contest between consumer and maintainer. Consumers control how their repo is written; maintainers control scan rules. In a contest, changing the writing is cheaper than changing the product, so tags appear that exist for the scanner, empty calls, and “pass the line then swap back to a private implementation”. Maintainers tighten rules, consumers dodge again, and the distance between metric and real pixels grows.

When the job is locating gaps, an ugly number is success: it names the variant to add, the sentence to drop into the editor, the contribution threshold to lower. The owner of the number is the maintainer; the action is to change the system, not the consumer’s scorecard. Consumers are invited to look at where the light landed in order to confirm “are we actually missing this”, not to accept a low mark.

Where it stops holding

For the system team itself, the metric may be a work goal — it is their product. Shipping the same number into every product team’s OKRs aims at the wrong object. Legally or safety-forced usage (a payment button must be the system’s) may be a merge gate; that is a compliance door, not a performance score, and it blocks a change rather than grading a person. Extreme negligence (copying system source into the repo and deleting upstream) needs a governance case, and must not be used to impose adoption appraisal on everyone. Metrics that are never shown also fail: consumers cannot help confirm a gap they cannot see, and maintainers talk only to themselves.

Applying it

• Address the report to “system maintainers” by default. Next to every ugly number, a system-side action (add a component, add in-context copy, lower contribution cost) — not a team ranking.
• Do not write adoption or legal rate into product-team performance reviews. If the organisation already has, move the goal onto maintainers first, then delete the product-side score.
• Gap meetings with consumers bring raw call sites, not a leaderboard. The output is the system’s backlog, not a remediation letter to the consumer.
• How to check: ask three product leads whether the number affects their performance. Anyone who says yes, the metric is already an appraisal. Then read two quarters of tickets opened “because adoption is low”: if they were assigned to product teams to change calls, not to the system to fill a gap, the object is inverted. Leave a known gap (the missing date picker) on the report: if the next backlog shows “add a date picker” rather than “team X missed adoption”, the searchlight is still on the system.

Related

• Same group: R1.18.1 Adoption is counted at call sites, not by teams · R1.18.2 High coverage is not the same as correct use · R1.18.4 The distribution of bypasses shows what the system is missing
• Adjacent: R1.06 Contribution and governance · R1.04 Usage guidelines
• Search terms: metrics for locating gaps · not a scorecard · adoption KPI