Over the last few years I've seen plenty of "platform teams" that were really just a renamed ops team with a new ticket queue. That's not a platform. That's the same bottleneck with better marketing.
So let's be precise about what an Internal Developer Platform (IDP) actually is — and what it isn't.
An IDP is not "more DevOps"
DevOps was supposed to tear down the wall between development and operations. In practice, in a lot of companies it turned into "every team does everything itself": its own Terraform, its own pipelines, its own monitoring, its own decisions about how to deploy. The result is enormous cognitive load on stream-aligned teams — the people meant to ship product value spend half their time fighting infrastructure they never wanted to understand in depth.
An internal platform is the answer to that load. It's a product, with internal customers who are the engineering teams. Its job is to take the part of the knowledge that not every team needs in their heads and make it consumable through a self-service interface.
Team Topologies: platform as a product, not a gate
The Team Topologies framework (Skelton and Pais) put words to what many of us felt intuitively. There are four team types — stream-aligned, platform, enabling, and complicated-subsystem — and the headline metric isn't "tickets closed per sprint," it's flow of value and cognitive load.
A platform team has one job: reduce the cognitive load on stream-aligned teams so they can deliver with real autonomy. The key word is autonomy. If you have to "request" something from the platform and wait, the platform didn't take load off you — it just moved it into a queue and added latency. That's the exact opposite of the goal.
This is why I insist the platform be run as a product. It has users, it has adoption, it has a roadmap driven by their real problems — not by what's technically interesting to the platform team.
Golden paths: a paved road, not guardrails
The term "golden path" comes from Spotify (Netflix calls it the "paved road"). It's the opinionated, officially supported way to get from idea to production: templates, tooling, docs, sane defaults.
This is where teams make the most common mistake, so let me say it bluntly: a golden path is not the same as a hard guardrail.
- A golden path is the easiest option. It's paved. Walk it and you get logging, security defaults, CI/CD and observability for free. You don't have to, but it's so convenient that not taking it hurts.
- A guardrail is a hard constraint — a policy you can't bypass (e.g. "no unsigned image reaches production").
You need guardrails — but few of them, in the right places (security, compliance). If the whole platform is built on guardrails and mandates, developers experience it as the police and start looking for ways around it. A golden path works the other way: it wins by being the easiest route, not by being the only allowed one. A mandate is an admission that the path isn't good enough for people to choose it on their own.
Self-service means a PR, not a ticket
Concretely: provisioning via Git, not via a ticket. A developer opens a pull request against a repo (a new service from a template, a new namespace, a new database resource), it passes policy checks, and a GitOps controller (ArgoCD, Flux) reconciles the approved change into the cluster state. No human in the loop for the common case.
This is the line between a platform and a renamed ops team. If there's a person between the developer's intent and the realized state, clicking buttons by hand, you don't have a platform — you have a service desk.
Thin platform vs. over-engineering
The most common way to wreck a platform isn't too few features. It's the opposite: a team spends a year building a beautiful abstraction nobody asked for, and on launch day nobody uses it. They built a platform for the problems they imagined, not the ones developers actually had.
I stick to a thin-platform rule: cover the real, repeated paths (the most common service type, the most common deployment) and nothing more. Abstract only what hurts you and your users both. Every abstraction has a cost — someone has to maintain it and someone has to learn it. If it doesn't remove more load than it adds, it's a net loss.
How to measure success
A platform without metrics is just an opinion. I track three things:
- Adoption. How many teams walk the golden path voluntarily? This is the most honest metric — if you have to mandate it, you've already lost.
- DORA metrics. The four keys — deployment frequency, change lead time, change failure rate, and time to restore. A good platform moves speed and stability together, not one at the expense of the other.
- Time-to-first-deploy. How long does it take a new developer to get "hello world" to production? If it's days, something is wrong. If it's hours, you're heading the right way.
What about Backstage?
Backstage (created at Spotify, donated to the CNCF in 2020, today a CNCF incubating project) is an excellent tool for a service catalog and software templates. But a tool is not a strategy. You can install Backstage in a week; building golden paths people actually want takes far longer. A portal with no paved roads behind it is just another pretty dashboard nobody opens.
A platform isn't a layer you route through. It's a road people walk willingly because it's the easiest one. If that's not true, you've built another bottleneck — just a more expensive one.