What Can a CIO Do to Rescue a Project Afflicted with Fake DevOps?

Based on the article “Tell-Tale Signs of Fake DevOps” by Nikolay Gekht.

Let’s start with the hard truth: Fixing a broken process is far tougher than building a solid one from scratch.

Why? Because each broken process breaks in its own messy, unique way. There’s no master map, no off-the-shelf fix. What lies ahead is a steep climb, strewn with blind spots, hidden risks, and variables no one sees coming.

Still, even in the thick of it, this isn’t a walk-away moment. There are still a few levers a thoughtful CIO can pull to steady the course and steer the recovery forward.

Let’s take a look at them.

1. Theory and Principles

DevOps. Agile. Psychological safety. These terms are repeated often, but rarely fully understood. Skimming a few articles or leaning on a single expert’s opinion won’t be enough. You need to dig into the theory and grasp the principles behind DevOps.

A good place to start? The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis. Going through this book thoughtfully can help you avoid common misconceptions and costly mistakes.

2. Kaizen, Not Kaikaku

Resist the urge to solve everything at once. Radical overhauls (kaikaku) may look bold, but they backfire.

Instead, lean into kaizen – the practice of steady, purposeful improvement through small, smart changes made daily. Follow the Toyota Improvement Kata:

• Set a direction

• Make a hypothesis

• Run an experiment

• Learn and adjust

Small, well-placed changes today will bring safer, more sustainable results than a sweeping transformation somewhere down the line.

3. The Social Part 

Broken DevOps isn’t just a technical or procedural issue. More often than not, it’s tangled up in unspoken assumptions, stale habits, interpersonal dynamics, and organizational inertia.

No process will stick if it ignores these social factors. Don’t brush them aside because they often run deeper than the cracks in the process itself.

Final Word

In the end, recovery isn't just about tools, pipelines, or practices. It’s about clarity of purpose. If you're leading the charge, start by asking the right questions:

• Why do I need DevOps?

• Why does it work?

• Why is it the right tool for this context?

• Why does it matter to the company?

• Why should people care enough to adopt it?

Answer those questions, and you’ll lay the groundwork to pull the project out of the mess and into a shape that’s ready to move forward.

You can find the original article, “Tell-Tale Signs of Fake DevOps” by Nikolay Gekht, in the Agile Bulletin 2023.