Why DevOps really is about culture
Why is talking about “culture” helpful in effecting a transformation such as DevOps? Jeff Sussna explores this often murky area to help define and explain the role of culture in DevOps today.
Emerging methodologies such as Agile, DevOps, cloud, and microservices both reflect and contribute to IT’s growing complexity. It’s no longer possible (assuming it ever was) to fully specify how things work or what people should do. To align IT with 21st-century business imperatives for quickness, innovation, and adaptability, we need to empower and rely on people’s ability to make decisions that are compatible with those needs.
How do we do that? According to DevOps, the answer is “culture”. But what does that word mean? It’s become a bit of a flashpoint within the DevOps discourse. Many critics object that the term “culture” isn’t meaningful, or that we don’t properly understand what it does mean, or that it’s not actionable, or that it isn’t even relevant, and instead we should focus on “concrete behavior”.
Even anthropologists, for whom culture is at the core of their work, don’t entirely agree on its meaning. For the purposes of this discussion, I will lift a definition offered by Clifford Geertz. According to Geertz, “…man is an animal suspended in webs of significance he himself has spun. I take culture to be those webs…” (masculine gender left as is in the original). In other words, culture defines, and is defined by, what we think things mean.
Meaning doesn’t just name things. It also constrains and guides what we think we can do with and about things. Put another way, meaning affords action. Changing the name of a meeting from “postmortem” to “learning review”, for example, changes your belief about what to expect will happen in the meeting, and what you think will be acceptable to say or do in it.
Culture generates implicit webs of meaning. We reinforce those webs through our actions over time. When we confront repeated similar system failures, for example, do we take their meaning to be that we need to document a standard recovery procedure? Or do they mean we need to investigate the root cause so we can banish the failures from happening again? We pick a path based on the culture surrounding us. Conversely, the path we pick reinforces that culture for ourselves and the rest of our organization.
DevOps as culture is about shifting the web of meanings we use to guide our work in IT. It challenges us, for example, to change our beliefs about the meaning of such things as “snowflake servers”. Instead of viewing them as affording opportunities for careful documentation and tending, DevOps points us instead down an alternative path, wherein we view snowflake servers as affording opportunities to replace them with standardized templates.
“We reinforce culture through
our tools and how we use them”
The question still remains, though, as to why talking about “culture” is helpful in effecting a transformation such as DevOps. In order to change organizational behavior, we need the ability to see what that behavior is, and how we reinforce it. Making the “web of significance” explicit gives us a handle to start bending it in new directions. It allows us to start asking, “why am I about to do what I am?”, and “what might be the implications if I did this other thing instead?”
The tools/culture dichotomy that haunts DevOps is thus a false one. We reinforce culture through our tools and how we use them. At the same time, our culture constrains which tools we use, and what we think they afford. In order to transform IT, we have to confront both simultaneously. We have to build “asking why” and “asking what if” into our daily work. Unless we do so, we are likely doomed to transformation implementations that are ineffectual, cargo-cult, apparent failures.
You can read the original article and many more on Jeff Sussna’s blog at Ingineering.IT.