DevOps culture needs to be created

No readers like this yet.
User experience vs. design

Is DevOps fundamentally about changing culture in an IT organization?

That seemingly simple question is sometimes a topic of heated debate, even though, if one digs into the details, it’s more a debate about how to think about transformation rather than a debate about the end state.

Back up a minute—you can think about DevOps as living somewhere between two poles.

At one pole lies all the various “devops-y” tooling: Jenkins, Chef, Puppet, Ansible, Salt, New Relic, and so forth. These tools cover a lot of ground, from continuous build to configuration management to application performance management (and this is just an off-the-cuff sampling). They appeal to different constituencies, and we could have long discussions about how well or how poorly individual tools align with DevOps philosophies like continuous improvement. In any case, if you’re sitting at this pole, you think that DevOps is about buying the right software (or at least you want your customers to believe that).

At the other extreme, DevOps is all about radical cultural transformation. For example, Parker Yates argues in this piece that "DevOps has too many cultural implications to convert believers over a long period of time; DevOps requires reorganization, not a subtle shift."

Lest I be accused of creating a straw man, this school of thought usually acknowledges the desirability of putting certain process and operational practices in place but it nonetheless views DevOps through the lens of the organization’s culture. Given that setup, it’s probably obvious that I think that DevOps has aspects of both tooling and culture. But I want to frame things a little bit differently.

For this alternate framing, it’s worth thinking about how manufacturing—to which analogies to DevOps are often drawn—has evolved over time: Standardized parts—often dated to the Système Gribeauval for cannons in 1765. The processes and machinery that Brunel and Maudlay applied to sailing blocks to standardize production at the beginning of the 19th century. The many innovations in automobile manufacturing, including highly-automated assembly lines, reusable automobile platforms, lean manufacturing, and systems approaches such as "The Toyota Way."

Many of these things can be thought of as cultural shifts: craftwork to factories, ad hoc observation to statistical quality control, reduced cycle times, and the empowerment of assembly workers. In essentially all cases, they represented a decisive and deliberate shift from business as usual. However, I largely agree with JP Morgenthal when he argues that "There is no single agreed-upon standard of what culture looks like when DevOps adoption is complete." He adds that "Every enterprise’s challenges are different and the behavior driving those challenges are different."

Discussing the top skills needed for Enterprise DevOps, Andi Mann states:

"Talk of DevOps almost immediately focuses on culture—like having empathy for fellow workers, being flexible and adaptable, seeking continuous improvement, building relationships, etc. However, while critically important in DevOps, culture is an outcome, not an input; and such attributes are mostly either innate or acquired slowly. Culture cannot easily be taught."

At the last CloudExpo in Silicon Valley, JP, Andi, and I hashed this topic out over some Mexican food, and I far more agree than disagree. If we’re using “culture” as a shorthand for the large number of factors that result in culture, we’re “only" being imprecise. But it’s more than a semantic quibble because it can distract us from focusing on actionable steps such as creating the right organizational structure, properly aligning incentives, and—yes—putting appropriate tooling in place.

I see a lot in common with how open source approaches and, to get a bit touchy-feely about it, an open source lifestyle can help companies down a DevOps adoption path. Open source is increasingly the default way that software technologies get developed. From cloud computing to big data to mobile, open source is pervasive. That evolution wouldn’t have happened had both individuals and organizations not learned how to use open source to create software more effectively. Open source is more than just opening up your code—it's also a very special way to develop and collaborate.

DevOps is fundamentally about adopting many of the same open source best practices. Agile. Transparency. Collaboration. Iterative fast release. Continuous integration. These come together and, over time, create an open source lifestyle and culture. They can likewise come together to make DevOps thrive.

It takes a vision and strong sponsorship from management, but it’s not about imposing a cookie cutter culture from on high. It’s about evolving the many aspects of an organization that create a culture that works for that organization to make it more effective—whether with respect to DevOps or to other activities. It’s also about having the right values and incentives to create an effective DevOps community that values open exchange, systems thinking, and broad participation.

User profile image.
Gordon Haff is Red Hat technology evangelist, is a frequent and highly acclaimed speaker at customer and industry events, and is focused on areas including Red Hat Research, open source adoption, and emerging technology areas broadly.

1 Comment

Open source has been and is a challenge to traditional hierarchies. The base line is control.
Trying to control everything only results in the blindness that makes one think one is in control.
It's always a management issue. Open source is a legacy of the cultural changes of the 1960's which challenged hierarchies.

Despite all the talk of disruption today, corporate culture in the main is not any less of a hierarchy. What we have is a "containerization" of disruption. For the average tech grunt, it's still fiefdoms and politics which rule the day and the need to keep relevant as corporations continue to look for ways to enhance the bottom line by reducing labor costs.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.