If the term DevOps has caught your ear of late and its caused you to start researching what it is and how it can benefit you, you’ve probably come across a number of dissenting pieces on the term “DevOps culture.” A recent tweet by Lori Macvittie of F5 (@lmacvittie) reiterated my thinking, “wow, this issue has some strong opinions surround it it!”

I’d be remiss if I didn’t mention that I have on numerous occasions stated my own issues with the notion of culture being an instrumental component of DevOps adoption. Having been an executive in a few startup tech companies in my past, I remember, and still smart from, the various executive team discussions about company culture. We spent hours–wasted hours???–discussing what kind of company we will be and how to build a culture that would turn us into a market leader only to have all that work undone by underhanded backstabbing and small company politics within the executive team itself.

Hence, I’m skeptical about the ability to truly foster culture anywhere. Culture is something that takes holds as a factor of the individuals involved and how they treat each other, which is a direct result of many other corporate led initiatives, such as opportunity to be recognized for their work, stability, compensation, etc. So, if it’s that difficult to foster a culture in a small startup, what is likelihood of fostering culture in a large enterprise, where so many in IT struggle everyday with great frustrations and an inability to progress through backlogs and fragility?

There’s a great Twitter discussion that includes Damon Edwards, CEO of DTO Solutions (@damonedwards), John Willis (@botchagalupe), Matt Stratton (@mattstratton) and myself on the topic in which Damon discusses how he and John Willis came up with the CAMS acronym–Culture, Automation, Measurement & Sharing–as a means of avoiding partial solutions.

In this thread, I specify that enterprises thrive on tangible, repeatable efforts. For me, attempting to explain the benefits of DevOps to the business to an IT executive needs to be rife with tangible and measurable efforts so that the IT executive can have a high threshold of confidence that if followed will lead to the expected results. In my opinion, culture does not belong in this conversation for the sole purpose that if the culture cannot be changed, the entire effort will be suspect and, thus, most likely not attempted.

In response to one of the tweets in this thread, Damon states:

Damon has been working with many large enterprises now on delivering benefits of DevOps, so I believe this statement is reinforcement of my earlier theory that culture is a big turn off for getting IT executives to invest in adopting DevOps approaches. Organizational dynamics is something that is a bullet point within the roadmap that must be dealt with and the IT executive will recognize that no transformational efforts can ever be successful without possible need to shift people and roles.

In speaking with Edwin Miller (@edwinmiller), CEO of 9Lenses, a company that provides a platform for analyzing organizational dynamics, there was agreement that culture is important, but it is very much a leadership issue. Without strong leaders that can admit fault, don’t fear not having all the answers and can incite the passion of workers any attempt at culture is a folly. The opportunity to have real transformation in IT will start with hiring IT executives that understand the changing landscape of the digital economy and realize, just like the automotive companies did in the 80’s, that middle-tier executives may have no perspective on issues where line workers have great insight into how to change things. That is, in order for things to really change in enterprise IT, it will require leaders that recognize that the aggregate knowledge of all in IT will be required to identify problems and eliminate them.

With regard to the perspective of those in favor of DevOps culture, it seems there are various perspectives on what is meant by the word culture. This blog entry by Jeff Sussna, “Empathy: The Essence of DevOps” has become a beacon for many on how to proceed by focusing on fostering change through shared experiences. This article, “DevOps Culture,” by John Willis discusses culture from the perspective of behavior modification, where behaviors are essentially how the organization responds to a given stimulus. This latter piece really is about problems caused by the overlap of people and process, which is an interesting point given that we talk about IT being about people, process and technology as if they were independent silos when what we really are talking about is the need to fix the points where these three elements overlap.

Frankly, stepping back from the fray for a moment, I find it odd that opposition to the term DevOps culture causes such fierce debate and in some cases mob-like responses in various forums. For me, I’ve presented a logical reason why the term can be seen as negative or at a minimum offer no value to entice investment or gain traction for taking action to work on the changes that are often discussed around companies practicing DevOps. Other than “it’s critical to DevOps success” messages, I’ve seen little from those pro-culture advocates as to why we should expect businesses will change something as esoteric and intangible as culture in order to succeed in fixing what we should all view as ineffective practices. Without meaningful changes in IT management to hire leaders with the aforementioned attributes, talking about culture change is akin to changing the oil filter in your car when the spark plugs are shot.