This article draws on ideas originally published at devops.com and concepts from The DevOps Handbook.
The Most Common Misconception About DevOps
Ask ten engineers what DevOps means and you will get ten different answers. What DevOps is, what it does, and how an organisation adopts it are largely contextual — but certain foundational elements are nearly universal. Automation is the most prominent of these. And precisely because automation is so central, many practitioners make the mistake of treating it as synonymous with DevOps itself.
It is not. Automation is not DevOps, and DevOps is not automation.
What The DevOps Handbook Says
The preface of The DevOps Handbook explicitly lists the idea that DevOps is simply “infrastructure as code” or automation as one of the prevailing myths about the practice. The authors clarify:
While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.
Technology executive Christopher Little put it even more succinctly, as quoted in the same book:
DevOps isn’t about automation, just as astronomy isn’t about telescopes.
Christopher Little
The telescope analogy is sharp. A telescope is the most powerful tool an astronomer has, and serious astronomy without one is nearly unthinkable — but the telescope does not define the discipline. Astronomy is defined by its questions, methods, theories, and community of practice. The telescope is what makes the work tractable at scale.
A Golf Analogy: Automation as the Putter
Consider golf. Different players take to the course for different reasons — competition, exercise, or simply enjoying the outdoors. But the fundamentals of the game are the same regardless of motivation. A wide variety of clubs and strategies exist to move the ball from tee to green, and once you reach the green, the putter becomes essentially indispensable. You could technically tap the ball in with another club, but every golfer agrees the putter is the right tool for that job.
And yet: the putter is not golf, and golf is not the putter.
Automation occupies exactly the same position within DevOps. It is the tool you reach for at a critical stage because nothing else does the job as well. But it does not constitute the whole game.
The Three Pillars Automation Cannot Replace
Effective DevOps rests on at least three pillars that automation alone cannot provide:
- Culture and shared ownership. Automation can enforce a workflow, but it cannot create the mutual accountability between development and operations teams that makes DevOps work. That requires deliberate organisational change — breaking down silos, aligning incentives, and building psychological safety.
- Architecture. A tightly coupled monolithic system can be automated, but the automation will still be slow, fragile, and hard to test. DevOps outcomes depend on architectural decisions — modularity, loose coupling, independently deployable services — that no automation script can retrofit on its own.
- Continuous learning and feedback. Blameless post-mortems, regular retrospectives, and cross-functional knowledge sharing are practices that humans must own. Automation can surface data and alert on anomalies, but the culture of acting on that information belongs to people.
Does More Automation Make People Redundant?
A related concern is whether increasing automation — especially infrastructure-as-code and self-healing systems — will eventually eliminate the need for operations engineers. The evidence so far suggests the opposite. As more routine, repeatable tasks are automated, engineers are freed to tackle higher-order problems: system reliability at scale, security architecture, capacity planning, and the design of the automation itself.
Automation’s role in DevOps is better understood as an enabler than a replacement. It shifts human attention from maintenance toward innovation. The operations function does not disappear; it evolves.
Automation Is Still Essential — Just Not Sufficient
None of this is an argument against automation. Quite the opposite. Attempting DevOps without automation is technically possible in the same way playing golf without a putter is technically possible — but it is inefficient, error-prone, and counterproductive. The goal of automating everything that can be automated is sound precisely because it reclaims human attention for the things that cannot be.
The key distinction is this: automation is a means, not an end. It is one element — a critical one — within a broader cultural and technical transformation. Treating it as the whole of DevOps leads teams to invest heavily in tooling while neglecting the organisational change, architectural work, and feedback loops that determine whether those tools actually deliver value.
Key Takeaways
- DevOps is a set of cultural norms, architectural patterns, and practices — not a toolchain.
- Automation is indispensable within DevOps but does not define it.
- Culture, shared ownership, and architecture are prerequisites that automation cannot substitute.
- Increased automation shifts human effort toward higher-value work; it does not eliminate the need for people.
- The most effective DevOps implementations automate aggressively and invest equally in the human and organisational side of the transformation.