I’ve been watching a pattern repeat itself for years, and it’s starting to grate. Someone at a conference hears about a new tool — some Kubernetes operator, or service mesh, or GitOps platform that’s supposedly going to fix everything — and they come back convinced their team needs it yesterday.

Not because there’s a problem that needs solving. Because the tool exists.

This isn’t about being anti-technology. I love good tools. But somewhere along the line, DevOps culture got it backwards. We’re picking solutions first and frantically searching for problems they might address, instead of looking at what’s actually broken and finding the simplest thing that fixes it.

The tool-driven trap

Here’s how it usually goes. A developer hears about something shiny at a conference or reads a blog post with a headline like “How we cut deployment time by 90%.” They get excited. They demo it to the team. Soon there’s a proposal on the table, stakeholders are onboard, and the team is six weeks into setting up infrastructure for a problem that might not even exist.

Meanwhile, the actual issue — maybe it’s flaky deployments, or tests that take too long to run, or documentation nobody reads — is still there. Untouched. Because everyone’s busy making the new thing work instead of fixing what’s actually broken.

The worst part is how convincing this feels in the moment. You’ve got a demo that works. The slides look good. Everyone’s enthusiastic. It’s easy to mistake activity for progress.

What actually gets fixed

I’ve seen teams spend months building elaborate CI/CD pipelines with seven different tools, only to realise the deployment process itself was never the problem — it was that nobody had permission to restart the production service, so deployments hung for hours waiting for manual intervention.

One tool would have solved that. Instead they built a cathedral.

This happens because we confuse complexity with sophistication. A system with ten tools looks more impressive than a system with one. It feels like more work has been done, even when the simpler approach would have been faster, cheaper, and easier to maintain.

The teams I’ve seen actually improve their delivery speed didn’t start by buying into a framework. They started by asking what was slow, measuring it honestly, and then making the smallest change that would move the needle. Sometimes that was a new tool. Sometimes it was just getting someone to approve pull requests faster.

How to resist the pull

I’m not suggesting you never adopt new technology. That’s not practical, and it’s not useful advice. But before you commit to something new, try these questions:

What problem are we solving? If you can’t answer this in one sentence, you’re not ready to pick a tool.

What happens if we do nothing? Not “what’s the worst case” — what actually degrades if you wait three months? Often the answer is “not much,” and that’s valuable information.

What are we replacing? Every new tool is also a thing you now have to maintain, learn, debug, and justify. If it’s not replacing something worse, why add it?

Who on the team will actually use this? If the answer is “the senior engineer who found it,” that’s a red flag. Tools spread through teams, not downloads.

The simple truth

The best DevOps practice isn’t a tool. It’s the habit of looking at what’s actually happening before deciding what to change. Measure the deployment time. Talk to the people who do the work. Find the bottleneck. Fix that.

If a tool helps, great. But let it be the answer to a question you’ve already asked, not the question itself.