DevOps keeps it cool with ICE

How inclusivity, complexity, and empathy are shaping DevOps.


Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.


There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target,, US DHS, and many others.

The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.

The inclusivity of the DevOps community extends beyond embracing different job roles or industries, as evidenced by the recent open conversations about gender diversity. The organizers of devopsdays events are actively reaching out to currently underrepresented populations (e.g., students, women, people of different ethnic backgrounds, LGBTQ+, folks outside IT). It’s a virtuous cycle: the more diverse points of view that DevOps includes, the richer and more widely applicable it becomes. Inclusivity is clearly the path for DevOps to meaningfully expand beyond just dev and ops to impact all parts of the organization (for instance, security), for all organizations.

Complex systems

More than ever, software is eating the world, and many companies are now building and operating systems of unprecedented scale. Systems of such complexity cannot be managed manually, which has lead to a wider adoption of modern configuration management and monitoring tools. This is the reason that automation and measurement have emerged as two of the key themes in DevOps, the “A” and “M” in CAMS. (It might also be the case that early DevOps practitioners naturally placed more emphasis on the technical aspects of DevOps, as opposed to the “softer” Culture and Sharing elements).

More fundamentally, the very reason that DevOps came into existence is because we are now working with (and in) complex, adaptive systems, which cannot be reasoned about in simplistic, linearly causal ways. In fact, they are often beyond human ability to comprehend — how complex systems function (and break) cannot be predicted based on past experience. Complex systems are constantly changing, and working with complex systems requires constant experimentation and continuous learning.

This is why DevOps places such a heavy emphasis on culture: without the ability to iterate on our organizations (e.g., by increasing communication between typically siloed groups), we lose our ability to successfully operate and evolve our products. Without the ability to learn from both our failures and successes (e.g., via blameless postmortems), we cannot improve the resilience of our complex systems.


Empathy can seem out of place in a discussion about technology and organizations. However, empathy is not only about feeling what others are feeling; it is not just commiserating or sympathizing. Empathy is a two-way conversation, a way to resolve conflict and to meet people’s needs. Without an empathetic conversation, we cannot understand the needs of all the participants in our complex systems (e.g., devs, ops, finance, customers), and therefore we cannot possibly improve our systems.

We can certainly try to brute-force our way to DevOps — for instance, we can ban silos, mandate hourly deploys, and insist on automation and monitoring of “all the things.” However, if there is anything to gain from this approach, it will be short-lived. We cannot expect a wider adoption of DevOps without first understanding why the (often painful) status quo makes sense to people, and why DevOps might not initially make sense for them.


Empathy is at the core of many design- and user-focused disciplines and approaches (e.g., Design Thinking, User Experience and User-Centered Design, Service Design, Human Factors, Impact Mapping, etc.). It’s not surprising that empathy has been called the essence of DevOps, as it’s required for the other two emerging themes of inclusivity and complex systems. Only with empathy can we expand and build a more inclusive DevOps community. Only by having open conversations — by understanding each other’s needs — can the siloed teams resolve their conflicts and begin to work together. Empathy is also the first step in moving away from a blame-oriented, command-and-control company culture towards the blame-free, resilient learning organizations that are best suited to work with complex systems.

More fundamentally, only with empathy can we build and operate products that people need and companies where people want to work. And those are worthwhile goals for the next five years of DevOps.


I’d like to thank Patrick Debois, Bob Marshall, Bridget Kromhout, David Mortman, Dave Mangot, Yves Hanoulle, James Turnbull, Katherine Daniels, and Will Maier for their contributions to this article in particular, and to DevOps in general.

Shameless plug

I teach a one-day (blameless) postmortems workshops, rooted in complex systems theory and human factors. The next one is in NYC on February 12. I hope to see you there.

Editor’s note: This is part of our ongoing exploration of the meaning of DevOps and how community plays a crucial role in its definition.

If you’re interested in learning more about blameless postmortems, you’ll want to check out Being Blameless by Dave Zwieback.

Cropped ice image CC BY 2.0 madmack66

tags: , , , , , , , , , , , , , ,

Get the O’Reilly Web Ops and Performance Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Michael Sage

    Well said! Openness, sharing, and leaning past the fear of learning new things or letting others review our work are hugely important to succeeding in DevOps.