DevOps told us every team should own the full delivery lifecycle. Build it, run it, deploy it, monitor it. Great principle. Terrible at scale.
By now, the pattern is familiar. You start with a few teams, each running their own pipelines and infrastructure. It works. Then you grow to twenty teams. Each one has reinvented service templates, built slightly different CI pipelines, and solved the same security problems in incompatible ways. Suddenly you have twenty bespoke deployment processes, none of which are documented well enough for anyone outside the team to understand.
That isn’t a failure of DevOps principles. It’s a scale problem. And platform engineering is the pragmatic fix.
What Platform Engineering Actually Is
Strip away the conference talks and vendor pitches, and platform engineering is simple: a team that builds the paved road so product teams don’t have to pave their own.
The platform team builds opinionated defaults for the boring stuff – service scaffolding, deployment pipelines, observability, security baselines. Product teams use those defaults and focus on product work. If a team needs to deviate, they can, but they start from a working foundation instead of a blank page.
At a large consumer platform, the infrastructure team had elements of this approach. The teams that used the supported path shipped faster and had fewer incidents. The teams that went custom spent meaningful time on plumbing that had nothing to do with their actual domain.
The Golden Path Is a Contract
I like the “golden path” framing because it makes the deal explicit. Follow this path, and the platform team supports you end to end. Deviate, and you own the consequences.
That isn’t about control. It’s about sustainability. A platform team can’t support infinite variation. Opinionated defaults reduce the support surface and let the platform team actually invest in quality instead of fighting fires across twenty different setups.
A good golden path covers the boring lifecycle: create a service, deploy it, observe it, roll it back. Make each step predictable and fast. If “create a new service” takes a developer two days of config and ticket filing, your golden path isn’t golden. It’s bureaucracy with a nice name.
Treat It Like a Product (Or Don’t Bother)
This is where most platform efforts fail. They build internal tooling with an infrastructure team’s mindset: here is the tool, use it, file a ticket if it breaks.
That doesn’t work. An internal platform needs product thinking. Who are the users? What workflows are painful? Where is the friction? What does adoption look like?
If developers avoid your platform, that isn’t a training problem. It’s a product problem. Either the platform doesn’t solve a real pain point, or it creates more friction than it removes.
Adoption is the only metric that matters early on. Everything else – consistency, reliability, cost savings – follows from teams actually choosing to use the thing.
What Goes Into a Platform
Keep it focused. An internal platform typically needs three capabilities:
A developer entry point. Somewhere that surfaces service ownership, docs, and supported workflows. This can be a portal, a CLI, or even a well-maintained repo with templates. The format matters less than the discoverability.
Self-service provisioning. Environments, pipelines, databases, queues – the resources teams need to ship. If provisioning requires a ticket and a three-day wait, you haven’t solved the problem.
Shared guardrails. Observability, security controls, cost defaults. Things that every team needs but nobody wants to build from scratch. Bake them into the golden path so compliance is the default, not an afterthought.
Build vs. Buy
Build what encodes your internal standards and unique workflows. Buy what’s commoditized. Most organizations don’t need a custom CI system or a bespoke container registry. They do need custom service templates, deployment policies, and integration glue that ties everything together in a way that makes sense for their stack.
The real cost isn’t the license fee. It’s the ongoing maintenance and integration work. Every tool you adopt becomes a dependency you have to keep running.
The Team Matters
A platform team needs infrastructure depth, software engineering skill, and – this gets overlooked – the ability to write decent documentation. A platform nobody can figure out is a platform nobody uses.
Avoid the ticket-queue trap. If the platform team’s primary interface is a Jira board where developers file requests and wait, you’ve built an ops team with a fancier name. The whole point is self-service.
Platform engineering isn’t a revolution. It’s DevOps growing up, acknowledging that “everyone does everything” doesn’t scale, and building the shared foundations that let teams move fast without reinventing the wheel every sprint.