A platform team is asked to justify its existence. What should it measure, and what happens when platforms are funded as cost centres?

What to measure

Outcomes for the teams it serves, not output:

• Time from zero to a service running in production, which is the platform's core proposition made measurable.
• Voluntary adoption rate and its trend. Voluntary adoption is evidence; mandated adoption is compliance, and a mandate destroys the only honest signal the team has.
• The proportion of teams that tried it and left, which is a much stronger signal than the proportion that never tried.
• Lead time and change failure rate for adopting versus non-adopting teams — the outcome the platform exists to improve, and rarely measured because it requires comparison.
• Support burden per adopting team, which should fall as the platform matures. A rising figure means complexity is being pushed onto users.
• Toil eliminated, quantified: hours per team per month no longer spent on provisioning, deployment or incident response.
• Developer satisfaction, surveyed and segmented by team so a dissatisfied minority is visible.

What not to measure: capabilities shipped. It is the metric most platform teams report and it correlates with nothing users care about.

The cost-centre problem

A platform funded as a cost centre is under continuous pressure to justify itself, which produces predictable pathologies:

• Mandates, to demonstrate adoption — which destroys the adoption signal and produces resentment.
• Feature output as evidence, because features are visible and outcomes are slow.
• Under-investment in reliability and documentation, neither of which is legible to a budget conversation.
• Chargeback disputes consuming the energy that should go into improving the platform.
• An under-resourced platform that everything depends on, which is a bottleneck with a mandate — worse than no platform, because teams can neither route around it nor get what they need from it.

Better funding models

• Funded as product infrastructure, with the value argued in engineering-capacity terms: "this platform saves 200 engineer-days a month across 40 teams, and costs 6 engineers" — an arithmetic argument rather than an aesthetic one.
• Showback rather than chargeback in most organisations, since chargeback causes teams to optimise their own line item against the whole — declining to use a shared platform because its cost is visible while their own inefficiency is not.
• Explicitly funded migrations, since rationalisation and deprecation benefit the organisation and the effort lands on individual teams. Telling teams to migrate while holding their delivery commitments constant guarantees the migration does not happen.

The argument that works

Not "we provide a platform" but "these are the things forty teams no longer have to do, here is what they cost before, and here is what we spend."

And the honest counterpart: a platform whose adoption is falling, whose support burden is rising, or whose users would leave if permitted is not delivering value and should be told so by its own metrics — which is why measuring voluntary adoption honestly is in the platform team's own interest.