The DevOps Joint

There have been many references to the concept of Empathy as a core DevOps mind-set lately. A few years ago, Jeff Sussna at Ingineering.IT wrote a blog post about Empathy as the Essence of DevOps.

I was in attendance at DevOpsDays in Toronto this year and the resonance of Empathy as a guiding principal for DevOps practitioners was unmistakable. There was a clear passion expressed repeatedly, by both the attendees and the hosts of the event, to constantly be aware of and to proliferate this idea. Even the DevOpsDays Code of Conduct expresses the same type of sentiment without calling it out explicitly:

I understand that people are different and I attempt to be forgiving of others actions at the level of their sincere intent..

The support for this idea is also plainly seen on the many #devopsdays Twitter posts that followed the event:

DevOps stresses an increased sensitivity to psychology and social interactions than does Software Development or Operations/Systems Administration on their own. There is (or should be) a greater awareness around listening more than speaking. There is a greater emphasis around trying to understand motivations versus simply taking inventory of problems. Instead of asking “what?”, it may be more important to ask “why?”. Whole classes of problems and solutions, and the efforts exerted to create them, could be avoided by simply paying attention to motivation.  There is also a greater emphasis on increasing the quality and productivity of all forms of communication. 

When asking questions (which should be often), a DevOps engineer or practitioner should be focusing on whether the problem is an actual problem, or a perceived problem. For example, trying to address a potential security problem – is it actually a security problem that has been raised by the security team, or are you acting on unconfirmed assumptions? Is the security team even aware of this particular problem in this context?

DevOps is also about being apathetic to words like “impossible” or “unsupported”. Problems are finite. Every problem has a solution – it simply may not have been discovered yet. A DevOps mind-set is never “we can’t do it”. More often, it should be “we can do it, if x”. Solutions should always be in sight – it’s just a matter of distance. 

This is the benefit (and sometimes the burden) of DevOps Engineers having experience on both sides of the Development and Operations fence. It is important to understand Operations concepts such as networking infrastructures and topologies, exponential back-off, database administration and migration procedures. It is also important to have a strong understanding of Development concepts, such as object-oriented design, functional programming, reusable code, IDEs, code formatting/syntax checking tools and guidelines, distributed application development, and so on. DevOps Engineers need the ability to see the full scope and depth of a solution and the consequences of an implementation, because they are the bridge of communication between teams.

So why are many DevOps Engineers and practitioners so keen to identify DevOps with Empathy? Could it be that DevOps professionals and practitioners are simply an extra sensitive bunch? No, that’s not it. Is it a conscious decision, a choice to act in and support the best interests of all parties, every day? Absolutely. Seasoned DevOps practitioners have been on both sides of the Dev/Ops fence. They understand the pains of dealing with Operations, Infrastructure, 10pm Friday night fire-fighting, and related obstacles from the perspective of a Systems Administrator. They also understand the pains of dealing with Software Development Life-Cycles, roll-out schedules, hot-fixes, testing processes, Product Managers, and other challenges from a Development perspective.

DevOps is not simply about automation, build-pipelines, or CI/CD. It is not only about processes and documentation, or release cycles and the cadence of deployments to production environments. It is however, about improving productivity and harmony within a team or organization. It’s about attention to detail. It’s about culture. It’s about removing obstacles so that Development and Operations, among other teams, can work together more reliably and more enjoyably. It’s about removing barriers to innovation, promoting experimentation and encouraging curiosity. Most importantly, DevOps is about bridging gaps – and bringing people and technology together. 

So there you have it. The reason why DevOps and Empathy go hand-in-hand is because those who are truly interested in DevOps have been on the emotional thrill-ride in both camps. Those who haven’t had the direct experience may still have the mindset to immediately recognise the harmony that can be achieved, along with the potential chaos that could be avoided, by being intentional about actions, thinking and work that is delivered and communicated between teams and across an organisation every day.

If you’ve ever wondered whether or not you are a DevOps Engineer, or are curious about the field or the practice – ask yourself how often you think about the problems, solutions, and contexts described above. If you are not simply interested in deliverables, but are also interested in actively making the lives of the people you interact with easier or more enjoyable; If you care deeply about your work, and the impact it has on your fellow team-mates or colleagues throughout your organization; then DevOps, either as a career or as a culture-shift for your organization, may be just what you are looking for.

This article has also been published to LinkedIn.