TL;DR
DevOps doesn’t fail because teams resist change. It fails because leadership offloads responsibility downward while keeping authority upward. When DevOps is used to work around bad management instead of forcing it to improve, it becomes exploitation with better tooling.

DevOps Without Abdication#

A Counter-Manifesto

There are books that help organizations improve. And there are books that help organizations feel justified.

The Phoenix Project and The Unicorn Project are often praised as foundational DevOps texts. They describe real pain, real dysfunction, and practices that genuinely help people survive broken systems. That part is true.

The problem is what many leaders take from them.

Too often, these books are treated as a management bible—less for what they demand of leadership, and more for how they teach organizations to function around leadership, resulting in adapation and not transformation.

And adaptation, while impressive, should not be confused with health.

DevOps Was Not Meant to Fix Management Failure#

DevOps emerged to reduce friction between development and operations. It assumes, quietly but critically, that leadership is capable of doing a few basic things:

set and defend clear priorities
limit work to available capacity
absorb accountability
protect teams from thrash
respect boundaries

When those conditions exist, DevOps amplifies effectiveness.

When they don’t, DevOps is just survival strategy, with a boot on your neck.

Many practices celebrated as “DevOps maturity” are actually employees compensating for absent leadership, aligning work themselves, managing risk themselves, and creating safety for one another because no one above them will.

Institutional triage, not empowerment.

Psychological Safety Is Not an Innovation#

If a framework needs to introduce psychological safety, something upstream is already broken.

Healthy organizations do not need to teach people that:

it is safe to speak honestly
mistakes will not end their careers
work will not invade their private lives

These are not cultural achievements. They are baseline management responsibilities.

When psychological safety becomes a “practice” instead of a property of leadership, responsibility quietly shifts downward. Teams are told to be open, resilient, and bravew, hile the structures that punish those behaviors remain untouched.

Safety cannot be practiced into existence by those without power.

When Empowerment Becomes Exposure#

DevOps is often described as empowering teams.

That is only true when responsibility, authority, and protection move together.

DevOps becomes exploitative when:

teams are given ownership without control
autonomy is declared but budgets and priorities remain centralized
failure is tolerated rhetorically and punished practically
speed is demanded while capacity is ignored

In these environments, DevOps doesn’t reduce risk, it redistributes it. Downward.

The language stays optimistic. The experience does not.

The Guru Problem#

Management parables often rely on a figure who knows the truth, withholds it, and reveals insight only when others are deemed ready.

This character is a narrative convenience, not a leadership model.

In real organizations, clarity withheld is power exercised. Allowing people to suffer so they can “discover” the right answer is not wisdom—it is control disguised as pedagogy.

If DevOps requires an enlightened intermediary to function, the system has already failed.

Healthy systems depend on transparency, not mystique.

What Competent Management Actually Looks Like#

Competent management is rarely inspirational. It is quietly corrective.

It looks like:

canceling work that exceeds capacity
choosing fewer priorities and defending them
making tradeoffs explicit and public
taking responsibility for failures without deflection
maintaining clear boundaries between work and home

In a competently managed organization, DevOps makes life boring in the best way. Incidents are smaller. Surprises are rarer. People sleep.

If DevOps makes your organization more intense, more fragile, or more exhausting, it is likely compensating for something missing above it.

Follow the Power, Not the Practices#

Here is the test most DevOps literature avoids:

When DevOps is introduced, who loses power?

If the answer is:

teams get more metrics
developers get more on-call
operations gets more responsibility

That is not transformation.

If the answer is:

executives lose plausible deniability
managers lose the ability to overload teams
leadership must say no more often than yes

Then something real is happening.

DevOps that does not challenge power structures will eventually reinforce them.