For most of 2022, whenever someone said "platform engineering" in a meeting I inwardly translated it as "DevOps with a new budget proposal." The language change seemed like exactly the kind of industry buzzword cycle that produces new job titles and expensive consultants without changing much about how work actually gets done.
I've changed my view since then, and I want to explain why the distinction is more meaningful than it initially looks.
What DevOps Actually Meant (And the Problem It Created)
DevOps was fundamentally about breaking the wall between development and operations. Give developers ownership of their services through production. Make them responsible for deployment, monitoring, and on-call. The idea was good and produced real improvements in software delivery velocity.
But it created a new problem: as developer teams grew, every developer team was independently building and maintaining their own CI/CD pipelines, deployment tooling, observability stacks, and infrastructure code. The same Terraform module was being written in slightly different ways by a dozen different teams. Developer productivity was being consumed by infrastructure work that was undifferentiated across the organisation.
What Platform Engineering Changes
Platform engineering treats the internal developer experience as a product. A dedicated platform team builds and maintains a set of shared capabilities — deployment pipelines, observability tooling, infrastructure templates, developer portals — that product teams use as a service rather than build themselves.
The critical difference: the platform team's customer is other developers. Their success metric is developer productivity and time-to-production for new services, not just system uptime. This changes how they prioritise work, how they design tooling, and what "done" means.
The Concrete Changes This Drives
Golden paths: Platform teams build "golden paths" — opinionated, well-maintained templates for common service types. New services get scaffolded from these templates and inherit working CI/CD, observability, and security configuration on day one instead of building it from scratch.
Internal developer portals: Tools like Backstage (from Spotify, now CNCF) give developers a single place to see all services, their health, their owners, their documentation, and their deployment status. This sounds like a nice-to-have and becomes essential once your organisation has more than 20 microservices.
Self-service infrastructure: Platform teams build abstractions so product developers can provision the infrastructure they need (databases, queues, caches) via a defined API rather than filing tickets or writing Terraform themselves.
Is It Right for Every Organisation?
A dedicated platform team makes economic sense somewhere north of 30-50 engineers, where the duplicated infrastructure work across teams becomes visibly expensive. Below that scale, a DevOps engineer embedded in each product team (or a single shared SRE) is often the right model. Platform engineering is not always the right answer — but for organisations at the right scale, it produces real improvements in both developer experience and infrastructure consistency.
