The easiest way to spot fake DevOps is to watch what happens after a bad release.

The deployment finishes. Customers begin reporting errors. Slack fills with screenshots. Then somebody says, “The pipeline passed, so this must be an operations issue.”

There it is.

A company can have Kubernetes, Terraform, automated tests and enough dashboards to cover a cinema wall. If people still throw problems across departmental borders, they haven’t really changed how they work. They’ve just made the handover faster.

I’m not against the tools. Some are excellent. But the industry has spent years selling DevOps as a shopping list because shopping is easier than changing behaviour.

Buying Software Is the Comfortable Part

A new tool gives everyone something visible to discuss.

There are demos, feature comparisons and a migration plan with coloured boxes. Leaders approve a budget. Engineers debate configuration. Six months later, the company has a modern delivery platform and the same old arguments.

Developers still want to release quickly. Operations gets blamed when production becomes unstable. Security arrives near the end with objections. Support hears about the release from customers.

The tool usually works.

The organisation doesn’t.

I once saw a team automate deployments that previously required a long checklist. It was genuinely useful. Releases became much faster. The awkward part was that only two people understood the automation, and neither was on call during weekends. When the pipeline failed on a Friday evening, everyone waited for Monday.

They had removed manual work without sharing knowledge. Progress, technically.

“You Build It, You Run It” Gets Abused

I like the idea that developers should remain responsible for software after it reaches users. It changes the quality of decisions when the person adding a feature may also receive the 2 a.m. alert.

But some companies turn this into a slogan and use it to dump more work on developers.

Shared ownership does not mean every developer must become a cloud expert, security analyst and incident commander. It means the team cannot treat production as somebody else’s mysterious basement.

Developers should understand how their code is deployed, monitored and recovered. Operations people should be involved early enough to influence design rather than receiving a finished system on release day. Security should not arrive like airport customs after everyone has packed.

Different skills still matter. The wall between them is the problem.

The Real Test Happens When Something Breaks

Culture is easy to praise during planning meetings.

Incidents reveal it.

Does the first conversation focus on restoring service, or on finding who approved the change? Can someone admit, “I don’t understand this part,” without looking incompetent? Does the person with useful context join the call, even if the failure falls outside their formal role?

Blame makes systems less observable because people begin hiding uncertainty. They delay reporting small mistakes. They write cautious incident reports that reveal nothing. Every failure becomes a courtroom scene.

Good teams are not endlessly cheerful. They can be irritated, tired and direct. The difference is that they aim the frustration at the problem.

Afterward, they ask why the system allowed one mistake to cause so much damage. Maybe the test environment was unrealistic. Maybe rollback took too long. Maybe an approval step existed only in someone’s memory.

“Be more careful next time” is not an engineering improvement.

Small Releases Require Trust

People often describe frequent deployment as a technical capability. It is partly that. Automated testing and delivery pipelines matter.

But releasing small changes also requires people to trust the process and each other.

A product manager has to accept that every update will not arrive inside a dramatic quarterly launch. Engineers need confidence that a failed experiment won’t become a performance-review anecdote. Operations needs a reliable rollback path. Support needs to know what changed before customers start asking.

Without that trust, companies gather changes into large releases because large releases feel official. More meetings. More approvals. More ceremony.

Then the release becomes so risky that the ceremony seems justified.

The loop is almost elegant.

Documentation Nobody Can Use Is Another Handoff

Here’s the thing. Collaboration does not mean sitting in more meetings.

Sometimes good DevOps culture looks like a useful runbook written before the person who knows everything goes on leave. Sometimes it is a deployment message in Slack that explains what changed and what to watch. Sometimes it is a developer adding context to an alert so the on-call engineer does not search through six dashboards.

These are small acts of respect.

A colleague once inherited a service with documentation that said, “Restart if required.” Required when? Restart which process? In what order? The document was technically present and practically useless.

Teams underestimate how much operational knowledge lives in casual conversations. One engineer knows that a warning can be ignored. Another knows the database job must never run during billing. None of it appears in GitHub.

Then someone leaves.

Metrics Can Expose Bad Habits, but They Can’t Fix Them

Companies like measuring deployment frequency, failure rates and recovery time. Fine. Numbers can show where work is getting stuck.

They can also become theatre.

If teams are judged only on deployment count, they split meaningless changes to increase the number. If incident volume looks bad, people quietly reclassify incidents. If recovery time becomes a target, teams may declare the incident over while customers are still cleaning up.

Metrics work when they support a conversation. They become harmful when the number replaces it.

The useful questions are less impressive: What repeatedly slows releases? Which failures surprise us? Where does one team wait for another? What knowledge belongs to only one person?

You don’t need a new platform to ask those.

Tools Should Follow the Awkward Conversation

The best DevOps improvements often begin with a complaint nobody wants to hear.

Testing takes too long. Developers cannot reproduce production bugs. Operations receives changes without context. Nobody knows who owns an old service. A rollback requires twelve manual steps and one person’s laptop.

Start there.

Then choose automation, monitoring or infrastructure tools that remove the specific friction. Otherwise the company ends up adapting its work to whatever product it bought, which is how simple processes become ceremonies with YAML files.

DevOps is not people being nice to each other. It is people sharing responsibility for getting software safely into users’ hands and keeping it useful afterward.

The tools can support that.

They cannot make someone care after saying, “My part is done.”