Design thinking expresses traditional design principles in a form that can be used for non-traditional activities. According to Herbert Simon’s definition of design as “changing current situations into preferred ones”, nearly anything can be designed, including DevOps. One could view DevOps as a thing, and argue about the definition of that thing. Alternatively, one could view it as an unfolding discourse, which can continually change from its current situation into a preferred one.
Empathy is central to design thinking. In practical terms, empathy means testing your assumptions against users’ perspectives. Design thinking projects often start by looking for a new solution, only to discover the need to reframe the problem itself. I believe this approach can help us navigate the current debate regarding the nature of DevOps and the relevancy of Enterprise DevOps.
Some of us dismiss Enterprise DevOps as, at best misguided, and at worst “snake oil”. Perhaps, though, we might be better served by listening to it for possible glints of wisdom. Could there be any truth to the claim that DevOps is “handwavy” when it comes to talking about culture? Might IT organizations gain genuine benefit from efforts to explain more concretely how to address the C in CAMS? Does denigrating people with the “snake oil” moniker miss the fact that salesmen go where the money is, and that money points to a perceived need? If we believe that Enterprise DevOps is “wrong”, might addressing the underlying real need be the best way to “discredit” it?
Conversely, those of us who dismiss “pure DevOps” as a fantasy for startup unicorns might benefit from testing our own assumptions that underlie that opinion. Ironically, DevOps came into being to solve a legacy problem, not to present a golden utopia to the masses. Just because we can’t get a handle on what feels like hand-waving doesn’t necessarily mean it’s empty of content or value.
That being said, if we think the “pure DevOps” discourse around culture is a call for “cultural revolution”, maybe that’s exactly what enterprises need. They are besieged by demands to change their notion of themselves and how they relate to their customers. Is it strange to think they’d need equally profound transformations within IT? If we try to translate the strange and foreign into something more accessible, are we really addressing the right problem?
Finally, if we want to present Enterprise DevOps as something “different”, we need to do more than just elaborate its ostensibly unique challenges. “Enterprises are different” is a question, not an answer. Assuming it’s the right question, we then need to answer it by describing what Enterprise DevOps practices actually look like, and explaining their unique applicability to large organizations. It doesn’t help if we’re as equally handwavy as the “other side”.
Im my humble opinion, DevOps is good, and we all deserve good DevOps. The best DevOps is that which concretely, empathically addresses its customers’ needs. Time will tell whether that results in a single set of practices you can buy from a certification body, or in infinitely many, where every shop does it a little differently, or something in between. I believe that empathy is the essence of DevOps, just as it is the essence of Design Thinking. As such it needs to characterize, not just specific practices in specific IT organizations, but also the ongoing design of DevOps itself.
The Tibetan Buddhist teacher Dzigar Kongtrul recently tweeted, “When we are hit with suffering we generally focus on the outer causes instead of looking at the inner causes of our suffering.” This comment seems like wise advice for us all. The more willing we are to expose ourselves to feedback, however it comes, and however confusing or distasteful it may seem, the better chance we’ll have of changing current situations into ones that really are preferred.