What Is DevOps?

Only those of us old enough to have lived through the pre-DevOps world can truly appreciate just how revolutionary the idea really was. I remember those long, dreaded release planning meetings before a Big Bang production deployment. People from alien departments—who hadn’t spoken to each other all year—would suddenly be packed into a room to plan what sounded like a bank heist:

“You come in at midnight and shut down system X. At 1:15am John will install system Y. At 2am Jane will update the config and deploy the hotfix. At 3am Tom will bring system X back online…”

It was a miserable circus. Releases dragged into the morning. Customers were impacted. Money was lost. And when things went wrong (they usually did), the finger-pointing began. The rollback process was even worse—sometimes more dangerous than the release itself.

That chaos is exactly what DevOps was trying to fix. Not with tools, but with a fundamental shift in how we work.

It’s wild how often we still need to say this: DevOps was never meant to be a team name. The original idea wasn’t to split work between developers and a new group of engineers wearing a different badge. It wasn’t about rebranding sysadmins. It was a cultural and organisational shift aimed at tearing down walls, not putting up new ones with fresh paint.

But that’s exactly what happened in a lot of places. The wall between Dev and Ops got relabelled “Dev” and “DevOps” instead. The same ticket queues, handoffs, blame games. We just made it sound cooler.

To make things clear, let’s use Donovan Brown’s definition:

“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”

That’s it. It’s about value, not roles. Collaboration, not control. And continuous delivery, not coordination overhead. The focus is on outcomes—moving ideas to production swiftly and safely—not job titles or tools.

And that bit about continuous delivery? That’s not a footnote. That is the point.

DevOps and Continuous Delivery: Two Sides of the Same Coin

DevOps doesn’t exist in a vacuum. It came about because we needed to deliver software faster, more reliably, and with less drama. That’s exactly what Continuous Delivery (CD) is about—being able to release any version of our software, at any time, with confidence.

If we think of CD as the outcome, then DevOps is how we get there.

CD demands fast feedback loops. Tests need to be quick and reliable. Deployments need to be automated and safe. Rollbacks should be instant. Infra needs to be reproducible and boring. That doesn’t happen if devs and ops are tossing work over the wall and hoping for the best.

So DevOps breaks down those walls. It’s the cultural and organisational shift that allows CD to actually work in practice. It’s what makes it safe for teams to merge to trunk multiple times a day, to deploy often, and to treat production as something to interact with, not fear.

Things like test automation, CI/CD pipelines, feature flags, infrastructure as code, observability, trunk-based development—those are all enablers of CD, and they all require cross-functional collaboration. No one team can do it alone.

You Build It, You Run It (But You’re Not Alone)

Now, “you build it, you run it” doesn’t mean developers have to become ops experts. That’s a common misunderstanding. It means that teams should own their software in production—know how it behaves, respond to incidents, monitor performance—not hand it off the moment it’s deployed.

But to make that sustainable, we need infrastructure professionals—platform engineers, SREs, cloud specialists—working closely with devs, not in isolation.

The job of a platform team isn’t to take tickets from developers. It’s to build self-service capabilities so developers can own more of the delivery pipeline themselves without needing to be Kubernetes wizards. That means things like templates, golden paths, sandbox environments, auto-scaling setups, CI/CD as a service. The goal is to reduce friction and cognitive load, not push responsibilities around.

Different Operating Models, Same Principles

This is where Team Topologies gives us a helpful lens. It breaks teams down into types—stream-aligned, enabling, complicated subsystem, and platform—and defines how they interact: collaborate, provide services, or facilitate.

The key is to be deliberate. If we’ve got a stream-aligned team building a product, then a platform team should be building tools and infrastructure that make delivery smoother for them. Not telling them how to deploy, but giving them paved roads so they don’t have to build the motorway themselves.

That’s real DevOps: shared responsibility, local autonomy, high alignment. Not “Dev gives code to DevOps and walks away”.

Some orgs go fully vertical—each team owns everything, end to end. Others rely on strong platform teams to provide leverage. Some keep a few enabling teams around to help build skills across the org. It doesn’t really matter how many teams we have or what they’re called, as long as they’re optimised for fast, safe delivery of value.

Wrapping Up

If we slap the label “DevOps” on a team and keep doing things the old way—separate queues, handoffs, blame games—then we’ve missed the point. DevOps was never about job titles. It’s about removing friction between those who build and those who run software, so we can deliver value continuously and confidently.

So next time we see a team called “DevOps”, maybe we ask: are we actually delivering better, faster, safer? Or are we just decorating the same old silos?