DevOps Was Never Meant to Be a Team

Why we turned a philosophy into a job title and missed the point entirely

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:

Sarah, start at 11:30pm—put the load balancer in maintenance mode and stop traffic. Midnight, Mike shuts down web tier first, then J2EE servers, flushing EJB cache and closing DB connections.

12:15am, Jennifer and Carlos take a final DB backup, shut down read replicas, clear replication lag, then at 12:45am bring down the primary for schema migration.

Dave, on standby with network until 1am—start data centre maintenance, upgrade ISDN lines, deploy firewall rules. Linda, meanwhile deploys WAR files to staging and runs smoke tests.

1:30am, Jennifer runs migration scripts, Carlos monitors and aborts if needed. Tom updates deployment scripts with new JDBC strings.

2:15am, Linda deploys new app version—start with one WebLogic instance, check health, then roll out to the cluster. Sarah monitors for anomalies.

2:45am, bring load balancer back with 10% traffic, ramp up if stable. Aim for full traffic by 3:30am.

And hope nothing breaks—rollback's worse and SLA penalties hit if we're not live by 6am.

It was a miserable circus. Releases dragged into the morning. Customers were affected. 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.

The Original Vision

The DevOps movement has clear origins. It started with John Allspaw and Paul Hammond's famous 2009 Velocity talk "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." They weren't selling tools or promoting a new team structure. They were sharing how Flickr had broken down the traditional barriers between development and operations to achieve something remarkable: deploying code multiple times per day, safely and reliably.

Their approach was radical for its simplicity. Instead of separate teams throwing work over walls, they had shared goals, shared tools, and shared responsibility. Developers understood operations concerns. Operations understood business requirements. Most importantly, they measured the same things and succeeded or failed together.

This philosophy was later crystallised by Gene Kim in "The Phoenix Project" and "The DevOps Handbook." Kim didn't describe DevOps as a role or department—he described it as a set of practices and cultural patterns that enable high-performing technology organisations. The focus was always on flow, feedback, and continuous learning.

So no, DevOps was never meant to be a team name, 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.

How We Got It Wrong

The transformation of DevOps from philosophy to job title didn't happen overnight. It followed a predictable pattern that many of us have seen repeated across the industry.

First came the consultants and tool vendors. They needed something concrete to sell, so abstract concepts like "cultural transformation" became "DevOps solutions" and "DevOps platforms." The message shifted from Allspaw and Hammond's collaboration model to "buy our tools and hire DevOps engineers."

The irony is that Gene Kim's work explicitly warned against this. "The DevOps Handbook" dedicates entire chapters to the importance of culture and shared responsibility, yet many organisations skipped straight to the tooling sections and missed the foundational principles entirely.

Then came the recruitment industry. Job boards don't have sections for "cultural mindset" or "collaborative approach." They have "DevOps Engineer" postings with bullet points full of tool names. Kubernetes, Docker, Terraform, Jenkins—suddenly DevOps became a technical skill set rather than an organisational principle.

Finally, executives looking for quick wins latched onto the easiest interpretation: create a DevOps team, give them the fancy new tools, and call it transformation. It was faster than the messy work of actually changing how teams collaborate.

The result? We ended up with DevOps engineers who were just sysadmins with fancier titles, working in isolation from the development teams they were supposed to be collaborating with. The wall was still there—we just painted it a different color.

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.

What Real DevOps Looks Like in Practice

When DevOps works as intended, it's often invisible. There's no dramatic "DevOps transformation" announcement because the change happens gradually, team by team, practice by practice.

You see developers who understand their application's resource requirements and can make informed decisions about scaling. You see operations engineers who understand the business context behind the applications they're supporting. You see shared responsibility for incidents, with blameless post-mortems that focus on system improvements rather than individual fault.

You see teams that can deploy on demand because they've automated away the manual, error-prone steps. You see infrastructure that's treated like code because both developers and operations understand the value of version control and testing. You see monitoring that provides business value because the people who built the software also understand what it means when it fails.

Most importantly, you see fast feedback. When something breaks, everyone knows about it quickly. When a feature isn't working as expected, there's data to prove it and tools to fix it. The time between "I have an idea" and "customers are using it" shrinks dramatically.

"But DevOps Means Something Different Now"

Here's where I want to scream.

Every time someone points out that DevOps was never meant to be a team, there's always that person who says: "Oh, but the world has changed. DevOps means roles now. Language evolves. You're being pedantic."

No. No, no, and no.

We haven't "evolved" the definition of DevOps. We've distorted it. And we've convinced ourselves that our distortion is progress.

This isn't like how "cloud" evolved from a vague metaphor to a specific computing model. This isn't natural language evolution. This is a fundamental misunderstanding that became so widespread we started treating it as truth.

It's like saying "Agile means having daily standups and using Jira" because that's what most companies do when they say they're "doing Agile." The fact that it's common doesn't make it correct. The fact that recruiters post "DevOps Engineer" jobs doesn't mean DevOps is now a role.

The original problems DevOps was designed to solve haven't gone away just because we created new job titles. We still have handoffs. We still have blame. We still have slow, risky deployments. We've just moved the dysfunction around and given it trendy names.

When someone says "DevOps is a role now," what they're really saying is: "We gave up on the hard work of cultural change and settled for organisational theatre instead."

The principles that made Flickr successful in 2009—shared responsibility, fast feedback, continuous delivery—those principles still work. They're not obsolete because the industry decided to misapply the label. If anything, they're more relevant now that software is eating the world and deployment velocity is a competitive advantage.

We can choose to do better. We can choose to implement the actual practices instead of just hiring people with "DevOps" in their job title. But first, we have to stop pretending that our distortion is evolution.

Different Operating Models, Same Principles

In Team Topologies, Matthew Skelton and Manuel Pais break teams into four types—stream-aligned, enabling, complicated subsystem, and platform—and define 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.

The Metrics That Matter

If we're serious about DevOps as a means to an end, we need to measure the end, not the means. The DORA metrics, developed from years of research including the work Gene Kim contributed to in "Accelerate," give us a framework: deployment frequency, lead time for changes, mean time to recovery, and change failure rate.

These metrics matter because they reflect the business outcomes that DevOps is supposed to enable—the same outcomes that Flickr was achieving back in 2009. Can we respond to market opportunities quickly? Can we recover from failures fast? Can we deliver features without breaking existing functionality?

Tool adoption doesn't matter. Process compliance doesn't matter. Having a "DevOps team" definitely doesn't matter. What matters is whether we're delivering value to customers more effectively than we were before.

Making the Transition

For organisations stuck in the old model—with separate DevOps teams and traditional handoffs—the path forward isn't to eliminate those teams overnight. That would create more chaos than value.

Instead, start by changing how those teams interact. Instead of taking deployment requests, have platform teams focus on building self-service capabilities. Instead of owning production deployments, have them focus on making deployments safe and easy for development teams to do themselves.

Gradually shift ownership of production issues back to the teams that built the software. Start with non-critical systems and build confidence. Invest in monitoring and alerting so teams can respond to issues quickly. Create runbooks and automation so that responding to incidents doesn't require deep operational expertise.

Most importantly, measure the outcomes. Are deployments getting faster and more reliable? Are incidents getting resolved more quickly? Are development teams spending more time building features and less time waiting for deployments?

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.

The goal isn't to have DevOps engineers. The goal is to have engineers who understand that development and operations are part of the same process, not separate phases. The goal is to have teams that can move from idea to production quickly and safely, without requiring coordination across multiple departments.

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?

The revolution that DevOps promised is still possible. But it requires us to focus on the principles that Allspaw and Hammond demonstrated at Flickr and that Kim codified in his work—not the branding that came later. It requires us to measure outcomes, not compliance. And it requires us to remember that the point was never to create new teams—it was to help existing teams work better together.