Grant Fritchey

12 April 2022

DevOps 101: How do you get buy-in from people?

In the first part of my DevOps 101 series, we tackled the fundamentals of What, who why and how. In this follow-up, I’m going to focus on how to gain buy-in across your organization.

That said, who do you need buy-in from?

DevOps is the union of people, processes and products to enable continuous delivery of value to our end users, according to Microsoft’s Donovan Brown. That’s a good explanation, because the focus is not on tooling, or processes, or even just people. The idea of implementing DevOps is to get as many people involved as you can, get them engaged with what you’re doing, and deliver value. That’s what it’s all about: delivering value.

So who is involved with DevOps? The answer is everybody. Your specific role in an organization really doesn’t matter – you can and probably should be involved in DevOps. This presents a challenge because if you don’t have support and engagement from everyone, you’re going to have issues getting DevOps implemented.

So how do you get everyone involved? How do you get their buy-in? How do you get them to agree that this is a good idea?

1. Measure your pains

Whether you’re in a technical or managerial role, it doesn’t matter. You need to start by measuring your pain. If you’re not getting things out of the door, you need to identify the bottlenecks. How long does it take to release new functionality? Why does it take so long? Why are you slowing down? Why are you unable to develop, test and deploy quickly? So that’s your first thing: how long it takes.

Second, how much downtime do you have? If you have failed deployments because what was deployed had errors and you had to spend a bunch of time fixing and recovering, then it wasn’t functional. In one organization I worked at, it would sometimes take four or five hours to get a successful deployment out of the door.

Measure these pains. Write them down, record them, get some idea of how long it takes you to do deployments. How many person hours are being dedicated to getting ready for a deployment, doing the deployment, and then recovering from the deployment? How much pain is involved across your organization? And don’t forget, also look at your competition. How is your competition doing on this stuff? Are they getting stuff out of the door faster?

Write all this down. One of the most important things you’re going to be doing through this whole process, and when you start doing DevOps, is communicating. When you start the important conversations, you need to write everything down and maintain and update it over time, so you can share the same information with everyone. This way they understand why you’re moving slowly, why you’re not delivering the things you need to deliver, and that’s where you’re going to start measuring your pain.

2. Identify champions

The next thing to do is identify champions. When I say a champion, it’s not necessarily the most knowledgeable person. It’s more important to find someone who not only can do the work but is enthusiastic about it and buys into the concept. But you don’t just want one champion, you need at least two. I recommend someone from management, and someone from the teams. Between those two, you’re going to have champions that can communicate and advocate for you from top down and bottom up.

You’ve researched DevOps and how successful organizations are when automating aspects of their development and getting functionality out the door faster and safer. You’re on board with that, and you want to find those people who say, ‘Yes, that sounds like something we should be doing’. Most importantly though you want to find people who say ‘I’m willing to change the way I work to implement and deliver this’. Those are your champions.

How do you identify the champions? The easiest way is to talk to your teams. See who is already aware of the DevOps concept, who is interested in automating things, or who has already identified bottlenecks and started to address them. There’s no limit to the number of your champions so get talking to the teams, find out who’s going to enthusiastically advocate, bring them onboard and run with it.

3. Adopt the language

What do I mean when I say adopt the language? Identify each of the teams that you need to bring onboard and talk to those teams as if you were one of them. So if you want to talk to developers, you’ll need to start discussions around what’s going to allow them to deliver code faster? What is it that they need to make these things happen? You’re talking to them in their language and focusing on what they care about, because now they’re interested and invested in what’s going on.

You should always start discussions by talking about their concerns and get their side of the story on what is causing them pain. Find out what they don’t like with existing processes, where they’re currently hitting bottlenecks and why things aren’t moving quickly. Then move the conversation to potential benefits: ‘You’re not getting code out the door. Well, we’re going to be able to do that faster once we set this up’. But you can’t mask or hide the way things are going to be. They need to know that there’s going to be some growing pains as you implement the changes.

This is where it gets tricky, because some people are going to be onboard with change and willing to learn – those are the easy conversations. Then there’s going to be the harder conversations, and they’re almost always going to start with one phrase: ‘That’s not the way we’ve always done things’.

As soon as you get that phrase, you’re going to have a tough time. That’s when we bring in the third thing: identifying the individual’s communication style. Are they more of an ask or tell kind of person? The way they communicate is the way you should communicate to them. No matter their preference though, the communication flow is always the same: discover their concerns, outline the benefits, and figure out how you can get there together.

4. Educate

You’re going to start with your champions. They’re going to be the ones advocating for you throughout the process, so make sure they feel comfortable enough in their own knowledge and skills to help lead the team.

That’s not to say your champions need to know everything there is to know about DevOps, because it’s just not possible. Personally, for example, I have no idea how you automate virtual machine stuff, I just know it can be automated, and that we need it automated. So I go to the team that knows this information and educate them on why we need to automate, so that they can set it up.

What you need to learn about is DevOps, and the very first focuses are collaboration and communication. You’re going to communicate to your champions that walls are going to be torn down and that ‘We’ve always done it this way’ is not an acceptable blocker.

When you start to adopt DevOps, you want to be open and transparent because it’s all about cross communication, and cross collaboration. So you also need to educate people in the processes that you’re starting to build. Show them exactly how you can get code in and out of source control, and then do a continuous integration build. Talk about how you get a deployment from dev into QA, and from QA into Staging. Explain how to automate each one of those steps, add additional tests, and how these add protection to our production environment. The entire process must be identified, documented, and then communicated.

As part of the education process, you’re also going to need to explain the initial setup costs, and these are predominantly time and effort, not money. Implementing DevOps, setting up automation, building automated testing, is a lot of work and you’re going to be slowing down at least one team while you figure this out. They’re going to deliver less than they have been to spend time working on the automation, but once it’s done, they’re going to speed up. And that leads us to talking about the rewards.

Rewards should be the last thing you talk about and work on in your education. Don’t lead with the fact that you’re going to deliver more code faster and safer. Instead, take them through the process. Explain why you’re setting it up this way and ask if there are any issues with that. Then define how you’re going to automate, outlining that it’s going to take a couple of weeks to get it running correctly, and there may be bugs during this time until it’s set up. This education is a major part of the implementation, and a big part of bringing everyone on board.

5. Measure your gains

You’ve measured and recorded your pains, identified champions, adopted the language and gone through the process of education. Now you’re ready to start the implementation. This is when you can really build momentum and start to sell DevOps across your organization, by measuring and reporting the gains.

As you begin the process of communicating to peers and bringing teams onboard, one of the very first things you need to do is define what success looks like. It may be that it currently takes three days to deploy, and they want to get this down to three hours. So, three hours is the goal.

As soon as you’re successful, share it with everyone. People who aren’t involved, people who are naysayers, certainly the people who are not your champions. Let them know the successes. You want to be able to contrast your new gains against the initial pains (which is why you record them at the start of this process).

The thing about pain is, everyone forgets. If you have a broken bone, you’re certainly aware of the pain at the time, but as soon as it heals you don’t sit around thinking about it, you move on. It’s the same issue here. As you start to deploy faster and safer, people are going to forget that it used to be painful. They’re not going to remember that it used to take hours to get this stuff done and now it’s just minutes. You need to showcase your pain to gain comparisons to achieve the ultimate goal of growing buy-in across the organization.

If you haven’t read them yet, you can catch up on the other posts in this DevOps 101 series:

• DevOps 101: What, who, why, and how
• DevOps 101: How to kick-start your DevOps initiative
• DevOps 101: Introducing Database DevOps
• DevOps 101: The role of automation in Database DevOps
• DevOps 101: Unlocking the value of frequent deployments