This article is based on a post originally published on dev.to and republished here with editorial enhancements for a DevOps engineering audience.
A few years ago, if you had asked many practitioners to define DevOps, the answer would have sounded something like: “Automation, infrastructure-as-code, automation, pipelines, more automation.” That answer is understandable — most early DevOps content focused almost exclusively on tooling — but it is also dangerously incomplete.
Automation is part of a DevOps practice, but it is arguably only 5–10% of what makes DevOps work. The reason so much writing has concentrated on automation is simple: tools are easy to write about. Relative to the harder cultural and organisational changes that DevOps demands, automation is the straightforward part.
What DevOps Actually Represents
Gartner’s widely cited definition provides a useful baseline:
DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.
Notice the order: culture comes first, collaboration comes second, and automation is mentioned last. The main components of DevOps are people and process. Automation is a force-multiplier — a lever — but without the right people and processes behind it, that lever accomplishes little of lasting value. At worst, automation without process simply lets teams make mistakes faster and at greater scale.
People: The Cultural Foundation of DevOps
At the heart of a successful DevOps practice is a culture that accepts failure, avoids blame, and demands collaboration and knowledge sharing. Each of these properties is load-bearing.
Accepting Failure Prevents Mediocrity
If team members fear how their manager reacts when they make a mistake, they will not attempt new approaches. The team stagnates while competitors who have embraced failure as a learning opportunity move forward.
Accepting failure does not mean lowering expectations or tolerating poor work. It means creating conditions where people surface problems quickly rather than hiding them. The expectation should be explicit:
“Mistakes happen. Don’t hide your errors. Communicate what happened, work on fixing it, and above all — learn from it.”
That posture directly reduces the destructive impulse to assign blame. Time spent deflecting responsibility is time not spent fixing the problem, and it poisons team trust in the process.
Removing Roadblocks to Collaboration
If your goal with DevOps is faster, higher-quality delivery, roadblocks must be aggressively removed. Fear, political gamesmanship, and mistrust between developers, operations, and the business are not minor inconveniences — they are blockers that need to be eliminated.
As a manager, tolerating finger-pointing within your team is a failure of leadership. DevOps culture requires that co-workers trust they will not be thrown under the bus for raising problems honestly.
Knowledge Sharing Is Non-Negotiable
If only one person knows how a critical system works, that person is a single point of failure for the entire delivery pipeline. There is no such thing as being “too busy to document” or “too busy to train a colleague.”
Knowledge hoarding — whether deliberate or through neglect — must be treated as a serious team-health issue, not a personal quirk. Normalise documentation, pair work, and cross-training as standard expectations, not optional extras.
Process: Where DevOps Actually Begins
You can have excellent automation and a strong culture and still not be practising DevOps if the underlying processes are missing or broken. Process is where meaningful DevOps transformation starts, and it delivers a higher return on investment than any tooling investment that follows.
Without defined processes, there is too much chaos to maintain a healthy culture, and any automation you build is likely solving the wrong problems.
Make Work Visible
The first step is giving the entire team visibility into the work backlog — not just managers. When everyone can see what is in flight, two expensive failure modes disappear:
- Duplication of effort: “I already have a script that does that.”
- Unintended side-effects: “Doing X while Y is in progress will cause Z to fail.”
Kanban boards, sprint backlogs, or any similar tracking mechanism only work if the team actually uses and maintains them. A board that goes stale within two weeks is a symptom of a process problem, not a tooling problem.
Require Accountability in Stand-ups
Daily stand-ups serve one primary purpose: shared situational awareness. Vague updates like “I’m working on server things” provide no value. The expected answer is specific: “Today I’m doing X, Y, and Z.”
This transparency is not about micromanagement. Every unknown status compounds delays, reduces quality, and erodes trust. The team needs to know what is happening — or not happening — so everyone can plan accordingly.
Agile Work Management Is a Prerequisite
If your team is not managing work in an Agile way — using Scrum, Kanban, or something comparable — the conditions for DevOps do not yet exist. Ad-hoc, undocumented work execution is incompatible with the feedback loops and continuous improvement that DevOps depends on.
Commitment to process requires continual reinforcement from both peers and management. “We set up a Kanban board and nobody used it, so we stopped” is not an acceptable outcome. Failure to update the board is itself a process failure that must be addressed — not a reason to abandon the process.
Where Automation Actually Fits
Once people and process are in place, automation becomes genuinely powerful. Continuous integration pipelines, infrastructure-as-code, automated testing, and deployment automation all amplify the output of a high-functioning team. Without that foundation, the same tools amplify dysfunction instead.
Think of automation as a socket wrench. In the hands of a skilled mechanic following a clear process, it speeds up the work enormously. Rusted and handed to someone with no process and no training, it is just a blunt instrument.
Further Reading
If you want to go deeper on the non-automation aspects of DevOps, two frequently recommended starting points are The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, and Effective DevOps by Jennifer Davis and Ryn Daniels. The critical reviews of Effective DevOps are instructive in themselves: the most common complaint is that the author did not talk enough about automation tools — which suggests she got the balance exactly right.
Original source: dev.to. Republished and expanded for a DevOps engineering audience.