Instrument AI Adoption Without Breaking Trust — Measure Systems, Not People

Workflow area: Measurement & ROI · Tier: Core · Hands-on time: ~30 minutes

Every AI tool ships with an admin console, and every admin console ships with a per-seat usage view, because seat counts are what vendors sell. The moment that view leaks into management practice — a 1:1 where someone's "low Copilot usage" comes up, a calibration where it doesn't help — two things happen: usage numbers become performances, and every other instrument you own (pb-37's impact system, pb-32's amnesty surveys, pb-31's incident reports) starts returning fiction. Telemetry governance is not a privacy nicety; it is what keeps all your other data true.

When to use — and when not to

• Use it before enabling any usage telemetrythe contract must predate the collection, because rules written after the first awkward dashboard read as damage control, not principle.
• Use it when a platform or parent org requests usage dataengineering-intelligence tools and GCC parent companies will ask for exactly the per-person cuts this playbook prohibits; the contract is your prepared answer.
• Use it to repair an existing per-person dashboard cultureremediation is possible but must be loud: publicly disable the views, publish the contract, and expect a quarter before reporting honesty recovers.
• Skip collecting what no decision needsthe contract's first test is "which decision does this field inform?"; telemetry with no consuming decision is surveillance inventory waiting for a misuse.
• Skip pretending not to measure at allzero instrumentation means adoption decisions by anecdote and pb-39's ROI case by vibes; the answer to surveillance risk is governed measurement, not blindness.

The recipe

1. 1.

   Write the purpose statement — one paragraph, published to the team. What is collected (tool sessions, seat activity, feature usage — name the actual fields from the admin APIs), why (capacity planning, license right-sizing, enablement targeting, the pb-37 impact pairs), at what granularity (team aggregates), and the explicit negatives: this data does not appear in performance reviews, promotion cases, or 1:1s, and no per-person view is built or consulted. Sign it as the engineering leader; an unsigned policy is a suggestion.

2. 2.

   Set the aggregation floor and enforce it in the pipeline. No metric is reported for any group smaller than five (pick your floor and write it down) — including by subtraction, the classic leak: "the team minus the two seniors" is a three-person cut wearing an aggregate's clothes. Enforce the floor where the data is produced, not where it is presented: the queries and platform configs that generate reports should be physically incapable of emitting small-n rows, because a floor maintained by presenter discipline fails at the first curious VP.

3. 3.

   Configure the tools to match the contract. Thirty minutes in each admin console: disable or role-restrict per-user dashboards where the platform allows; scope admin-API pulls to aggregate endpoints; restrict raw-access roles to the one or two people who run the pipeline; turn off any vendor "engagement scoring" of individuals. Where a platform cannot disable per-person views, name the compensating control in the contract — who holds the role, and the commitment not to consult it — and weigh the gap in the next pb-35 evaluation; admin-side governance is a legitimate selection criterion.

4. 4.

   Give the team first review of the data about them. Before any usage report rolls upward, the team sees it: five minutes in a team meeting or an async post — "here is what the telemetry says about us this month; is it fair, and what context is missing?" This is the trust mechanism that makes the whole contract legible: the subjects of measurement are its first audience, corrections flow in before the data travels, and the annotated version (with the team's context attached, pb-36-style) is what goes up. Data about a team that the team has never seen is surveillance regardless of intent.

5. 5.

   Audit the contract quarterly — visibly. Fifteen minutes: pull the access logs on raw telemetry roles, confirm the small-n guards still hold after platform updates, check that no per-person number appeared in any performance artifact (ask the EMs directly), and report the audit's result to the team in one line. The audit's existence is half its value — a contract nobody checks converges on whatever the admin consoles make easiest.

Make it yours

• Small team or startup: the purpose statement is a pinned message and the floor still applies — on a six-person team most cuts are below n=5, which means most reporting is simply the whole-team number, and that is fine; small teams are where "I noticed you're not using the tool" does the most damage precisely because it feels casual.
• Large org or GCC: the contract becomes org policy with works-council or privacy review where jurisdictions require it (employee-monitoring law applies to usage telemetry in much of Europe and increasingly elsewhere); when the parent company requests per-person data, the prepared answer is the contract plus the aggregate report that actually serves their stated need — escalate the rare genuine exception to HR/legal rather than deciding it in engineering.
• Platform-heavy orgs: engineering-intelligence tools are contract-relevant vendors — their AI-adoption modules default to individual developer views in many configurations; make disabling those views part of onboarding the platform, and put the platform's own admins under the same access-audit as your internal roles.

Quality check

• The team can state the purposeask an engineer what the usage data is for and who sees it; a shrug means the statement was published but not communicated, which is the same as not published.
• No small-n number has shippedsample last quarter's reports for group sizes, including subtraction cuts; one leak teaches everyone the floor is decorative.
• First-review actually happenedcheck the last three upward reports for the team's annotations; unannotated reports mean step 4 has silently become a formality or been skipped.
• Access logs are boringraw-telemetry access outside the named pipeline roles is a contract breach even when well-intentioned; investigate every anomaly and say that you do.
• Usage honesty is stable or improvingthe system-level signal: if telemetry usage patterns and pb-32 survey self-reports track each other, people aren't performing for the dashboard; divergence between them is your earliest warning that trust is slipping.