We were struggling to get our features out into production. There were lots of defects and firefighting aplenty. All this and the company was but a few months old. What was working here going to be like in a year? We were all staying as late as we could and even working weekends to try and fix issues that would appear, seemingly, from nowhere. It was hell.
Frustrated and tired, I decided to pitch the idea of DevOps to the chief technology officer (CTO). I’d read a little about the DevOps movement and I figured we could benefit from some of the things I’d learned. I mean, I had little choice; things couldn’t go on like this.
In that moment the success of the business (and my sanity!) was quite possibly riding on my ability to fix our problems.
The CTO turned to me with a pensive, somewhat puzzled look and said, “DevOps … I’ve heard that phrase a few times — but I’m not sure what it really means. What does it mean?”.
It’s safe to say my bumbling attempt to justify and explain what the tacit term “DevOps” really means, and critically, why it matters to the business, failed miserably.
I simply didn’t have a strong enough understanding of what DevOps actually is and I definitely wasn’t able to clearly explain it and why we needed it. I could see the problem, but for the life of me I couldn’t articulate the solution. I was tired of working evenings and weekends, and I really wanted the business to succeed. Urgh.
As a programmer, this is a common situation.
And I’m willing to bet you’ve had a similar predicament, too.
It goes a little like this: You make a comment about an improvement, maybe something you read about online, and before you get a chance to catch your breath, it happens.
It’s like you’re on “Dragons’ Den” (or “Shark Tank”) pitching an idea. The lights are all on you and you’ve got one shot: Sell the idea. It’s do, or die.
At this point, it’s too easy to lock up.
Buckling under the pressure, you feel tempted to reach for the best justifications you have in the moment:
“Well … — insert large technology company — do it.”
Or worse: “It’s industry standard.”
But, while these answers seem legitimate, they’re actually non-answers. They’re not logical or strong justifications at all. They don’t show how the solution you have meets the problem and creates a real, valuable result.
But, what is a more compelling option? Well, I’m glad you asked, because that’s what we’re going to talk about today.
So if you’re trapped, running about with your hair on fire and you need some DevOps help, you’re in luck. Because today, I’m going to take you through how to truly understand the DevOps movement, and better still: how to pitch it so that your business will care.
First, we will look at diagnosing whether your business needs DevOps at all. After that we’ll address the way that most people try to explain DevOps and we’ll look at why it ends up falling flat. Lastly, we’ll go through the best way to explain DevOps so that your business will care.
Now, before your hair sizzles off completely, let’s get to it.
How Do Businesses Know If They Need DevOps?
In order to understand whether we need DevOps, we should look at some problems that it addresses.
As a doctor would, we’ll begin to understand the problem (to hopefully prescribe a solution) by first looking at symptoms.
So, what are the symptoms a business suffers when it is in need of DevOps?
- You don’t deploy as often as your business would like.
- Deploying into production is painful and scary.
- You have difficulties syncing your development teams and they step on each other’s toes.
- You don’t have a clear understanding of whether deployed features are “successful” or not.
- Your operations team (frequently) complains or blames developers for production issues and vice versa.
- You spend a lot of time firefighting production issues as opposed to writing new features.
Did I catch you nodding your head to a few of these?
Why were you nodding? Because these statements are ubiquitous. Even to the best companies in the world, and even to companies already practicing DevOps.
Implementing DevOps is like sweeping the floor: it’s not something that a company does once and then it’s done forever. DevOps must be considered continually; as our software adapts as we release more, so too must our understanding, knowledge, and implementation of DevOps.
At this point you might be wondering: Can it really be true that most businesses need some form of DevOps capability?
Yes, and I’ll explain why.
How Not to Explain DevOps
To try and explain DevOps, we might be tempted to approach it from a tools-first perspective: detailing the different tools you can use to implement DevOps: Docker, AWS, Kubernetes, Chef, Puppet, Ansible. This seems appropriate — right?
Not really. But let me explain why.
To understand why this approach is weak at best, let’s take an example.
Imagine you’re on a car forecourt looking to purchase a new car. You need the car to take your kids to school, so what’s important to you is that it’s spacious, has an interior resilient to sticky fingers, and reliable.
The car salesperson comes up to you. They look you up and down and assume you’re a single individual and likely have plenty of disposable cash, so they start showing you a bright red sports car.
“It’s just in, brand new!” they say emphatically. “It has a lightweight chassis, a V-8 engine, and last but not least: leather seats.”
All the while you’re thinking that this salesperson just has not taken the time to really understand your needs. You feel like rolling your eyes — what a waste of time.
When we try to explain DevOps from a tools (or jargon) perspective we’re falling into this same trap: not identifying the problems that the solution is trying to solve. Putting the problem first is at the heart of getting buy-in to a new idea like DevOps.
But if tools are not the best way to explain DevOps, then what is?
The Best Way to Explain DevOps
In order to pitch DevOps, we need to understand what it really is, and why it’s important.
To do this, I’m going to share with you the best definition that I have come across about what DevOps really is:
Most businesses are suffering from a problem known as “chronic conflict.” A chronic conflict occurs when two parts of a business have diametrically opposed goals.
In other words: no matter how hard one part of the business pushes for success, there is another part of the business that ends up pushing back just as hard. What happens as a result is that these competing departments achieve a state of stasis, where no one is going anywhere fast.
For a company seeking growth, and trying to respond aggressively to the market, stasis can be deadly.
Maybe unsurprisingly (given the name DevOps) the two departments that cause the conflict are development and operations.
But, people in business are smart, right? And they wouldn’t let this type of thing happen?
Well, it happens, not because they’re not intelligent, but because they’re not looking at the system as a whole. Let me explain:
When most businesses grow, they have to think about dividing their employees into different teams. A common and (seemingly) logical separation is between development and operations. And this is where the chronic conflict begins to get introduced.
Operations are tasked with keeping the live servers stable and secure, whereas development are tasked with pushing as many changes into production as possible.
As you can imagine, the more development push into production, the greater the perceived instability. So the response from operations? To push back.
What happens over time is usually that the communication between these two departments breaks down. Rather than working together to get valuable features into production, they’re now bickering, arguing, and blaming each other. Everyone has to stay late and work weekends on deployment days, and work is not only a chore, but it is becoming unprofitable.
With changes flowing constantly into production, it’s likely that lots could go wrong. So a better practice (at least on paper) is to slow down production, opting instead to deliver in big batches, possibly once a year, or maybe even less.
But, delivering in this way means that the business is slow to put value in front of the customer.
The solution to this problem: DevOps.
DevOps is proactively bringing together and aligning development and operation onto common goals. And yes, by making use of special tooling and automation.
With DevOps in place, and the operation and development team cooperating, you can achieve a smooth (and calm!) flow of value into production.
Explaining this value to your business is the best way to get them on board with DevOps.
Now, It’s Your Turn to Pitch — The Lights Are On
Hopefully this helps you understand a little more about the DevOps movement and how to pitch it. By explaining the problem — the core chronic conflict — it makes it easy for your business to understand how they could have got themselves into this situation. And importantly, how DevOps will help take them out.
Then, when you’ve achieved this, you should be able to start explaining the tooling and more advanced concepts with their attention captivated. No more late nights and weekends spent on your laptop or hair burnt to your scalp. Now, with the business on board, you can start experimenting with DevOps and paving the way to success.
| Published on Java Code Geeks with permission by Lou Bichard, partner at our JCG program. See the original article here: You’re Selling It Wrong — How to Explain DevOps so Your Business Will Care Opinions expressed by Java Code Geeks contributors are their own. |
