Building a DevOps Culture - Speed, Risk, Patience & Trust


DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative [silos]. The promised benefits include increased trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.1

DevOps is evolving…into a culture for continuous delivery of IT services. As more pieces of the puzzle fall into place, we understand that DevOps is primarily a matter of human collaboration -- assisted, but not encompassed by, certain tools and technologies.[2]

Expanding the terrain with DevOps

The word “DevOps”, written like that, is a merger of “development” and “operations”. It referred, originally, to efforts to merge these two aspects of software activities, whereby “factory product” is transformed (Dev) into “consumable product through a delivery mechanism (Ops)”.[3]

“DevOps culture” expands the terrain, so to speak, on which DevOps has been built. It is also the secret ingredient required for any organization that is seeking to embed DevOps practices into its own business processes. Only once it has adopted DevOps culture will the organization be able to reap the benefits that DevOps offers. Just as the song says, “You can’t have one without the o-o-ther.”

Levels of DevOps readiness

A lot of younger organizations have been able, from day one, to build advanced software and/or services, and agile practices, into how they do business. If they haven’t already done so, they will likely be able to integrate DevOps culture, and the techniques and habits underlying it, into their day-to-day operating fabric.

But for many other organizations, integrating advanced technology is and will be a struggle. These companies need to contend with legacy systems—to take just one example—but also with a culturally ingrained reliance on those systems and other bits of baggage. So there are struggles of two kinds: technical—let’s call this “objective” for present purposes—and cultural: “dispositional” or “subjective”.

At its most fundamental, “culture” is all about habits—about keeping them, changing them, updating them, and—yes—breaking them. And when we are talking about habits, we are often also talking about interests. “Interests”, too, can be classified along the same fault lines:

  • “objective”: related to those factors that actually have an impact on the well-being of an individual or an organization
  • “subjective”: having to do with perceived threats to one’s own, or an organization’s, well-being

DevOps Change - Technical and Cultural

The investment required to effect fundamental cultural change can, in its own way, be just as significant as that required to bring about technical changes. If this sounds like a bit of an overstatement, consider this: according to Gartner, this year 90% of infrastructure and operations organizations that try to use DevOps “without specifically addressing their cultural foundations” will fail in the attempt.[4]

This kind of statistic should serve as a wake-up call for organizations that have been considering integrating not only DevOps but also DevOps culture into their fabric. And this is particularly true when it comes to a key factor in effecting change: the pace of that change.

DevOps tensions - Conceptual and Practical

There are two key tensions we can identify around this pace-of-change factor. And understanding these, and how to address them, can already help organizations ensure they can build a robust DevOps culture.

The first tension is conceptual: between speed on the one hand and, on the other, deliberation or patience, with the organization’s (overall cultural) attitude to risk[5] serving as a kind of mediating element.

The second tension is practical: it revolves around a basic conflict of professional interest between the two communities of actors whose work is involved here: (Web) developers and infrastructure, or operations, engineers.

Let’s look at each of these tensions in turn.

To go faster, first be patient

In one (simplistic) sense, like Fordism, Taylorism, and even Muzak before it, DevOps can be seen as being all about speed – about producing more in less time. Definitions of DevOps vary considerably – as a notion, it is still a work in progress – but one thing they all have in common is a reference to timeliness: “DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases….”[6] Similarly, a McKinsey blog put out last year began:

Rapid innovation, time to market, customer-centricity, acting like a start-up—sound familiar? They’re all buzz phrases that excite the CEO and instill fear in those tasked with running, transforming, and safeguarding their organizations…. Agile methodologies really can accelerate product development, drive new value, and spur organizational change.

But difficulties emerge when the need for speed is emphasized in isolation from the other key elements of DevOps – and this is where things can get tricky. The same McKinsey blog gives an example:

We’ve seen many organizations such as banks and telcos pour millions into agile development and deliver a finished product after every sprint—and then wait (and wait . . . and wait) for it to pass through traditional sign-offs and further rounds of testing. When the product finally does go live, it’s via a big, old-fashioned release.

One reason the piece cites is a “deep-seated cultural aversion to risk”, related in turn to the need to meet “demands for compliance”. And it argues that it “takes a massive shift—a cultural shift—to overcome” the caution that in the end serves as a brake on the pace of change.

Conflicts of interest: developmental change vs operational resistance

And that brings us to the second tension we noted above: between communities of professional interest within an organization. At one level, this tension can be seen as rooted in a “conflict that has come about from years, decades even, of development and operations teams being segregated from one another and not being enabled to communicate, let alone collaborate, effectively.” But it gets worse: Mark Burgess sets the problem out as follows:

There is [a] basic conflict of interest between the roles of developer and operations engineer…. Web developers are motivated to push out new goodness as fast as possible. Infrastructure engineers often have little incentive to change anything. They are used to being ignored until something goes wrong, whereupon they are the first line of blame for the fault. Deploying something without due diligence would only land them in trouble. To developers during the web boom, operational resistance was the problem. To operations, developmental change was the problem.

To tackle this fundamental problem, fundamental change is required. And it must involve the aforementioned “massive…cultural shift”. The first adjective means, here, that the shift has to take place across the organization. And that takes time – precisely the commodity that seems in such short supply if we take a narrow view of DevOps as merely about achieving efficiencies.

The second adjective, “cultural”, refers here to the attitudes that all key actors in any change programme have towards that change. And the central component in any changed attitude is trust. And lest we seem to be getting too touchy-feely here, let’s specify that we mean “functional trust”. Building this kind of trust among actors in an organization is key to building DevOps culture into the fabric of an organization.

DevOps - Small word, big demands

In the end, then, DevOps is a short word that actually comprises a series of demands that are nothing to sneeze at:

  • On the technical front: get your organization’s kit in place, cleaning out the legacy clutter

  • Engage with, and educate, all actors who will be implementing the changes that a new DevOps culture will allow, as well as all staff who will be affected by them (probably everyone)
  • In particular, work to build a culture of trust around compliance with regulations and requirements (as opposed to building a culture of just compliance)
  • Be prepared to slow down, in recognition of the massive scale of change, in order to go faster, both across the board and sustainably

It’s like anything else, though—meet these demands, and the pay-off, in the form of a “culture of effective and seamless collaboration”, is more than worth it.[7]



[2] Source:
[3] Source:
[4] Source:
[5] See
[6] Source:
[7] Source: