The Illusion of Control
Comfort comes when we feel in control.
Sometimes that comfort is a fantasy, and in the current world of AI (and war) I guess all of us need that feeling from time to time.
Yet when that goes too far it goes too far indeed. That’s because no matter how much we design a process failure will politely excuse itself from that process. Each and every time.
Defend Success from Failure
We add checks.
We add approvals.
We add pipelines, gates, dashboards, and acronyms until the whole thing looks impressive enough to reassure senior management and frighten junior engineers.
There is one truism though. Software ships because someone decides to ship it.
Not because the process is complete.
Not because the checklist is satisfied.
But because the business needs it live, the deadline is now, and reality has arrived.
The Rise and Rise of the Comfort Blanket
DevOps, in theory, is about enabling delivery.
In practice, it often mutates into something else entirely. Risk management theatre.
Over time everything becomes defensive:
“We need one more approval”
“The pipeline hasn’t finished”
“We should align on this in a meeting”
“Let’s not touch it until Monday”
None of these statements are wrong in isolation.
Collectively, they form a system optimized not for delivery, but for avoiding blame.
And blame avoidance is a powerful motivator, as we all know in the industry.
Git blame is called blame for good reason, don’t you think?
Developers Don’t Live in Theory
Developers, on the other hand, live in a far from forgiving world.
The feature is late
The bug is visible
The customer is angry
The PM is asking questions that start with “just”
At some point, the question stops being “is this perfectly safe?”
and becomes “is this safe enough?”
That decision is rarely made in a meeting.
It’s made quietly, by the person closest to the code, who understands the trade-offs and knows exactly what will break if they’re wrong.
This isn’t recklessness.
It’s accountability.
Safety Is Not the Same as Inaction
There’s a dangerous assumption baked into many delivery processes:
that slowing things down automatically makes them safer.
It doesn’t.
What it often does is:
hide risk rather than reduce it
push responsibility downward
delay feedback until it’s more expensive
A release delayed by three days doesn’t become safer.
It just becomes later.
And when it finally goes out, the same risks still exist — except now they’re wrapped in ceremony.
The Real Tension No One Talks About
The unspoken conflict isn’t DevOps vs developers.
It’s process vs judgment.
Processes don’t take responsibility.
People do.
Processes don’t get paged at 3am.
People do.
Processes don’t explain outages to customers.
People do.
So when delivery finally happens, it’s rarely because the system allowed it.
It’s because someone decided the system had done enough.
What Actually Works
The healthiest teams I’ve worked in didn’t remove process.
They removed the illusion that process replaces trust.
They understood:
guardrails are there to help, not to freeze movement
engineers are paid to make decisions, not defer them
risk is managed by feedback, not by delay
Which is a world away from the unhealthiest teams I’ve worked in.
Conclusion
Most importantly, the best developers I’ve seen have all accepted a hard truth
Software delivery is not made safe by perfection.
It’s made safe by ownership.
Let that sink in for a moment.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com
The Secret Developer has broken production systems before. Shockingly, none of them were fixed by adding another approval step.