A distinction worth making carefully
"Platform engineering" has been trending in the DevOps and SRE space for the past two years. Every conference has talks about it. Teams are renaming themselves. Vendors are rebranding their products. The natural question is whether this represents a genuine evolution in how organisations structure engineering, or a rebranding of what was already called DevOps or SRE.
The answer is: it's a bit of both, and whether the distinction matters depends on where your organisation is.
What DevOps actually meant
DevOps, in its original framing, was a cultural movement. It was about breaking down the wall between development teams (who write software) and operations teams (who deploy and run it). The goal was shared responsibility for the full lifecycle of a service — developers would care about operability, operators would be involved earlier in the development process.
In practice, "we're doing DevOps" often came to mean: "developers now also do the ops work." CI/CD pipelines, infrastructure provisioning, on-call rotation, deployment automation — these became developer responsibilities. This was an improvement on the old model where a separate ops team was a bottleneck, but it introduced a different problem: developers were spending significant time on undifferentiated infrastructure work instead of building product.
What platform engineering actually means
Platform engineering is the response to that problem. A platform team treats other engineering teams as internal customers. They build and operate the internal infrastructure, tooling, and self-service capabilities — the "internal developer platform" — that make product developers productive.
The distinction is the product model. A platform team asks: what do our developer teams need to deploy, run, and observe their services? And then they build that as a product, with the same attention to usability and reliability they'd give an external product.
Concretely, a platform team might own:
- The Kubernetes platform (so product teams don't manage clusters)
- The CI/CD golden path (so teams get working pipelines by default)
- The observability stack (so teams get metrics, logs, and tracing without configuring it)
- The secrets management system (so teams can access secrets without managing vault infrastructure)
- Developer self-service tooling (so teams can provision databases, create environments, and manage access without filing tickets)
The key word is "self-service." The platform team's goal is to make the platform so good that developers can do what they need without involving the platform team. That's a different incentive structure from traditional ops, where involvement was the point.
The practical difference for your organisation
For a small team (under 20 engineers), the distinction is largely academic. One or two engineers doing infrastructure work, whether you call them DevOps or platform engineering, are probably doing a similar job.
The distinction starts to matter at around 50–100 engineers. At that scale, the friction caused by every product team managing their own infrastructure becomes significant. Teams are solving the same problems (how to do database migrations safely, how to set up monitoring, how to manage secrets) independently, inconsistently, and repeatedly. A platform team that solves these problems once and makes the solution available to everyone creates compounding leverage.
At 200+ engineers, platform engineering isn't optional. The cognitive overhead of each team managing its own infrastructure is too high, and inconsistency becomes a reliability and security risk.
Does your organisation need a platform team?
Ask whether your product engineers are spending significant time on infrastructure work that isn't specific to their product. If the answer is yes — if teams are building their own CI/CD pipelines, configuring their own observability, managing their own secrets rotation — then the raw material for a platform team's roadmap is already there. You're just currently doing it in a distributed and inefficient way.
The other signal is consistency. If two teams use different tools to solve the same problem, if your deployment processes vary significantly across services, if an engineer moving between teams has to relearn how infrastructure works — these are symptoms that a platform team would address.
The label matters less than the mindset. Whether you call it DevOps, platform engineering, or infrastructure engineering, the question is the same: are you building internal capabilities as a product, with the goal of making every other engineering team more productive? If you are, you're doing platform engineering, whatever you call it.