Winning at Whac-a-Mole: Overcoming Psychological Barriers to DevOps Transformation (second of three)

Author’s note: This is the second in a three-part series about why DevOps transformation can be so hard for an enterprise, Be sure to read Part 1: Overcoming Process Barriers to DevOps Transformation: A Herculean Task.

Resistance to change is one of the largest barriers to successful enterprise adoption of DevOps. This can be especially true when you try to scale the concept beyond a tiger team or skunk works to the entire software development and infrastructure ops resource pools. Resistance to change is human nature, and the mere whisper of forthcoming “change” can elicit anything from passive-aggressive behavior to overt resistance from anyone within shouting distance.

Why? Because change disrupts our “equilibrium.” Change forces us to move beyond our comfort zone in the safe status quo and into the unpredictable, uncertain, world beyond-our-control—and this creates fear.

Popping Up Everywhere

In our work with enterprises all over the world, we see this fear of and resistance to change popping up in all sorts of unproductive ways—like ugly Whac-a-Moles—in the midst DevOps transformation journeys. You can arrange these anecdotal experiences of corporate organ rejection into roughly three categories.

This isn’t easy stuff. Solving problems of this variety are how large management consulting firms stay in business. But, if you face these fears rationally, you can begin to see how the rational self-interest of enterprises can win the day, especially among enterprises where leaders understand the existential imperative to change.

Without further ado, those three categories of fears we commonly encounter are:

  1. Fear of losing control
  2. Fear of failure
  3. Fear of obsolescence

Now, let’s look at some ways to anticipate where these fears may raise their ugly heads in your DevOps journey and how to keep things moving in a positive direction.

Fight Fiefdoms

We fear losing control. This also goes to human nature. When you introduce change people feel like this will impact their ability to maintain control of the environment they own. If things don’t change, at least they know how to keep the lights on, even if the process is less than ideal.

If fact, we are so enamored with control that in many large enterprises, we see evidence that there has been some “event” or out-of-control situation that has precipitated the knee-jerk addition of a non-productive, non-collaborative policy to ensure that event never happens again. We see this evidence in policies like “no development access to production systems,” and vice versa. I have heard things like “We don’t do blank in that environment” where blank could be technologies like DHCP or load balancing.

It is easy to see how these fear-based policies come to be. These environments are managed by different people, each of whom are being evaluated independently. Therefore, they each have a strong incentive to maintain control by “protecting the fiefdom.” But DevOps requires the elimination of these fiefdoms and the policies that sustain organizational silos.

When you implement a new process, people will need to collaborate in ways that they have not done before. They will need to trust people with things that they have not been entrusted with in the past. Each organization is different, but finding that “thing” that gets people to collaborate is critical to overcoming this psychological barrier.

Give Deployment an “Easy Button”

Processes that are unnecessarily hard and complex are prone to fail. No one likes to fail.

So, when a transition to a DevOps workflows begin, you’ll find that the people who are the biggest disbelievers generally have been responsible for deployments in some form or fashion. These people have seen the worst of it. Deploying code that has never been deployed before into a production system is scary.

But herein lies the beauty of DevOps. One of the primary benefits of maintaining a code base that can be deployed at any time is that to get to this state, you will deploy it over and over again. When your code base is being continuously integrated and deployed, by the time you get to the production system, you will have deployed this code several hundred times (the actual number of deployments will vary based on the size of the team, size of the code base and the length of the project).

By performing this deployment over and over again, there should be no surprises when it comes time to stand up an application in production. Practice makes perfect. A code deployment to a production environment, should be the easiest thing we do, not the hardest. Give deployment an “Easy Button” and watch fear evaporate.

Invest in Training

Another common source of resistance to DevOps is a fear of obsolescence— ”If this works, they won’t need me any more.” What your IT team needs to know is that the DevOps transformation can not only make the company more competitive and successful but also make their job more important to the organization than ever before. After all, the success of your company’s DevOps transformation is to a large extent dependent upon the expertise of the individuals charged with architecting, implementing and operating the infrastructure. Plus, DevOps will improve day-to-day work life of IT professionals considerably by eliminating unproductive processes that generated conflict, dissention, deployment failures, etc.

One of the best ways to establish trust in this regard is to invest in your people. Provide training and mentoring to ensure they have the necessary knowledge and skills to execute and sustain your DevOps transformation.

The fears associated with change are not always rational, but they are real and potentially destructive to your DevOps journey. Keep these fears—like Whac-a-Moles—out of play by anticipating them and facing them head on.

Read our final post of this series … getting down to business, with tips on taking care of several of the most common business barriers to DevOps transformation.

Author: Seth Fox