There's No Fix for a Blame-Shifting Culture

Years ago, I caused a production incident.

I uploaded in-development code to staging, and somehow it ended up applied to production.

I rolled the source back quickly and avoided real damage, but the aftermath inside the company was ugly.

The cause was simple: a flawed handover document.

At the company I was at then, the new-development team and the maintenance team were separated. The maintenance side handled additional development and releases while operating the system in production.

CI/CD as we know it today wasn’t mature yet. We had version control, but releases were manual, run from a written procedure document.

The procedure had originally been written for “development → staging.” When the production environment was added later, somewhere along the way a copy-paste mistake slipped in.

The result: what looked like a staging connection string was actually pointing at production.

Naturally, the response was, “The handover doc is broken.”

But from the new-development side, a different message came back: “It’s the maintenance team’s fault for not checking production logs in advance.”

The atmosphere on the floor turned sour fast.

Looking back now, “you should have verified in production beforehand” is also a fair point.

But the deeper problem wasn’t process. It was culture.

The new-development side: “We built it. You take it from here.”

The maintenance side: “Nobody told us anything.”

To make it worse, new-development and maintenance had originally been separate companies. The merger was, in practice, an acquisition. There was barely any movement of people between them, and not much goodwill either.

If people from each side had been seconded into the other for some shared operations period, this kind of dumb mistake never would have happened. But that didn’t happen.

Once you’re in this situation, individual safety measures can’t keep up.

You can add more checklists. You can tighten the procedure. You can layer on more reviews.

But as long as the underlying culture is “push it onto the other team,” something will break.

A major incident is rarely a single technical mistake. It surfaces as the accumulated result of human-side problems:

• Organizational silos
• Insufficient information sharing
• Pushing responsibility back and forth
• The “someone downstream will handle it” attitude

Today, CI/CD and IaC are standard, and a runbook typo taking down production has, fairly, become rare.

But what I keep noticing in the field is that the underlying problem hasn’t disappeared. It’s just changed shape and reappeared somewhere else.

“I thought the other team was setting up the Terraform permissions.”

“It’s in CI now, so SRE can take it from here.”

“The docs are in Confluence — please read them.”

Only the tools have changed. The structure is exactly what it was back then.

What technology can solve is “how easy it is to make a mistake.” It can’t fix “lack of interest in someone else’s work.”

So the first thing I look at when designing a system isn’t the architecture diagram or the pipeline.

It’s whether the people who are going to operate it can talk about each other’s work as if it were their own.

If that part is intact, most incidents get caught before they happen.

If that part is broken, no matter how impressive the machinery you put in place, the same hole opens up sooner or later.

In the end, what we’re really up against isn’t the tools or the runbooks. It’s always the distance between you and the person sitting next to you.