A team I worked with had a document called "How to Deploy a New Service." It was 31 steps long. It referenced two Confluence pages that no longer existed, one Slack thread, and a person who had left the company. Standing up a new service took about three days, most of it spent asking around.
They did not have a tooling problem. They had all the tooling — Terraform, Kubernetes, a CI system, a monitoring stack. What they did not have was a path. Every developer assembled those pieces from scratch, slightly differently, every time.
That gap is what platform engineering is actually about, and it gets lost under the job titles and the vendor slides. It is not "DevOps with a new name." It is the recognition that "every team owns their own infrastructure" quietly means every team solves the same five problems badly.
The Failure Mode It Fixes
The devops movement was right that throwing code over a wall to an ops team was broken. But the version many companies landed on — every product team owns their full stack — has a cost nobody priced in.
Six teams means six slightly different Dockerfiles, six CI pipelines, six ideas about secrets, six logging formats. When something breaks in a service you did not write, none of your knowledge transfers. And your product engineers, hired to build product, spend a meaningful chunk of their week on YAML.
The platform team's job is to make the well-lit path so much easier than the alternative that people take it voluntarily. Note the "voluntarily." A platform nobody chooses is a bureaucracy.
Golden Path, Not Golden Cage
This is the distinction that decides whether the effort works.
A golden path is the supported way. It is fast, documented, monitored, and it covers the 80% case. Take it and you get CI, deployment, observability, secrets and an on-call rota configured for you on day one.
A golden cage is the only way. Step outside it and you file a ticket and wait.
The cage always loses. Some team will have a genuine need the platform does not cover, and if the platform blocks them they will route around it — and now you have shadow infrastructure that is worse than what you were trying to prevent.
So the rule I hold to: the paved road must be optional, and it must be so much easier that opting out feels like work. If teams are leaving the path regularly, that is information about the path, not about the teams.
What Actually Goes in the Platform
Ordered by how much time they give back, from what I have seen:
Service scaffolding. One command produces a repository with the Dockerfile, the CI pipeline, health endpoints, structured logging, tracing, a test harness and the deployment manifests — all matching house conventions. This is the single biggest win and it is mostly templating.
Self-service environments. A developer can create a preview environment for their branch without asking anyone, and it disappears on merge. The asking is the expensive part, not the compute.
A deployment pipeline they do not maintain. Build, scan, deploy, roll back. Owned centrally, consumed as a template, updated in one place when the security team changes a requirement.
Observability by default. A new service emits traces, metrics and structured logs, and has a dashboard, without the author configuring anything. Observability that requires setup is observability that exists on the services that needed it least.
Paved-road infrastructure modules. A Terraform module for "a Postgres database" that already has backups, encryption, private networking and the right alarms, instead of every team assembling those from the provider docs.
What does not go in the platform: business logic, opinions about how teams write code, and — my strong view — a mandatory abstraction over the cloud provider that hides everything. Developers need to be able to see through the platform when they are debugging. A leak-proof abstraction becomes a black box that only the platform team can diagnose, and now you have rebuilt the ops silo you were escaping.
Treat It Like a Product, Genuinely
The phrase "platform as a product" is repeated so often it has stopped meaning anything. The parts that actually matter:
Your users are internal and they can refuse. Adoption is voluntary in practice even when it is mandatory on paper. That makes adoption rate your real health metric.
Measure time-to-first-deploy. How long from "I have an idea for a service" to "it is running in production and I can see its logs"? Three days was that team's number. Under an hour is achievable. That one metric drives most of the roadmap.
Do user research on your own engineers. Sit with someone shipping a service and watch where they get stuck. The answer is never what the platform team assumed. It was usually secrets management, in my experience, and never the thing that had a Jira epic.
Have a support channel and staff it. A platform with no visible humans behind it gets worked around.
The Portal Question
Backstage and its equivalents come up immediately, and I think teams reach for them too early.
A developer portal is a user interface over your platform. If the platform underneath is inconsistent, the portal is a nicely-designed window onto a mess — and you now maintain the window too. I have watched a team spend a quarter on a portal that listed services nobody could actually deploy through it.
Build the golden path first. A CLI and a good README will carry you a long way. Add the portal when the number of services makes discovery a genuine problem — when people cannot find who owns what — not because it is the recognisable artefact of platform engineering.
How Small Is Too Small
Below roughly 15-20 engineers, you probably do not need a platform team. You need one senior person to set conventions and a template repository. The overhead of a dedicated team exceeds the duplication it removes.
The signal that you have crossed the line is specific: when the same infrastructure question gets asked in Slack for the third time by the third different team, and each of them solves it differently. That is duplication with a measurable cost, and it is the point at which someone should own the path.
For that team with the 31-step document, the first version of their platform was a scaffolding CLI and one shared pipeline template. Two engineers, about six weeks. Time-to-first-deploy went from three days to under two hours, and the document was deleted — which was, honestly, the most satisfying part of the whole project.
