DOP 340: Why Operations Teams Resist Every Technology Wave

Episode 340

Show Notes

#340: The smartest ops people are often the most likely to resist new technology – and they’re not wrong. If you don’t change anything, nothing breaks, and nobody blames you. That’s a completely rational choice. It’s also the one that guarantees you fall behind. Bare metal to VMs, VMs to cloud, cloud to Kubernetes – every time, the teams that played it safe ended up scrambling to catch up two years later. The safe bet isn’t safe. It just feels that way.

It gets worse when you look at where the tools come from. Kubernetes? Built by developers. Terraform? Developers. Containers? Developers. The tools ops teams depend on were made by a different tribe. So the pushback isn’t really about whether the tech is ready or whether the risk is too high. It’s about identity. ‘Not my people’ is a harder objection to overcome than ’not ready yet,’ because no amount of documentation or proof-of-concepts answers it.

And about proof – everyone wants it before they’ll move. But the proof already exists. It’s the tool someone on your team has been running in shadow IT for a year without any official support. If it survived that long on its own, that’s stronger evidence than any pilot program. That’s your roadmap. And the way in is small chunks, not grand plans. Move one service. Learn something. Adjust. Repeat.

AI in ops follows the exact same pattern. A tool that gets you 50% of the way there for free means you can focus your expertise on the other 50%. That’s a win. But the people waiting for AI to be perfect before they’ll touch it? They’re making the same mistake as the teams that waited for perfect proof before migrating to the cloud. Different decade, same trap.

Frequently Asked Questions

Why do operations teams resist new technology?

Viktor Farcic’s explanation on DevOps Paradox episode 340 turns on whose people built the tool. Application developers readily adopt libraries written by other application developers, but the tooling handed to operations, Kubernetes included, was written by developers rather than by operators. He adds an incentive problem: refusing a change means nobody can ever prove it would have helped, so saying no carries no measurable blame.

Are operations teams more resistant to change than other teams?

Viktor Farcic pushes back on that premise in DevOps Paradox episode 340. Every group has its own reason for saying no, and each treats its own reason as valid while dismissing everyone else’s. Operations cite production, security cite risk, testers cite the human touch. He says the same applies to blame: it feels asymmetric from inside a team, but corporations distribute it fairly evenly.

How should a company approach a large technology migration?

Viktor Farcic’s answer on DevOps Paradox episode 340 is small chunks paired with a vision that can change. Grandiose plans get made because they sound better to shareholders than describing the single thing you intend to do this week. He insists on both halves: chunks without a vision are random, and a vision that never changes proves nobody applied what the chunks taught them.

What should companies do about shadow IT?

Viktor Farcic proposes a rule on DevOps Paradox episode 340: adopt any shadow practice still running a year later. Persistence is the evidence, because the ones that were not worth it quietly disappear, so a surviving shadow tool is a roadmap item that already validated itself. He describes the practice as an illegal center of excellence. Darin Pope calls it appealing and chaotic in equal measure.

Where does AI genuinely help operations work today?

Viktor Farcic’s rule on DevOps Paradox episode 340 is that AI shines where a large volume of data sits in one place, or very few places, and somebody has to make sense of it. Darin Pope’s example is log summarization, and he adds generating a Bash script that includes the input validation he would otherwise skip. Cases spanning many scattered sources get harder.

Could AI replace an operations engineer?

Viktor Farcic says on DevOps Paradox episode 340 that nothing is close to that today. His framing is that AI enhances him rather than substituting for him: output that is only half right still helps, so long as reviewing and correcting it takes less time than doing the work himself. What he wants is the ratio shifting toward thinking and away from correcting.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 340, “Why Operations Teams Resist Every Technology Wave,” works through why operations teams reject tools their developers are keen on, how blame is actually distributed, and what shadow IT reveals about a roadmap. Every episode page carries the audio, the video, and a full transcript.

Episode Transcript

Read the Full Transcript

Topics

Share and Download

Hosts

Darin Pope

Darin Pope

Viktor Farcic

Viktor Farcic

Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences.

He has published DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog The DevOps Toolkit.