A couple of years ago, I was brought in to assess the delivery practices of a mid-size financial services company. They had all the artifacts of a modern engineering organization: a CI/CD pipeline, infrastructure as code templates, a dedicated SRE team, Slack channels named after microservices. The CTO proudly told me they had “completed their DevOps transformation.”
Then I spent a week with the teams.
The CI/CD pipeline existed, but most deployments still required a manual approval chain that took three days. The IaC templates were written by one person and understood by nobody else. The SRE team had become the new operations silo: developers threw code over the wall to them instead of to a traditional ops team. The Slack channels were active, but the conversations were the same ones I would have heard in a ticketing system ten years ago: “Can you restart the service?” “Who changed this config?” “Is anyone looking at this alert?”
They had adopted the tools. They had renamed the teams. They had not changed the culture.
This is what I call DevOps theater: the performance of modern engineering practices without the underlying transformation that makes them work. And after working across hundreds of cloud engagements, I can tell you it is far more common than the success stories suggest.
The Renaming Problem
The most visible symptom of DevOps theater is organizational renaming. Operations becomes SRE. QA becomes “Quality Engineering.” Project managers become “Delivery Leads.” The org chart looks modern. The behavior hasn’t changed.
I worked with a company that had restructured its entire engineering organization around “product teams.” Each team had a product owner, developers, and an embedded SRE. On paper, it was textbook. In practice, the SREs still reported to a central infrastructure manager who controlled their priorities. The product teams had no real ownership of their operational posture. When something broke at 2 AM, the SRE escalated to the infrastructure manager, who escalated to the VP of Engineering, who woke up the on-call developer. Four handoffs for a single incident.
They had the structure of DevOps without the accountability of DevOps.
The renaming problem is seductive because it feels like progress. You can present it to the board. You can put it in a slide deck. You can even hire consultants to validate it. But renaming a team doesn’t change how that team makes decisions, shares responsibility, or responds to failure.
“You Build It, You Run It” as Slogan
Amazon’s famous principle, “you build it, you run it,” has become one of the most quoted and least practiced ideas in software engineering.
The principle is simple: the team that writes the code is responsible for operating it in production. No handoffs. No separate operations team that inherits the consequences of someone else’s design decisions. The feedback loop between building and running is direct and immediate.
In practice, most organizations implement a diluted version. Developers write the code and deploy it through a pipeline, but operational responsibility still lives somewhere else. Monitoring is set up by a platform team. Alerts are routed to an on-call rotation that developers participate in reluctantly. Incident response follows a process designed by someone who has never read the codebase.
The result is a feedback loop that is technically present but practically broken. Developers don’t feel the pain of their operational decisions because someone else absorbs it. The SRE or platform team becomes a buffer that insulates developers from the consequences of their choices, which means those choices never improve.
One pattern I keep encountering: organizations that adopted “you build it, you run it” as a policy but never invested in the capabilities that make it possible. Developers were told they own production, but they were never trained in observability, incident management, or operational design. They were given responsibility without capability, which is a recipe for burnout, not ownership.
The Automation Illusion
Another hallmark of DevOps theater is automation that automates the wrong things.
I’ve seen organizations invest months building sophisticated deployment pipelines while their incident response process is still a shared spreadsheet. Others automate infrastructure provisioning while their change management process requires three email approvals and a calendar invite. And then there are the companies with fully automated testing suites that nobody trusts, so every release still goes through a manual regression cycle “just to be safe.”
Automation without trust is just faster bureaucracy.
The deeper issue is that many organizations automate their existing processes instead of rethinking them. They take a manual deployment process with seven steps and automate all seven steps, including the three that shouldn’t exist. They build a pipeline that enforces the same approval gates that were designed for a world where deployments happened quarterly, not daily.
Real DevOps automation starts with the question: “Should this step exist at all?” If the answer is no, automating it is waste. If the answer is yes, the next question is: “Who should own this, and what feedback does it produce?” Automation that doesn’t generate feedback is just invisible manual work.
The Metrics That Lie
DevOps theater is sustained by metrics that measure activity instead of outcomes.
Deployment frequency is the most common example. Organizations track how often they deploy and celebrate when the number goes up. But deployment frequency without measuring change failure rate, lead time, and mean time to recovery tells you nothing about whether you’re actually delivering value faster.
I worked with a team that deployed 47 times in a single month. They were proud of the number. When I looked closer, 19 of those deployments were rollbacks or hotfixes for the previous deployment. Their actual successful delivery rate was closer to 60%, and their mean time to recovery was measured in days, not hours. The deployment frequency metric said “high-performing team.” The reality said “team in constant firefighting mode.”
The DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recovery) exist precisely to prevent this kind of self-deception. But even DORA metrics can become theater if they’re measured without context. A team that deploys frequently to a staging environment but batches releases to production every two weeks is not a high-performing team, regardless of what the dashboard says.
Metrics should create accountability, not comfort. If your metrics make everyone feel good but nothing is actually improving, you’re measuring the performance, not the practice.
Why the Culture Doesn’t Change
If the tools are available and the frameworks are well documented, why does DevOps theater persist?
Three reasons, consistently.
First, cultural change requires vulnerability. Admitting that your team doesn’t actually own production, that your pipeline is a formality, that your SRE team is just ops with a new name, requires leaders to acknowledge that the transformation they sponsored didn’t fully land. That’s a hard conversation, especially when the board has already been told it succeeded.
Second, DevOps culture requires trust between teams, and trust is built through shared consequences. When developers and operations share on-call rotations, share incident reviews, share the pain of a bad deployment, trust develops naturally. When those experiences are separated, when one team builds and another team suffers, trust doesn’t form regardless of how many “blameless postmortem” templates you adopt.
Third, and this connects to something I explored in the four things AI cannot replace in the people you hire: DevOps culture depends on the same human qualities that no process can manufacture. Teamwork that goes beyond collaboration. Adaptability that questions assumptions, not just learns new tools. Empowerment that distributes ownership instead of hoarding it. Organizations that hire for individual output and reward individual heroics will struggle with DevOps regardless of their tooling investment.
What Actually Works
After working across hundreds of engagements at Clouxter, the organizations that genuinely practice DevOps, not just perform it, share a few characteristics.
At Clouxter, we earned the AWS CloudFormation Service Delivery designation as one of our first steps in building a disciplined cloud practice, and later the AWS DevOps Competency. That was about six years ago. What we see in customer environments today is fundamentally different from what we saw then, which is itself proof that DevOps is never a destination. But the patterns that separate real practice from theater have remained remarkably consistent.
When we run DevOps maturity assessments with customers, the gap between perceived maturity and actual maturity is consistently the most surprising finding. Teams that rate themselves as “advanced” often score at foundational levels in culture and process, even when their technology scores are high. The tooling is modern; the behavior is not. That gap is where theater lives, and making it visible is the first step toward closing it.
The organizations that close it, share a few characteristics.
They start with ownership, not tools. Before selecting a CI/CD platform or designing a pipeline, they answer: “Who is accountable for this service in production, and do they have the authority and capability to act?” If the answer is unclear, they fix that first.
They invest in operational literacy. Developers learn observability, incident response, and operational design as core skills, not optional extras. This isn’t a training program; it’s a hiring criterion and a career progression expectation.
They measure outcomes, not activity. Deployment frequency matters only in the context of change failure rate and recovery time. Lead time matters only if it measures the full cycle from commit to customer value, not just the pipeline execution time.
They treat incidents as learning, not blame. Blameless postmortems are common in name; they’re rare in practice. The organizations that learn from failure are the ones where the postmortem produces a concrete change, not just a document. If your postmortem archive is growing but your incident patterns aren’t changing, the process is theater too.
They accept that DevOps is never “done.” The companies that declared their DevOps transformation complete are usually the ones performing theater. The ones that treat it as a continuous discipline, revisiting practices, questioning assumptions, adapting to new capabilities, are the ones that actually improve.
And everything I’ve described here applies with even higher stakes when you add security to the equation. Organizations that renamed their process “DevSecOps” without embedding security into the development flow, without giving developers security literacy, without making security a shared responsibility rather than a gate at the end, are performing the same theater with far greater consequences. Security theater in a DevOps pipeline doesn’t just slow you down; it creates the illusion of protection while leaving real vulnerabilities unaddressed. That dimension deserves its own conversation, and I’ll explore it in a future post.
The AI Dimension
This matters more now than it did five years ago. As AI becomes part of the engineering workflow, the gap between DevOps theater and genuine DevOps practice widens, and not just because of coding assistants.
AI is reshaping every stage of the delivery pipeline. AI-generated infrastructure code looks syntactically correct but often ignores organizational standards, security policies, and the operational context that a senior engineer carries in their head. AI-assisted code review and security scanning in CI/CD pipelines produce results that teams accept uncritically, creating false confidence in a pipeline that was already theater. AI-driven monitoring and alerting generates noise instead of signal when the operational model underneath is broken, because the AI has no context for what “normal” looks like in an environment nobody truly understands.
And then there’s the compounding effect. AI enables teams to create new services, new infrastructure, and new integrations faster than ever. In an organization practicing genuine DevOps, that speed is absorbed by tight feedback loops, real ownership, and operational literacy. In an organization performing theater, that speed creates new services that nobody owns, new infrastructure that nobody monitors, and new integrations that nobody understands. The governance gap doesn’t grow linearly; it compounds.
The question is not whether your organization has adopted DevOps. The question is whether the adoption changed how people work, or just how the org chart reads.
The Honest Question
If you’re a technology leader, here’s a question worth asking your teams, and being honest about the answer:
When something breaks in production at 2 AM, what actually happens? Not what the runbook says. Not what the incident response process describes. What actually happens?
The distance between the documented process and the real behavior is the distance between your DevOps practice and your DevOps theater.
Closing that gap is not a tooling problem. It’s a leadership one.
Ricardo
