SDLC, DevOps & Developer Experience · Chapter 6 of 15
The internal platform, and whether anyone wants it
Golden paths versus gates, the test that tells you which one you built, and what to measure instead of teams onboarded.
Platform engineering has a high failure rate for a consistent reason: teams build the platform they think other teams should want, mandate its adoption, and measure success by how many were forced onto it. This chapter is about the alternative.
The distinction that decides everything
A paved road makes the standard path the fastest path. A team takes it because taking it is quicker than not, and they can leave it when their needs genuinely differ.
A gate makes the standard path the only permitted path. A team whose needs fall outside it raises a ticket, waits six weeks, and eventually routes around — and now you have shadow infrastructure you cannot see, which is worse than the non-standard thing you were preventing.
The test
If the platform became optional tomorrow, would teams still use it?
If yes, you have built a product and your adoption number means something.
If no, you have built a tax, and the number you are reporting upward measures compliance rather than value.
This is uncomfortable to ask and it is the single most useful question a platform team can put to itself. It also reframes every roadmap argument: the question stops being ‘how do we get teams to adopt this?’ and becomes ‘why is our path not the fastest one?’
What a golden path actually contains
The phrase gets used loosely. A golden path that works is specific: one command produces a new service that is already correct on every dimension the organisation cares about.
- A repository with the agreed structure, licence and ownership metadata.
- A pipeline that already builds, tests, scans and deploys — not a template to fill in.
- Observability wired: structured logs, metrics, tracing propagation, a starting dashboard.
- Deployment to a real environment, with health checks and a rollback path that has been tested.
- Security baseline: no root, secrets from the secret store, dependency scanning on.
- A registration in whatever catalogue the organisation uses, so the service is discoverable and has an owner from the first minute.
- And the escape hatch, documented. A team that needs something different must be able to take it without asking permission, and should be able to see exactly what they are giving up. A paved road with no exit is a gate with better branding.
The target that makes this real: from nothing to a deployed, observable, production-ready service in under an hour, with no tickets. If that takes three days, the platform is a documentation site.
Developer portals, and the honest assessment
Internal developer portals promise a single place to see every service, its owner, its dependencies, its health, and its documentation. The promise is genuinely valuable — ‘who owns this and is it healthy’ is asked constantly during incidents.
The failure mode is a catalogue nobody maintains.
A portal populated by hand decays within months. Ownership metadata goes stale the moment someone changes team, and a catalogue that is 40% wrong is worse than none, because people act on it and are misled.
The only version that survives is one where the data is a by-product of work that happens anyway. Ownership derived from the repository. Dependencies derived from the build or from tracing. Health derived from the monitoring that already exists. If keeping the portal current is a separate task, it will not be done.
And the second failure is scope. A portal that tries to be the interface to everything becomes a worse version of each tool it wraps. The ones that work do a small number of things well — find a service, find its owner, see its health, create a new one from a template — and link out for the rest.
What to measure
“Teams onboarded” is the wrong metric because it measures the platform team's activity rather than anyone's outcome. Four better ones:
| Metric | What it tells you |
|---|---|
| Time to first deploy for a brand-new service | Whether the golden path is real. Measure it by actually doing it, quarterly, with a stopwatch |
| Time to first commit for a brand-new engineer | Captures documentation, environment setup, pipeline and review culture in one number |
| Self-service rate — proportion of requests completed without a ticket | The clearest measure of whether you built a product or a service desk |
| Voluntary retention — teams that could leave and did not | The honest version of adoption |
And one qualitative practice worth more than any of them: a quarterly survey asking developers what wastes their time, with the results published and the top item actually fixed. Platform teams that do this consistently outperform ones that build from a roadmap, for the obvious reason — they are solving problems people have rather than problems they imagined.
The team, and its most common mistake
Platform teams fail in a predictable pattern, and it is worth naming because it is avoidable:
- Building for the platform team's taste rather than the users' need. The elegant abstraction that nobody asked for. Ask what people are doing manually and repeatedly, and automate that.
- Abstracting too early. A platform built before three teams have solved the problem their own way is a guess. Let the patterns emerge, then extract them — the extraction is much easier and it is grounded.
- Owning the incidents without owning the code. If the platform team is paged for application failures on the platform, they are an operations team with a different name. The boundary has to be explicit and it has to hold.
- No product management. A platform is a product with internal customers who can, in practice, say no. Somebody has to do discovery, prioritise, and say no to requests — and if nobody does, the platform becomes whatever the loudest team asked for last.
- And measuring output rather than outcome. Features shipped by the platform team is not a result. Time saved for everyone else is.
Check yourself