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-reviewed journal for health professionals, “A Typology of Organisational Cultures” is as relevant today as it was then. 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 health care, 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 he identified three patterns, each created and shaped by the focus of management and the response of the workforce to that focus: 

Westrum discovered that each of these organizational types influences 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 that 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. One part of an organization may be pathological while another is generative, the driver being the leadership in place, because it is the preoccupations of individual leaders that shape cultures.

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 … and also where DevOps is more likely to take hold.

By its very nature, DevOps requires cooperation, collaboration, and a culture that welcomes change. So the farther 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 the conclusion to his paper, Westrum writes, “By changing the culture, virtually everything can change—trust, openness, confidence, and even competence.”

The key is to influence the leadership style by, for example, referencing sources like The State of DevOps Report from Puppet and DevOps Research and Assessment (DORA) to demonstrate the business benefits DevOps can bring to an organization. You also could try using a DevOps approach to resolve a small but difficult issue. Doing so may open eyes to a better way of doing things.

And cultures in the same organization can change over time, depending on the management style in place. Westrum himself, for example, uses two different examples from NASA to illustrate how a generative culture solved a problem under one flight director and how a bureaucratic culture prevented problems being solved under the leadership of another.

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 from the Apollo 13 movie, “Failure is not an option,” was never actually said, that was the attitude.

Mission planners worked out a way to use the moon’s gravity to slingshot 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.

At 12:07 p.m. on April 17, 1970, the Command Module of Apollo 13 splashed down in the South Pacific Ocean. All three crew members 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, staff relied on a damage prediction spreadsheet created to calculate the impact severity of ice pellets the size of cigarette butts. 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, so they opted to keep the orbiter crew in the dark about the situation.

At 9:00 a.m. 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. This is a tragic example of a pathological culture at work.

Can You Introduce an Organizational Culture?

We don’t all work at NASA, or even do jobs that 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 probably 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 successfully 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. Perhaps unsurprisingly, Westrum mentions a case study and anecdotal evidence that demonstrate 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.