Platform teams without the bureaucracy

Platform teams fail in a predictable way. They are formed to reduce duplication, given authority to standardise, and within a year they are a queue that product teams route around. The tooling is usually fine. The operating model is what broke.

Adoption is the only real metric

If teams use the platform because they must, you learn nothing about whether it is good. If they use it because it is the fastest route, you learn everything. Voluntary adoption is the only signal that survives contact with reality.

A golden path that has to be mandated is not golden. It is just a path.

Keep the escape hatch documented

Some teams have genuine reasons to deviate — a latency floor, a regulatory boundary, a technology the platform does not support yet. Documenting how to leave the paved road does two things: it stops the deviation happening in secret, and it produces a list of what the platform should support next.

Measure the platform like a product

• Time from repository creation to first production deploy
• Proportion of services on the current golden path, tracked over time
• Support requests per adopting team, which should fall as documentation improves
• Satisfaction, asked quarterly of the engineers who actually use it

None of those measures whether the platform is technically impressive. All of them measure whether it is helping, which is the only question that matters to the people funding it.