The platform team you already have

Elsewhere in this track, platform teams: when, why, and when not lands on the test for starting one: has the same pain shown up, unprompted, in three places, independently, without anyone orchestrating it. That test has a second half nobody applies as rigorously, months or years later, once the team is up and running and has its own headcount and its own roadmap: has the pain it was built to kill actually stopped.

Most platform teams pass the founding test and never get checked again. They exist. They ship things. Engineers use some of what they ship, and somewhere in there the org quietly stops asking whether the original problem is solved, because the team's existence starts to feel like the answer rather than a bet that needs revisiting.

The wrong test to reach for

Adoption or satisfaction. That's the obvious way to check, some number that says most teams use the platform, or engineers rate it well on a survey. Wrong number. It looks fine and tells you almost nothing, because adoption can be high for reasons that have nothing to do with the platform working well. A mandate produces adoption. So does the absence of any alternative. Neither means the team is doing its job.

The test that actually answers the question

Go back to the pain that justified starting the team in the first place. The specific, named thing that was happening in three places independently before anyone built anything. Ask directly: has that stopped recurring. Not "do people use what we built." "Did the thing we built to stop this actually stop it."

Same rule the founding decision used, run in reverse. Three independent teams solving the same problem badly was the signal that justified starting the platform team. The mirror image, the founding pain going quiet, is the signal that it's still earning its place. Engineers still hand-rolling the same workaround the platform was supposed to replace, three years in? The team hasn't succeeded, regardless of what its own dashboard says about usage.

What happens when the pain doesn't recur, and what happens when it does

A platform team that passes this test cleanly, the original pain genuinely gone, has a decision to make that most avoid. Whether it's still needed at its current size, doing what it's currently doing. Whether it should shrink, refocus on the next named pain that's actually recurred three times, or hand what it built off to a smaller ongoing maintenance function. Uncomfortable conversation, for a team that's succeeding. Exactly the conversation success is supposed to trigger.

A platform team that fails this test, pain still there under a layer of tooling nobody quite adopted, usually isn't a team that needs more headcount. It's a team that's drifted from the problem it was funded to solve, often because it started building for problems it guessed at rather than ones that had actually recurred. Same failure mode as forming too early. Just arriving later.

When to actually run this

Not quarterly. Not as a KPI review with the team's own future riding visibly on the answer, which just teaches people to manage the number instead of the problem, and doesn't take long to teach either. Run it whenever the platform team asks for meaningfully more headcount or scope. Run it once a year regardless, as a genuine question rather than a formality. If nobody in the room can name the original pain without checking a doc, that's already the answer.