DevOps Is Dead, Long Live Platform Engineering

A while back I was in a room arguing about scrum. Then kanban. Then scrumban, which is apparently a thing now.

My position was narrow. None of it survives operational or architecture work. Priorities shift under you mid-sprint. Half your clarifications depend on a third party who has never heard of your ceremonies and owes you nothing. Try point-estimating “work out why this landing zone grew the way it did.”

Somewhere in there the conversation slid to DevOps, and a couple of scrum masters told me it was the best thing to happen to software delivery. So I asked the only question I actually had. Then why aren’t your teams shipping secure, compliant, scalable deployments?

Because that was the brief. I was there to harden what the client themselves called an “organically grown, non-centrally governed” landscape.

I’ve heard some version of that phrase in several countries now, on more than one continent. Different industries, different headcounts, same euphemism. When a sentence travels that far it stopped describing a local failure of discipline a long time ago.

So here’s the claim. DevOps was a good idea that got mistranslated on the way through the industry, and we then industrialised the mistranslation into a tax on every engineer’s working memory.

That tax is the whole story.

Platform Engineering is the correction. Treat the platform as a product, developers as its users, and deliver it on three rails: a Golden Path, an invisible policy guard, and an automatic feedback loop.

Ever had code that was done, tested, reviewed, and you still couldn’t ship it that day? More than once in a quarter? Then you’ve felt the symptom. This is the post-mortem.

The charge sheet

Three counts. Misrepresentation, cognitive overload by design, and velocity theatre.

Start with the misrepresentation. The 2009 DevOps manifesto said “break the wall between Dev and Ops.” Somewhere between 2015 and 2020 that sentence quietly became “every developer is now also an ops engineer.” Read them side by side. One is about collaboration. The other is about load transfer.

Not the same sentence.

The second count is cognitive overload, and it’s built in. Look at the gap between a job title and a job. The title says Software Engineer. The actual job: write features, configure and maintain pipelines, manage Helm charts, triage security scans, write runbooks, respond to incidents, attend compliance reviews, debug infrastructure you did not build, and learn three new tools a quarter. Ask any room which of those they signed up for in the interview. The silence is the answer.

Go and read your own team’s job ad. Then read their last two weeks of tickets. If those two documents describe the same job, you can stop reading here.

Third count: velocity theatre. DevOps promised faster delivery. At elite organisations, deployment frequency genuinely climbed. The median organisation got more process, more gates, and more tools. Speed became something you measured instead of something you felt. Adding tools to a pipeline is a project. Delivering a paved road developers actually use is a product.

Most of us shipped the project and called it the product.

The variable nobody budgets for

Human working memory is finite, and badly implemented DevOps spends it on the wrong thing. Cognitive Load Theory splits the demand in two. Intrinsic load is the complexity of the problem you are actually solving. Extraneous load is the complexity of the environment you’re solving it in.

Done badly, DevOps maximises the second one. Your best thinking goes into the scaffolding instead of the building. When working memory is full of Helm values and effective-routes tables, there’s no room left for an elegant solution to the real problem. Call that a motivation problem if you like. It’s a hard ceiling on how much architecture quality a tired engineer can produce, and no amount of wanting it more raises the ceiling.

You cannot standup your way out of a memory limit.

The data tells a more complicated story than “elite teams just try harder.” What elite performers share is structural. Standardised pipelines they didn’t each reinvent. Self-service infrastructure that doesn’t route through a ticket queue. Automated security and compliance gates. Dedicated platform support for on-call. They didn’t hand every developer more tools. They gave every developer fewer decisions.

And finish the famous quote properly. “You build it, you run it.” Werner Vogels, 2006. What Amazon also built, and kept internal, was the platform that made that sentence survivable: their own infrastructure layer, deployment system, and build system. The slogan travelled. The platform that made it possible stayed home.

We copied the poster and left the machine behind.

Three crime scenes

Field notes, not architecture diagrams. This is what shows up in the Slack channels.

The first is a bottleneck nobody named. Developers open tickets to deploy. There’s no self-service, so every road leads to one team. That team burns out, developers slow down, everyone blames everyone. Same shape at fifteen people and at four thousand.

The second is a tooling graveyard. Jenkins in 2019, GitLab CI in 2020, GitHub Actions in 2021, Argo CD in 2022, Crossplane in 2023. Each one adopted for a good reason. None ever removed. In isolation every layer made sense. Stacked together they’re geological. New developers spend their first three months just learning the topology. (I have personally added a layer to a stack like this and written a very confident document explaining why it would replace the previous two. It replaced nothing. It is still running.)

The third is a security standoff. The developer says security is slowing them down. Security says developers bypass their controls. Both are right. Both are having a conversation that should have been automated away. Security as a gate creates friction. Security as a rail creates speed. The difference is whether someone built the track.

One root cause sits under all three: the platform is implicit. Everyone maintains it, nobody owns it, it grows by accident, and it never gets better by design. The organisations winning right now made a single decision. The platform is a product, and developers are its users. That’s the whole thesis. A decision about ownership, taken before the tool swap and before the reorg, which is why both of those usually fail without it.

”But it worked for us”

“Hold on. We did DevOps properly and it worked fine for us.”

Sometimes it did. And if it did, congratulations, you accidentally built a platform. Somebody on your team is quietly maintaining it in the gaps between their real work, and when they leave you will find out exactly how much of it lived in their head. The job now is to make it intentional, before that happens.

DevOps genuinely works under specific conditions. Small autonomous teams. An early product moving fast. Everyone sharing context in the same Slack and the same standup. An ops burden light enough to carry alone. At that scale it’s good, and nobody is taking it from you.

Then it breaks. Past eight to ten engineers. When products mature into compliance, audits, and SLAs. When context stops being shared across timezones and codebases. When the ops burden compounds faster than you hire. When you need developers who are experts in the product domain rather than the infrastructure one.

It doesn’t fail because your engineers aren’t good enough. It fails because it doesn’t scale to complexity. And complexity always arrives.

So here’s the uncomfortable version of the claim. “You build it, you run it” is still the right principle, but as a staffing model it is finished. If your answer to operational complexity is to distribute it evenly across every engineer, you have not adopted a culture. You have declined to build a product, and you are billing the difference to your developers’ attention.

Three rails

A Golden Path for how to build. An Invisible Guard for how to stay safe. A Feedback Loop for how to know it’s working. Rails aren’t walls. You can leave them. But the path of least resistance is the path that works.

Rail	What it provides	Developer surface area
Golden Path	One opinionated, maintained, supported route from git init to production	platform new service --template api-node
Invisible Guard	Security, compliance, and governance enforced in the pipeline, by code reviewing code	A policy check on every pull request, no human in the loop for the common case
Feedback Loop	Observability as a platform feature, wired automatically on deploy	A few lines of service metadata in values.yaml

Start with the Golden Path. One opinionated route that just works. `platform new service --template api-node` creates the repo, configures the pipeline, ships a hardened Dockerfile, enables security scanning, and wires observability. First deployment in minutes instead of three days of asking colleagues which Helm chart to pick. Call the template a shortcut and you've misread it. It carries every ops lesson the organisation ever paid for, packaged so the next developer never has to learn any of them the expensive way.

The Invisible Guard enforces security, compliance, and governance at the pipeline level. Not humans reviewing tickets. Policy-as-code on every pull request. A policy that says “no container runs as root” or “no secret in an environment variable” doesn’t block your sprint. It blocks the specific line of code that would have become a 2am incident. Governance doing its job invisibly, catching problems immediately and cheaply rather than late and expensively at a gate.

This is where the platform conversation meets the governance conversation. When security and architectural standards are enforced as code in the pipeline, your governance posture stops being a slide deck someone updates the week before an audit. It becomes a property of the running system. The same logic scales from a single pull request up to the whole environment: an architecture assessed continuously against a defined standard produces evidence as a by-product of building.

That last part is the bit I got tired of doing by hand. I assess Azure estates for a living, and the job kept ending the same way: a careful set of findings against the Well-Architected Framework, mapped to the controls an auditor would ask about, delivered as a document that started going stale the day I sent it. Doing that once is consulting. Doing it continuously is a product, so I built Platform Architecture Authority to do it continuously. If you want to see the standard it assesses against, the Azure architecture governance checklist and the Well-Architected security pillar walkthrough are the honest version of it.

The Feedback Loop makes observability a platform feature, not a developer responsibility. Developers should not hand-build log aggregation, metrics scraping, distributed tracing, alert routing, and SLO dashboards for every service. They should deploy and automatically get a dashboard, an error rate, a P99 latency, and a paging rule. A few lines of service metadata (name, team, tier, language) and the platform wires the rest. That’s the developer’s surface area. Everything underneath is the platform’s problem. Operational-excellence pillar, made real. See the Well-Architected operational excellence walkthrough.

The verdict

DevOps is guilty of mistranslation. Not malicious, not incompetent. A good idea industrialised wrong. The tooling multiplied while the developer hours did not. Security became a gate instead of a rail. Speed became something teams measured instead of something they felt.

Platform Engineering is the sentence, served.

“You build it, you run it” stays true. “You configure it, you secure it, you monitor it, you pipeline it, you Helm-chart it, you on-call it” was never the job, and if that is what your org currently means by DevOps, then the humane thing to do is stop calling it a culture and start calling it an unfunded product.

The best platform is the one your developers never have to think about. Go build that one.

Frequently asked questions

What is the difference between DevOps and Platform Engineering? DevOps is a culture: Dev and Ops sharing ownership of the full lifecycle. Platform Engineering is the structural correction that makes that culture survivable at scale. It builds an internal platform as a product, so developers get self-service paths instead of each carrying the full operational burden personally. Think of it as DevOps with the platform Amazon kept in-house.

Does Platform Engineering just move complexity to the platform team? Yes, deliberately. Complexity doesn’t disappear. It moves to a team that specialises in managing it, where it can be solved once for everyone instead of re-solved by every product team. That concentration is the entire point. An implicit platform maintained by everyone and owned by nobody is the failure mode being corrected.

What about small teams that cannot afford a platform team? Start with conventions, not tooling. A documented golden path, a shared Makefile, and one automated security check cost nothing and deliver most of the early benefit. Treat your most-deployed service type as a template, give it a README, and scale the investment up as the team grows. You don’t need permission or a budget line to begin.

Is policy-as-code worth the setup effort? For any organisation with compliance, audit, or SLA obligations, yes. It shifts security and governance checks left. They run in seconds on every pull request, catch problems when they are cheap to fix, and produce an evidence trail as a by-product. The alternative, a human gate at the end, finds the same problems late, expensively, and inconsistently.