How to Market DevOps to Your Executives

It's late Saturday night. You rub your eyes and look away from the computer screen for a blissful few seconds, the first time in hours. The weekend elevation of your company's latest application that will "save the company" started a day ago. It hasn't gone smoothly. Moreover, the project is "too big to fail." You'll be here all weekend if you have to, trying to figure out why the application won't work.

You know there's a better way. You know DevOps practices and culture would make your IT department way more productive. What you don't know is how to communicate this to your management.

Thankfully, another team is debugging the problem, so you have a little downtime. You open up trusty Google and try to figure out how to market DevOps to your management and executive team. Their buy-in is crucial.

Developer, Develop Yourself

Technical folks don't always have the best communication and people skills. Unfortunately for some, winning management over is more salesmanship than technical skill. Sales? Yuck. But it's true.

However, the sales skills you need aren't the kind you see at a used car dealership. Instead, use the sales techniques many third-party vendors use to get companies like yours to buy their product. They try to learn about your organization and what its values are. From there, they can tailor their presentation and pitches to show how their product reduces or eliminates specific pains that your company feels.

A similar tactic is necessary in order to convince management that DevOps is worth the investment. Ask yourself, "Who signs off on DevOps?" Find the person, usually a VP or C-suite person, who will sign the check and sponsor the project. Then ask, "Why would this person sign off?" You need to determine what pains matter to them. Cool technology is not enough to convince executives to spend money.

You take out a piece of paper and start a checklist of what you need to convince your management that DevOps will help your company. You write down the following:

• Find out who will sign the check
• Think about what will make that person sign the check

You're interrupted by your buddy who thinks he may have fixed the issue. You take a quick look at the code change, listen to his explanation, then approve the change. Now you need to rebuild and redeploy the application. This gives you another 45 minutes to an hour to do some research.

DevOps Proof Points

Executives are going to be curious about what other companies are doing. This helps to convince them that they are not about to spend millions of dollars on one developer's flight of fancy.

There are several pieces of information available on how DevOps has worked well for other companies. One such resource that I think is great is Puppet's annual "State of DevOps Report." This report takes an extensive look at low and high performers in terms of DevOps adoption and outlines what makes one more successful than the other.

After looking through the resources, here's what you find. Keep in mind that you need to understand what is important to the person signing the checks. Not all of these may apply.

First off, high-performing organizations deliver code much more quickly than low-performing companies. In fact, these high performers deliver 46 times more frequently than other companies. They deliver code to production multiple times a day.

You stop in your tracks. You know what will happen next. When you tell your managers that these organizations deploy to production multiple times per day, your managers will immediately run away screaming as if they were on fire. They envision the nightmare of what is happening this weekend happening even more frequently.

Is More Frequent More Risky?

You decide to soldier on regardless. You're glad you did. Because you now stumble upon some numbers that show quite the opposite is true.

Mean time between failures (MTBF) and mean time to recovery (MTTR) are common terms in operations to describe the stability of a system. MTBF measures how much time passes between systems failing. MTTR measures how long it takes to bring systems back online when failures do occur.

In the DevOps world, MTTR is much more important. When you use the right technologies, such as containers with orchestration and configuration tools like Puppet or Chef, you become agile. You can destroy servers and recreate them in seconds. When a failure happens, you can fix it much faster.

The numbers bear this out. High-performing organizations have an MTTR that is 96 times faster than their low-performing brethren. On average, an outage lasts less than one hour for these organizations. Failures will happen in any complex system. How you recover is more important than preventing failure. Companies like Google, Netflix, and Amazon don't care if a server dies or starts acting up. They kill it and bring up a new one in minutes. The customer is none the wiser.

Talking about failures still makes people uncomfortable, at least in the initial stages. However, you can help alleviate that by noting an important truth: elevating more frequently is not riskier. This may seem counter-intuitive but think about it for a second. More frequent delivery means smaller code changes for each delivery. If only one or two lines of code have changed, how much damage can really be done?

On the other hand, working on hundreds or thousands of lines of code for months and then trying to deliver it all at once is what leads to the long weekend you're currently facing. The stats bear this out. High-performing organizations have troublesome elevations that are five times fewer than other organizations.

Your VP of operations would love to hear that software changes will bring down production fewer times. When problems do occur, you'll be able to resolve them in minutes, not hours or days.

You take out your notepad and jot this stuff down.

• DevOps leads to faster delivery with fewer outages due to elevations
• DevOps leads to faster recovery from problems when they do occur.
• VP of operations would love this.

This is good.

Your Mission and Customers Are Important

Development managers and the VP of engineering are traditionally more focused on features than operational excellence. DevOps helps in this regard as well.

An important concept in DevOps and lean practices is "true North." True north refers to the singular mission and purpose for your company existing. Why do you deliver software? Adopting lean strategy means cutting out anything that doesn't add to your ability to fulfill that mission.

Serving your customers is an important part of that mission. Are your customers constantly complaining about outages and buggy web applications? How much money is spent taking calls from upset customers? How many developer hours are spent fixing these problems?

Your VP of engineering will be quite happy to hear that the VP of operations or the COO will praise his engineers' good work, not curse them. Executives care about what their peers think. Giving them the ammunition to brag a little about their organization will be a selling point unto itself.

If your development manager won't buy that argument, then remember one word: bugs. According to this post, the cost of finding a software bug in production is 100 times more expensive than finding that bug in requirements and about seven times more expensive than a bug found during testing. DevOps practices save money by using practices and technology that find bugs earlier in the development lifecycle.

Your trusty pad comes out again:

• Define the company's mission and reduce or eliminate processes that don't further that mission
• Reduce customer phone calls due to software bugs and outages
• Save money by finding and fixing bugs earlier in the development lifecycle

Better Prepared to Sell

Finally, the application is working. It's early Sunday morning now, but at least you can go home. However, you aren't going home empty-handed. You have a notepad with great points jotted down on how to market DevOps to your executives and management. You revisit this list and revise it. It's looking good now:

• Find out who will sign the check (VP of operations and VP of engineering).
• Think about what will make that person sign the check.
• Reduce the number of elevations that cause outages.
• Fix problems more quickly if an outage does occur.
• Improve morale by eliminating unnecessary processes.
• Wipeout customer phone calls due to bugs and outages.
• Find and fix bugs early to save potentially 7-100x.
• Reduce pain, like long outages, angry customers, infighting among senior leadership, and wasted money.

You drive home tired but satisfied. You're ready to come in on Monday and pitch DevOps. Sales doesn't seem so bad after all.