At least once a week, I find myself in an exchange with an IT manager about if DevOps is an organic, bottom-up culture thing. Their thinking is this: start hosting a few hackathons, start a DevOps learning center, and get server engineers to understand how servers connect to the “why” of their business, and the momentum and associated “people change” will be too much to stop. They think all they need to do is to make a Mad Men-style sales pitch to IT leadership, and DevOps will sweep over them like a wave. It’s clear they believe in what they are saying, but they haven’t been through actual, successful enterprise IT change.

Once you’ve operationalized DevOps in a conservative, well-established enterprise IT organization, you understand why relying on the organic, bottom-up approach to change will always lead to major resistance or even the effort being squashed.

Here are some of the reasons why:

  • DevOps impacts the entire IT value-chain and disrupts the majority of established norms.
  • Major disruptions are always expensive to implement and require leadership sponsorship.
  • Organic efforts are always one leadership change away from being squashed.
  • Product vendors with deep relationships are trying to capitalize on DevOps and sell DevOps as a tool problem. (In reality, it’s people, processes, and tools.)
  • Existing partners whose revenue streams are disrupted by cloud, automation, and DevOps are trying to misdirect and misinform.
  • People – even IT leadership – tend to dislike truly disruptive change like DevOps, and resistance to change will start to be too overwhelming when additional major disruptions occur.

Admittedly, it took me a few tries to get it right, but I realized that there are two main points I needed to continually focus on to drive the DevOps change:

1. Relentlessly pursue IT leadership’s complete buy-in to the idea that change enabled by DevOps impacts all areas of the IT value chain. DevOps will require a major investment, and that investment is worth it. Data from value stream measurements, impact examples from existing DevOps wins, examples from other organizations, and a clear plan of action for instituting and scaling DevOps are all table stakes.

2. Remain aware of how the current IT system really works, and how that blocked us from realizing the benefits of Agile, cloud, and automation. Understand what the system will look like once we embrace DevOps, and keep in mind the efforts we are making to realize the target state. This helps avoid the confusion, misinformation, and misdirection from other parties. It also tends to smooth any transitions in leadership if our current and proposed efforts are well established and thought-out.

The irony is that once a few initiatives have been started to ensure the second point above is well supported, and the first point is well underway, culture things like hackathons, learning centers, and a tight connection between technology and business motivations become a reality. These things are the result of a well-supported and planned DevOps change program – not the contents of one.

Organic change is hoping for a perfect alignment of the stars and initiatives. We tend to advise our clients that for DevOps to be adopted quickly, they need: to start realizing the benefits of cloud and agile, a well-informed plan, and the unwavering desire to have IT leadership to be the true sponsors of DevOps.