Golden Paths Beat Platform Mandates
Internal platforms fail when they are enforced and succeed when they are chosen. The difference is whether the paved road is genuinely faster than the alternative.
Most internal platform teams are given a mandate: all services will deploy through the platform by the end of the quarter. Most then spend the following year discovering that mandates produce compliance rather than adoption, and that compliance produces some remarkably creative workarounds.
The platforms that succeed are the ones product teams would choose voluntarily. That is a much higher bar than a mandate, and clearing it produces something far more durable.
The paved road has to be faster
A golden path is a supported, opinionated way to do a common thing: create a service, add a database, ship to production. It earns adoption by being the fastest route, not the required one.
The test is concrete: from an empty repository, how long until a new service is running in production with logging, metrics, alerting, CI and a deployment pipeline? If the answer is under an hour on the paved road and two weeks off it, adoption takes care of itself. If the answer is two days either way, no mandate will save you.
Opinionated, not restrictive
The distinction matters more than any technology choice. An opinionated platform makes a decision on your behalf and lets you override it. A restrictive platform makes the decision and forbids the override.
Restriction seems safer and produces the opposite of safety. The team with a genuine requirement your platform does not serve will not abandon the requirement. They will build a shadow system outside your visibility, and you will discover it during an incident.
- Default hard, escape cleanly. Sensible defaults for everything, with a documented, non-punitive way out for teams whose needs differ.
- Treat escapes as product feedback. Every team that leaves the paved road is telling you about a gap. Repeated escapes for the same reason are a roadmap item, not a compliance problem.
- Version the path. Teams need to upgrade on their own schedule. A platform that requires lockstep migration across the organisation will be resisted, correctly.
If your platform needs a mandate, it is not finished.
Build it from real services
Platforms built in isolation encode an imagined workflow. The way to avoid this is to build the path by migrating real services onto it, starting with the platform team's own, then a friendly team's, then a sceptical team's.
The sceptical team is the valuable one. They will surface the requirements that make the platform genuinely general instead of merely plausible, and they will do it before you have committed to an architecture that cannot accommodate them.
What belongs on the path
Scope creep is the characteristic platform failure. A platform that tries to own everything becomes a bottleneck and a single point of failure for the organisation's ability to ship.
A useful boundary: the platform owns what is identical across services, and teams own what differs.
- Identical, so platform-owned: how a service is built, deployed, observed, secured and rolled back. Nobody differentiates on their CI configuration.
- Different, so team-owned: what the service does, its data model, its dependencies, its scaling profile.
- Contested, so negotiated: language and framework choice. Some standardisation is genuinely valuable; total standardisation is usually a fight not worth having.
Measure the thing you actually want
Platform teams often report on adoption because it is easy to count. It is a poor proxy. What you want to know is whether product teams are shipping more safely and more often than before, and whether the cognitive load of operating a service has gone down.
Deployment frequency, lead time for change, change failure rate and time to restore remain the most useful available signals. If the platform is working, those move for the teams that adopt it. If they do not move, adoption numbers are measuring compliance with a mandate rather than the delivery of value.