Matt Hilbert

20 February 2019

You’re ready for DevOps, but is your workplace?

DevOps is gathering pace. More and more organizations are recognizing that by encouraging collaboration, cooperation, and communication, they can release features faster and offer advantages to customers sooner.

That’s the promise, but in order to adopt DevOps, organizations need to be able to embrace the openness it requires, change the way they function, encourage experimentation and innovation, and work across departmental silos.

It’s not as easy as it sounds and the reason lies in an academic paper written by Ron Westrum, an American sociologist, in 2004. Originally published in ‘Quality and Safety in Health Care’, an international peer review journal for health professionals, A typology of organisational cultures is as relevant today as it was then. Perhaps more so. Importantly, the model he created is applicable across every industry sector.

Westrum wrote the paper following research into the belief that organizational cultures shape many facets of performance. He was looking in particular at the safety aspects of healthcare, but he used his knowledge of organizational dynamics from many industries going back decades.

What is an organizational culture?

Westrum defines the culture within organizations as: “The patterned way that an organization responds to its challenges, whether these are explicit (for example, a crisis) or implicit (a latent problem or opportunity).”

He called out the way organizations process information as a type marker for culture, and identified three patterns, each created and shaped by the focus of management and the response of the workforce to that focus. These became what is now called the Three Cultures Model:

Westrum discovered that each of these organizational types influence activities such as communication and cooperation, which causes organizations to respond characteristically to problems and to opportunities for innovation. Indeed, the way they process information and behave is predictable in almost every case.

Pathological cultures are created within organizations by individuals who focus on personal power and the hoarding of information to gain advantage. The management style is typically domineering, with innovation and creativity discouraged because they threaten the status quo.

Bureaucratic cultures emerge where the emphasis is on following rules and defending departmental turf. Whether it’s good for the organization or not, existing procedures and practices are not questioned and change is seen as a predicament that must be subjected to intense scrutiny.

Generative cultures arise when the motivation is the broader mission of the organization. This creates a climate which encourages the solving of problems rather than seeking the cause of them, and supports innovation and cooperation within and across departments.

It’s interesting to note here that the cultures Westrum talks about can exist throughout an organization, or within units or departments of an organization. So one part of an organization may be pathological, while another is generative.
The bureaucratic type of culture is also often the one that organizations or departments default to when there is no politics in play at one end of the spectrum, or mission to aim for at the other.

You can probably guess where this is going. You may even recognize which column of Westrum’s Three Cultures Model the organization you work for fits into.

By its very nature, DevOps requires cooperation and collaboration, and a culture that welcomes change. So the further right your organization sits in the model, the better the fit with DevOps.

Can organizational cultures change?

If you work in a department or organization with a pathological or bureaucratic culture, you might be thinking DevOps will never be an option. Encouragingly, however, in his conclusion to his paper, Westrum says: “By changing the culture, virtually everything can change – trust, openness, confidence, and even competence.”

And cultures in the same organization can change over time, depending on the management style in place. Westrum himself, for example, uses NASA to illustrate how a generative culture can solve a problem – and how a bureaucratic culture can prevent problems being solved.

When an oxygen tank exploded on board the Apollo 13 spacecraft in April 1970, it left the three-man crew stranded in the Command Module with rising levels of carbon dioxide and an apparently impossible journey home. Mission Control didn’t give up. While the famous line, “Failure is not an option”, from the Apollo 13 movie was never actually said, that was the attitude.

Mission planners worked out a way to use the moon’s gravity to sling-shot the spacecraft back to Earth. NASA engineers improvised a carbon dioxide filter using a hose taken from a space suit and a myriad of other odd bits and pieces available to the crew. A team of six engineers from the University of Toronto were called on to calculate the exact pressure required to separate the Lunar Module from the Command Module on re-entry. They used slide rules.

At 12.07pm on April 17, 1970, the Command Module of Apollo 13 splashed down in the South Pacific Ocean. All three crewmembers survived. A generative culture at work.

Fast forward to January 16, 2003, and the launch of the Space Shuttle Columbia from Kennedy Space Center. During launch, a large piece of thermal insulation from the external fuel tank broke off and damaged the left wing of the orbiter spacecraft.

While the two-week mission went ahead, some NASA engineers were concerned about how the damage would affect re-entry when the orbiter returned. They requested imaging of the orbiter to determine the level of damage. Repeated requests were ignored and in some cases quashed. Worried, a former NASA Flight Director worked outside official NASA channels to get the imaging. He too was ignored.

Instead, a damage prediction spreadsheet, created to calculate the impact severity of ice pellets the size of cigarette butts was relied upon. The piece of thermal insulation that struck the wing was the size of a suitcase.

The attitude of senior NASA managers was influenced by a belief that nothing could be done if severe damage was detected, and to keep the orbiter crew themselves in the dark about the situation.

At precisely 9.00am on February 1, 2003, the orbiter disintegrated in the sky over Dallas ,Texas, on re-entry. Hot atmospheric gases had penetrated the damage in the left wing and destroyed its internal structure, causing the spacecraft to break apart. All seven crewmembers died. A pathological culture at work.

Can you introduce an organizational culture?

We don’t all work at NASA, or even do jobs which involve saving lives. Most of us, however, want to work for an organization where the culture encourages innovation and collaboration, and lets us do the right thing. So what can you do to introduce a culture that is more responsive to DevOps?

If you work for an organization with a pathological culture, DevOps just isn’t an option. Cooperation and collaboration are actively discouraged, so the glue needed to connect Dev and Ops is missing. If you really want to do DevOps, you’re out of options here and it might be worth moving on.

In bureaucratic organizations, introducing DevOps is possible, but there will be problems. Think soft DevOps here, with long lead times and planning meetings before a tentative first step is taken. Patience is key but conversely, once DevOps is introduced, it will become the new norm and take its place in the rulebook.

Generative organizations are where DevOps will be seen as a natural next step if it’s not in place already. Every facet of their makeup matches the advantages of DevOps and, perhaps unsurprisingly, Westrum mentions a mass of case study and anecdotal evidence which demonstrates how the cooperation and empowerment within generative organizations makes them more effective.

So if you’re ready for DevOps, take another look at Westrum’s model and decide where your organization sits within it. The next step will be down to you.

This article was originally published on Agile Connection.