In retrospect, DevOps was a bad idea.

We need to talk about DevOps.

In the beginning, DevOps made sense. It was a logical evolution of healthy engineering practices. But we never should have given it a name. Once we labeled it, it got completely out of hand.

Before DevOps, developers would write software and hand it off to an operations team, who then had to figure out how to get it running in production. This didn’t work very well. Eventually, developers who cared about deployment started getting involved in making sure their code made a smooth transition to production. That was a huge improvement.

And that’s where we should have stopped.

We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset—a necessary shift away from isolated ops teams managing production without developer participation.

When cloud services arrived, this shift became even more natural. Spinning up a server was no different than calling an API. Infrastructure could be programmed. It could be versioned. It could be tested.

But then we made a terrible mistake: we gave it a name—DevOps.

Suddenly, developers who were good at working with production systems were given a new title. And as soon as “DevOps engineer” became a role, people started forming DevOps teams. That was the beginning of the end.

When we created DevOps engineering teams, we pulled engineers away from product teams and gave them a new mission. We left product development teams without anyone focused on production. We undid everything that made DevOps work in the first place.

Effectively, we created a new operations team called DevOps, and operations went back to managing production in isolation. Sure, they adopted newer tools and sprinkled in some automation. But that’s really beside the point, because the real benefit of DevOps came from empowering developers to own their deployment pipelines and automate their production processes—tailored to their team’s specific needs.

Once again, companies tried to standardize everything and chase economies of scale. In the process, they stripped DevOps of its usefulness.

Now, DevOps teams build internal tooling designed more to restrict than to empower. They wrap every API in layers of homegrown abstractions, which fall behind what cloud providers like AWS already offer. Developers end up begging for support for features that are already standard elsewhere.

Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production. And because DevOps owns the compliance checklists, they bake that mistrust into the rules. SOC compliance, for example, ends up filled with restrictions that assume developers are potential bad actors—rules that hinder more than they help.

Of course, this is all completely pointless. A DevOps engineer is just as capable of malicious behavior as any other engineer. The solution isn’t to block access—it’s to make actions transparent and reviewable. Security comes from visibility, not locked doors.

So what did creating a “DevOps” role actually get us?

It pulled production-minded engineers off their teams and stripped those teams of both the interest and the permission to manage their own production environments. We ruined the idea of DevOps by formalizing it.

P.S. Platform Engineering is the same story. In the words of Yogi Berra, “It's déjà vu all over again.”