I covered where platform engineering actually comes from last week — the short version is that it’s what happens when “you build it, you run it” hits an organisation large enough that nobody can hold the whole picture in their head any more. This week I want to sit with a distinction that gets blurred constantly, in job specs, in conference talks, in the way people casually use “DevOps team” and “platform team” as if they’re the same noun with a rebrand: they are not the same thing, in kind, not just in degree.
DevOps is a culture. It’s a set of practices that’s supposed to be everyone’s job — every team owns its own pipeline, its own on-call, its own path to production. Platform engineering is an org design decision: a dedicated team that builds an internal developer platform and operates it as a product, with a defined set of users, measured on whether those users actually adopt it and how much friction it removes from their day. Confusing the two doesn’t just cause a semantic argument on LinkedIn. In a regulated environment, it changes how many things you have to defend to an auditor.
What DevOps Actually Promised#
The original DevOps pitch, going back to “you build it, you run it,” was a culture change, not a team. The point was collapsing the wall between the people who write code and the people who get pinged when it breaks — every team carries its own operational responsibility, every team owns its own CI/CD, every team is on the hook for its own production incidents. Nobody gets to throw a build over a fence and call it someone else’s problem.
That model works. I’ve operated inside it for most of my career — at Syrex, being the escalation point across a dozen client environments meant there was no fence to throw anything over in the first place; you owned what you built, full stop. The trouble isn’t the culture itself. It’s what happens when “every team owns its own pipeline” scales past a handful of teams and nobody’s coordinating what “owns its own pipeline” actually means in practice.
What Platform Engineering Actually Is#
Platform engineering isn’t DevOps with a different job title on the org chart. It’s a structural answer to the problem DevOps-at-scale creates: instead of every team independently reinventing “how do we build, scan, promote, and deploy safely,” a dedicated team builds that path once, builds it well, and offers it to every other team as a product — a self-service internal developer platform, not a mandate handed down from a steering committee.
The word that actually matters there is product. A platform team has users — the org’s own developers — and it’s judged the way a product team is judged: adoption rate, time saved, tickets that never got raised because self-service handled it, developer satisfaction, how much of the golden path teams actually walk versus route around. That’s a completely different measurement axis from “did every team ship a working pipeline,” which is the closest thing shared-responsibility DevOps has to a success metric. Nobody owns the developer experience of the whole engineering org under a pure DevOps model, because ownership is deliberately distributed. Under platform engineering, somebody owns exactly that, and it’s their job description.
The two disciplines are converging at the edges — a software engineer today is expected to understand the deployment pipeline their code goes through, and a platform engineer is expected to understand enough about application architecture to build a path that actually fits what teams need, not just what’s easy to operate. But converging skill sets doesn’t erase the underlying org-structure question, and that’s the one people keep skipping past.
| DevOps (shared-responsibility model) | Platform Engineering (dedicated team) | |
|---|---|---|
| Who owns the pipeline | Every product team, independently | One platform team, offered as a service |
| Measured by | Individual team’s delivery velocity, uptime | Adoption, self-service success rate, developer satisfaction, tickets avoided |
| Org shape | Flat — no central authority over “how we deploy” | A team with a product, and consumers of that product |
| What “good” looks like | Every team can deploy without waiting on ops | Every team chooses the golden path because it’s genuinely the easiest option |
| Failure mode at scale | N teams, N slightly different implementations of “safe” | One implementation, one thing to get right — and one thing to get wrong |
| Compliance posture | N pipelines, each needs independent review | One vetted pipeline, reviewed once, consumed many times |
Where This Actually Bites — the Audit Surface#
Here’s the part I don’t think gets said plainly enough, and it’s the part that shows up hardest in banking. Under a pure shared-responsibility DevOps model, “every team owns its own promotion path” sounds healthy right up until a PCI-DSS or POPIA-scoped audit asks a simple question: show me how a change reaches production, and prove the control that stops an unreviewed change from getting there. If you have twenty teams with twenty pipelines, that’s twenty different answers. Not because any one team is careless — because twenty independently-evolved implementations of “how do we promote safely” will drift from each other in ways nobody planned, and each one is a separate thing an auditor, or worse, an incident, can find a gap in.
I don’t design against that scenario in the abstract — it’s the shape of the actual problem I get paid to solve. Translating POPIA and PCI-DSS requirements into reference architectures other engineering teams build against, rather than each team independently reinventing its own interpretation of “safe promotion,” is a meaningful part of what a Cloud Architect role in a regulated banking group actually is. The value of that isn’t that it’s more sophisticated tooling. It’s that there’s one implementation to review instead of N, one place the security gate lives instead of N slightly-different gates, one set of promotion policies to reason about instead of N teams each having quietly made their own judgement call about what “reviewed” means.
own pipeline"] --> A1["Auditor reviews
Team A's promotion logic"] T2["Team B
own pipeline"] --> A2["Auditor reviews
Team B's promotion logic"] T3["Team C
own pipeline"] --> A3["Auditor reviews
Team C's promotion logic"] T4["Team D
own pipeline"] --> A4["Auditor reviews
Team D's promotion logic"] end subgraph PLATFORM["Platform engineering"] direction TB GP["Platform team
one vetted golden path"] GP --> C1["Team A consumes it"] GP --> C2["Team B consumes it"] GP --> C3["Team C consumes it"] GP --> C4["Team D consumes it"] GP --> A5["Auditor reviews
one promotion path, once"] end
The left side isn’t a strawman — it’s the honest end state of “every team owns its own ops,” left to run without anyone deliberately consolidating it. Four teams, four separately-evolved answers to “how do we gate a promotion,” four separate places a control can quietly go missing, and four separate conversations with whoever’s checking your compliance posture. The right side is smaller not because platform engineering does less work — building and operating that golden path is real, ongoing engineering effort, carried by a team whose whole job is exactly that — but because the surface a reviewer actually has to examine collapses from N implementations to one.
My own pipeline for this blog is a small, low-stakes version of the right-hand side, and I’ve written the mechanics up properly elsewhere — Progressive Delivery with Kargo covers the Warehouse/Freight/Stage model that decides what gets promoted and when, GitOps Reached Maturity in 2026 covers why a single, boring, consistently-applied promotion path is worth more than a clever one. What I want to point at here isn’t the tooling, it’s the shape: one vetted path, applied the same way every time, is a fundamentally smaller thing to reason about — and to defend — than the same discipline reinvented independently by every team that needs it. A homelab blog doesn’t need an auditor to make that true. It’s true regardless of who’s checking.
The Pay Signal, for What It’s Worth#
One data point worth mentioning without leaning on it too hard: platform engineers are reportedly compensated meaningfully more than DevOps engineers in current market data — figures in the range of a 27% premium show up in industry comparisons. I wouldn’t build an argument on a salary survey. But it’s a useful sanity check that the market is treating these as genuinely distinct disciplines with a distinct value proposition, not just DevOps wearing a new badge. Organisations don’t tend to pay a structural premium for a rebrand.
Summary#
DevOps and platform engineering solve related problems with different org shapes, and the difference is load-bearing, not cosmetic. DevOps distributes operational ownership across every team and calls that distribution the culture. Platform engineering concentrates the how — the golden path, the promotion discipline, the guardrails — into a team that treats internal developers as its actual users and gets measured on whether they choose to use what it built. In an unregulated startup, that difference might just be a matter of taste. In banking, where every promotion path is a control someone eventually has to defend, N bespoke implementations of “safe” versus one vetted golden path isn’t a style preference — it’s the difference between an audit surface you can actually reason about and one you can’t.
Next week I’m turning this lens on my own pipeline — treating the GitOps setup that ships this blog as a thought experiment in what it would take to offer it as a genuine self-service platform, not just a well-run pipeline for one operator.