Somewhere between the fifth and the fifteenth engineering team, every organisation builds a platform team. About half of them end up with a platform that product engineers route around. The difference is almost never technical.
The golden path is a default, not a gate
A good platform makes the supported way the fastest way. A failing platform makes the supported way the only way, then becomes a queue. If a product team can genuinely justify stepping off the golden path, they should be able to - and the friction they hit should come from the consequences of that choice, not from a ticket waiting for approval.
Self-service provisioning with no human in the request path for the common cases.
A paved road that covers the first ninety percent: service scaffold, pipeline, observability, secrets, on-call wiring.
A documented, supported exit for the remaining ten percent.
Platform changes shipped behind the same review standards as product code.
Measure adoption, not output
Platform teams that report on tickets closed and components shipped drift away from their users within two quarters. The metrics that keep them honest are the ones their customers feel.
Four numbers worth a dashboard
Time from empty repository to a service serving production traffic. Median pull-request-to-production duration. Percentage of services on the current paved road. Number of production incidents attributable to platform defects. Everything else is commentary.
p50 repo_created -> first_prod_deploy : 4h 20m target: < 1 dayStaffing it honestly
A platform is a product with internal customers, and it needs the same roles: someone accountable for the roadmap, engineers who talk to users weekly, and documentation treated as a deliverable rather than a favour. Three engineers who interview product teams monthly beat eight who ship a Kubernetes abstraction nobody asked for.
If your platform team cannot name the three things that are currently slowing down the product teams, it is building for an imaginary user.
Start with the pipeline, not the abstraction
The highest-leverage first project is almost always continuous integration and delivery: a single, fast, reliable pipeline that every service uses. It is unglamorous, it touches every team, and it earns the credibility you will need before you ask anyone to adopt a service mesh.
Dedicated dev teams we embed with clients spend their first sprint on the pipeline for exactly this reason - it is the shortest path from "new vendor" to "the build is green and fast now".
