Every once in a while, our industry needs a good, sharp elbow to the ribs. Not a cheap shot. A wake-up jab. That’s exactly what Charity Majors delivered in her recent Honeycomb blog post, “You Had One Job: Why Twenty Years of DevOps Has Failed to Do It.”
If you’ve known Charity as long as I have, you know this is her superpower. She’s never been shy about an opinion. She’s dynamic, fearless, and above all else, really sharp. I admire and respect her tremendously, and I genuinely enjoy having her involved in Techstrong activities. She makes every conversation better by refusing to let it get comfortable.
Her argument, boiled down, is this: DevOps set out to do one core thing, get developers to care about their software in production, and by that measure, it failed. Not dead. Not useless. But failed at its primary mission. That’s a provocative take, and like most good provocations, there’s a lot in it I agree with and some I don’t.
Let’s start with the easy part. DevOps has been far from perfect. Anyone who says otherwise is selling something. Too often, “DevOps” became a job title, a tooling checklist, or worse, a rebranding exercise for the same old silos with better conference swag. And yes, getting developers to care about what happens after the code hits Git, all the way through deployment and into real-world behavior, remains uneven at best. Charity is right to call that out.
But here’s where I start to push back, in true Shimmy fashion. Whether DevOps “failed” depends entirely on where you’re standing and what yardstick you’re using.
One of the enduring, almost comical truths of DevOps is this: Developers often think DevOps is too Ops-centric. Ops folks think DevOps is too Dev-centric. Both sides are convinced the other one got the better end of the deal. You know what that usually means? It’s probably a decent deal. Nobody got everything they wanted, which is often the only way progress happens.
The truth, as usual, lives somewhere in the messy middle.
Ask an Ops person what DevOps success looks like, and you’ll hear something very close to what Charity is advocating: Developers who care deeply about reliability, performance, and behavior in production. Ask security teams and you’ll get a different answer. For them, success is when everyone shares responsibility for security, when “shift left” actually shifts something besides PowerPoint slides.
Ask developers, and many will tell you DevOps succeeded when it removed friction. When it let them automate the non-coding work so they could, you know, actually write code. Platform engineers will talk about internal developer platforms, golden paths, and guardrails that let teams move faster without blowing themselves up. SREs, data scientists, and release engineers all bring their own definitions to the table.
That’s not a bug in DevOps. That’s the thing.
DevOps has always been slippery. It resists clean definitions. It refuses to sit still long enough for a standards body to nail it down. At its core, DevOps was never about a single outcome. It was about breaking down silos, increasing communication, and getting more people aligned around delivering value. Success, in that sense, was always going to be plural, not singular.
Charity is absolutely right about one thing that sits at the heart of her argument: Feedback loops matter. If developers don’t see what happens to their code in the wild, they can’t get better at building resilient systems. This is where observability enters the story, and it’s no accident that Charity has been one of its most forceful champions.
But here’s an uncomfortable truth we don’t say often enough. When DevOps first emerged, observability, frankly, kind of sucked. We didn’t even use the word much back then. The tools were blunt. The data was overwhelming but not insightful. We collected logs, metrics, and traces mostly because we could, not because they reliably told us what to do next.
Charity is right again when she argues that without advanced analytics, without machine learning, without the ability to actually make sense of massive volumes of data, observability can’t fulfill its promise. You can’t make wine before its time. You are only as good as your tools.
And what a time to be alive.
AI has changed the equation, not just a little, but fundamentally. It has turned observability from a passive recording system into an active partner in understanding complex systems. Suddenly, those feedback loops Charity talks about are not just possible, they’re actionable. It’s no coincidence that OpenTelemetry and other observability projects are dominating conversations in the CNCF and across the market. The ecosystem finally caught up to the ambition.
But AI’s impact doesn’t stop there. It’s transforming how we write code, test code, secure code, and operate systems. It’s collapsing feedback cycles that used to take weeks into minutes. It’s making it easier for developers to see downstream consequences and for Ops teams to surface upstream insights. In other words, it’s doing exactly what DevOps always wanted to do, just with far better leverage.
So if DevOps wasn’t fully delivering on its promise twenty years ago, that doesn’t make it a failure. It makes it early.
As Andrew Clay Shafer famously said, “The DevOps you get is the DevOps you deserve.” I’d add this: The DevOps you get is also the DevOps your tools allow. DevOps needed AI. It needed better data. It needed observability that could actually observe, not just collect.
From that vantage point, DevOps didn’t fail. It evolved. It struggled. It disappointed at times. But it also laid the cultural and organizational groundwork that makes today’s AI-powered tooling meaningful. Without DevOps, AI would just be another shiny object bolted onto broken processes.
Charity’s essay is valuable precisely because it forces us to confront our assumptions. It reminds us that slogans aren’t outcomes and that intent doesn’t equal impact. On that, we agree completely.
Where we differ is on the verdict. Failure implies finality. DevOps was never finished. It’s still becoming. And now, finally, it has the tools it always needed to be what so many of us hoped it could be.
That doesn’t mean the job is done. It means the job just got interesting.
