Usage Telemetry

A platform team without usage telemetry operates on anecdote. It cannot say which capabilities matter, who would be affected by a change, whether an improvement was adopted, or what is safe to remove.

"Which teams call this" must be answerable in minutes, and when it is not, that is the first thing to build — before any deprecation, any roadmap decision and any breaking change.

Why it matters

Every subsequent platform decision depends on it. A deprecation without it breaks unknown consumers, a roadmap without it reflects the platform team's assumptions, and an improvement without it cannot be shown to have been adopted.

It is also the single most effective device for ending prioritisation arguments: "three teams use this and forty use that" settles a discussion that advocacy does not, and it is usually a day of instrumentation away.

Implementation patterns

• Per capability and per consuming team, not in aggregate — the aggregate hides that everyone uses one thing and nobody uses five others.
• Version distribution across the estate: template versions, library versions, base images. A long tail of very old versions is the earliest signal that propagation is not working, visible long before it becomes a security problem.
• Success and latency of platform operations — provisioning, deployment, build — instrumented with the rigour a customer-facing service would receive, since consumers experience these as the platform's reliability.
• Support load split by category, because a high rate of "how do I" questions is an abstraction and documentation problem and a leading indicator of bypass.
• Resource consumption and cost per consuming team, which makes quotas enforceable and identifies a noisy neighbour during the incident rather than afterwards.

Industry example

Data-protection platforms such as Druva and internal platforms in large SaaS organisations both hit the same wall: a capability must be changed, and nobody can enumerate who depends on it. The organisations that evolve their platforms comfortably are the ones that instrumented usage early, and the ones that cannot evolve are the ones that did not.

Failure scenarios

• No per-consumer usage data, making every change a risk.
• Aggregate metrics only, hiding the distribution.
• Version drift unmeasured, discovered during a vulnerability response.
• Support load untracked by category, so an abstraction problem looks like a documentation problem or vice versa.
• Cost unattributed, so quotas cannot be enforced and noisy neighbours cannot be identified.

Trade-offs

Telemetry about how teams use a platform can be read as surveillance, and if it is framed or used as a measure of team productivity it will destroy the relationship the platform depends on — and it will be resisted and gamed.

The distinction is whether the data is used to improve the platform or to assess the teams, and the platform team's behaviour establishes that quickly in either direction. Publishing what is collected and what it is used for is the cheapest way to establish it correctly.

Interview question

"You need to change the signature of a platform API. Tell me exactly how you find out who is affected, and what you would do if the answer is that you cannot."