How to explain devops to non-techy managers?

Question

I'm totally excited about DevOps. I know that DevOps is the methodology that will move us into building an IT infrastructure that will streamline and move our company forward.
But how do I sell this to my bosses, especially non-technical bosses?

We are going to implement an automation project which will include, automated deployment , infrastructure cloudification , continuous integration process .. we definitely need to persuade our bosses to invest at higher levels in this.

Note: we started to improve our process by automating tests, releases and supervision , it's a step towards adopting devOps but the automation project itself is in stand by as we need more investment.

Answer 1

Being a consultant I am contractually obliged to answer, "it depends". With that out of the way, I can actually answer your question.

What does it depend on? Well, that could come down to what your boss thinks about DevOps:

1. If your boss has heard of the term, via their obsession with CIO.com maybe, then ask them what they think it means. From there work out what the difference is and if their view is compatible. Identify a suitable project to trial DevOps on and pitch it to them. Remember that at the core DevOps is culture so consider how that could be applied to a project.

2. If your boss has never heard of the term then build a business case for DevOps. Use the Puppet Labs State of DevOps and material from books such as The Phoenix Project to write the business case. Find a problem that your boss has and DevOps could solve and use it as a conversation starter. As kenchew said you don't have to mention DevOps, you might for example, suggest that Operations be more involved in a project or more test automation to be planned as part of project delivery.

3. If your boss thinks DevOps is just another buzz word then do one of the above but absolutely don't mention DevOps, look at other similar models such as Site Reliability Engineering, Platform Engineering or Continuous Deployment and find out how they could solve the problem.

The key is to focus on understanding what your boss is motivated by, then carve out a small bit of time, money and people to take tangible steps to solving that problem.

I highly recommend the book To Sell Is Human by Daniel H. Pink, fundamentally Daniel Pink talks about how selling something is a very human thing to do, all we need to do is tap into the needs and align our "pitch" by proposing a solution that serves those needs.

Answer 2

You don't.

Despite your enthusiasm about DevOps, non-tech bosses don't really share your fascination with the techie lingo.

First, show your bosses the benefit of a small pilot projects you have done. Collect some useful data points to prove your case. (Found this question that could help: What are some methods to measure the ROI for DevOps?)

Next, tell your bosses you have a project that could bring more benefits but need a small investment. (Try to figure out a project that don't let your bosses fall off the chair. You should have a feel of what this figure is if you have been working with your bosses for a while.)

Once you got the investment, do an excellent job of achieving the objective. Better yet, wildly exceed it!

Now, when finally the bosses ask you "So what did you do that brought us so much benefits?"

This is the time that you proclaim:

"DevOps"

And ask for more investment for your next devops project.

Answer 3

My go-to line of reasoning for people who are unfamiliar (or just mistaken) about the term DevOps boils is down to "delivering business value more frequently". This, in my experience, is something very few managers are able to object to. They get it.

If they say something like "we just need someone to straighten out our devops, probably just a few weeks of work; so there's a limit on how much we're going to invest in devops right now" I just try to explain that's like saying "we don't want our company to deliver too much business value. we just need a bit more, but that's it".

It's just rhetoric, of course, but I find it's effective, much more so than than telling them to read a book about Toyota.

Answer 4

Any business initiative would get a traction if you show its relevance to either topline or bottomline of the organization.

Internal initiatives such as devops can only affect the bottomline. You need to identify the costs of recurring work performed by the individiuals and how automation would reduce that expenditure.

Even though non-techy managers may not understand the difference between choosing chef over puppet, they have some understanding of Industry trends. You can make them aware of the costs of delays due to builds not being available, costs of regression issues and how your approach can reduce those costs. If you can show tangible plan for improvement in bottomline, and if it is better than the other action items on their plate, you would get a go-ahead.

Answer 5

Everything in the previous answers is true, but I think there are some things missing to actually get the approval and commitment from your bosses (BTW: most people only have 1 boss at max ...).

Sooner or later Mr. Murphy will come along (= Anything that can go wrong, will go wrong, and it shall go wrong when it shouldn't go wrong). And at that point some boss(es) will want to get answers to questions like this one:

What happened when and why, and which authorized user actually approved it ... upfront?

And at that point you'll get the real ROI from DevOps-practices you'll have in place ... And/or all of a sudden get all sorts of huge budget approvals to implement what you seem to be looking for.

Even if it would take too long for Murphy to come by, your company might also run into requirements such as what Richard described in the question "What processes or tools enable Segregation of Duties when engineers both deploy and run code?" (those kind of requirements scare CxOs ...).

But, if you ever have to introduce "DevOps" to somebody who is new to it, it may help them to "warn" them upfront like "OK, so you want to start DevOps practices, great! But be aware that it is like switching to another religion ..."