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.

[Originally posted in on O'Reilly Radar.]

Global Retrospective: devops, the First 5 Years

Devops is officially 5 years old. In the time since the inaugural devopsdays event in Ghent in 2009, it has evolved from an idea about agile infrastructure to an emerging organizational philosophy (or practice), one that even huge, mainstream enterprises are adopting. Devops is also an open, vibrant, and diverse community of practitioners (or philosophers), who are actively debating culture, automation, measurement, and sharing both their successes and failures openly. The theme for the 5-year-anniversary devopsdays gathering in Ghent, Belgium is “the future of #devops”. This is a natural place and time to pause and reflect about how far we’ve come and where we’re going. To that end, part of this devopsdays will be devoted to a retrospective (a blameless postmortem of sorts). On the first day, October 27, Yves Hanoulle and I will have a place, where attendees can write down their observations and ideas about the past and the future of devops on post-it notes, placing them into one of 3 areas: stop, start, or continue.

  • What hasn’t worked well in the devops movement, and we should stop doing? Place in the “stop” area.
  • What could we do in the future to make devops even more successful (by some measure of success)? Add it to the “start” area.
  • What has devops gotten right, and practitioners should keep doing? Add to the “continue” area.

Can’t make it to Ghent? No worries! You can participate in the historic global devops retrospective on twitter, by using #devopsstop, #devopsstart, and #devopscontinue hashtags. Yves and I will collate and summarize all the ideas received by 17:00 (5PM) Belgium time on October 27, and will present the results at the conference and in a blog post on this site on the following day.

On the second day of the conference (October 28), there will be 3 open spaces devoted to “fleshing out” one (or more) of the ideas that we’ve all come up with during the retrospective. These ideas will likely come from the “stop” or “start” categories--we’ll have the what and the why, and the open spaces will help us brainstorm how we get there and who will be leading the way. In addition, each open space will conduct a premortem to identify potential problems with these ideas.

Finally, each of the groups will produce and share a blog post about the results of their open space, and nominate one or more people to represent the open space during the combined Retrospective Podcast with Devops Cafe, FoodFightShow, Arrested DevOps, The Ship Show.

Devops is a global phenomenon, continually shaped by its far-flung and inclusive community. We hope you take this opportunity to participate in the retrospective--in person or on twitter--and to make the next 5 years of devops even more awesome!

Update [October 27]: The raw results are here.

How devopsdays NYC built a well for a village in Cambodia. (A #devopsWater update)

Last year, the attendees of the devopsdays NYC conference used the money usually spent on t-shirts to drill a deep-bore water well for a village in Cambodia. They donated $2500 ($12/person) to Lotus Outreach, which quickly set out to find a suitable location, and a local partner organization to oversee the construction of the well. The result?

On July 5, 2014, clean, safe water started flowing from a newly-built well in the isolated Brormoay Commune in the Rike Reay Village, Veal Veng district, Pursat province, Cambodia. The well now serves 81 villagers, and even more people from the surrounding area during the dry months. The 36 village children, of whom 15 are girls, will no longer have to miss school and risk their lives to fetch water far away from their homes. The families no longer have to spend money to purchase water instead of paying their kids’ school fees.

Those of us who attend technology conferences are some of the most well-paid and financially secure people in the world. We can certainly afford to buy our own t-shits, and spare the landfills the other “swag” routinely given out for free at conferences.

So the next time you register for a tech conference, ask the organizers to donate the money they would otherwise use for t-shirts to a worthy cause. If you’re organizing a conference, give your attendees the option to donate part of their registration fee to charity. In a small way, the world will be a better place.

Here's the full report on the devopsdays NYC well.