Why tools alone don't make DevOps

I've seen companies "do DevOps" by buying tools. Kubernetes, a CI/CD platform, an observability suite, maybe a new team called "DevOps". A year later, releases are still slow and painful, developers still throw code over the wall, and the new DevOps team is just the old ops team with a new name and a longer ticket queue.

The tools aren't the problem. They're just not the point.

What DevOps was supposed to fix

The word "DevOps" was coined around 2009, when Patrick Debois organised the first DevOpsDays in Belgium. The problem it addressed was a human one: developers wanted to ship changes quickly, operations wanted stability. They had different goals, different managers and different incentives. So they fought, and software delivery was slow and fragile.

DevOps proposed bringing them together: shared goals, shared responsibility, shared tools, and a lot of automation so that speed and stability stop being opposites.

Notice the order. People and goals first, tools to support them.

The CALMS framework

A useful way to think about DevOps is CALMS, a framework popularised by Jez Humble and others:

• Culture: shared responsibility, collaboration, learning from failure.
• Automation: removing manual, error-prone work from building, testing, deploying and operating.
• Lean: small batches, limiting work in progress, removing waste and waiting.
• Measurement: data about delivery and reliability (like the DORA metrics), used to improve, not to punish.
• Sharing: knowledge, tools, responsibility and success across teams.

Tools mostly cover the A and part of the M. The C, L, and S depend on how people work together.

Tools make good collaboration faster. They also make bad collaboration faster.

Signs of "DevOps in name only"

• A DevOps team that receives tickets from developers and does all the deployment and infrastructure work for them. That's a new silo, not DevOps.
• Developers never see production: no access to logs, metrics or alerts for their own services.
• Blame after incidents: someone gets told off, nobody looks at the system.
• Big, infrequent releases despite having a CI/CD tool.
• Approval boards for every change, meeting once a week.
• Tools chosen by one team and forced on others without asking what they need.

Breaking silos

What actually helps:

• Shared goals. Developers and operations measured on the same outcomes: delivery speed and reliability, not one each.
• "You build it, you run it", with support. Teams own their services in production, including on call, with platform teams making that manageable.
• Platform teams that serve, building self-service tools that let developers move independently, instead of doing work for them.
• Embedding: an SRE or platform engineer working within a product team for a while, sharing knowledge both ways.
• Shared rituals: joint postmortems, shared dashboards, demos across teams.

Feeling safe to speak up

Google's research on team effectiveness, known as Project Aristotle, found that the most important factor in high-performing teams was psychological safety: the belief that you won't be punished for speaking up, asking questions, or admitting mistakes.

The DORA research says something similar: a generative culture, where information flows freely and failure leads to inquiry rather than blame, predicts better software delivery and better well-being.

In practice, psychological safety in DevOps looks like:

• Blameless postmortems where the question is "how did the system allow this?", not "who did this?"
• People saying "I don't know" or "I broke it" without fear.
• Juniors comfortable asking questions in public channels.
• Leaders admitting their own mistakes first.

Without it, problems get hidden, and hidden problems become outages.

Leading the change

If you want to move your organisation towards real DevOps:

1. Start with a pain point everyone feels: slow releases, painful deployments, frequent incidents.
2. Pick one team willing to try a different way. Show results.
3. Measure before and after (DORA metrics are great for this).
4. Invest in automation that removes the most painful manual work.
5. Change incentives: what gets rewarded and measured shapes behaviour more than any tool.
6. Get leadership support. Culture changes from the top as much as from the bottom.
7. Be patient. Culture change takes years, not sprints.

So, are tools useless?

Not at all. Good tools make good practices possible and scalable. But they come after the decision to work together differently, not instead of it.

My take: DevOps is something you practise, not something you buy. The tools are the easy part. The people are the point.

— Desly