At the heart of DevOps lies conflict

“70% of DevOps is culture, 30% is technology.”

This has become the main mantra in the DevOps world over the last several years. 

But if that’s the case, why do so many of us neglect the 70%? 

I’ve thought about it over time and come to the following realization: Besides culture being more difficult to identify, discuss, and implement, we avoid it because it usually starts with something we try to ignore, something we call Conflict.

Conflict doesn’t always have to be a bad thing. Depending on how it’s handled, it can actually lead to long-term growth and breakthroughs. The problem is that many of us can’t handle it well, either due to a lack of training, awareness or any other reason. Conflict carries a negative connotation so as a result we like to pretend it doesn’t exist. 

But what we miss here is an opportunity, because conflict lies at the very heart of transformations. Seeing as Eficode is a DevOps company, we often discuss the conflicts you might encounter during DevOps transformations and how you can grow from them. 

Dev + Ops

You might have your own definition of DevOps. Whatever yours may be, it likely involves the merging of at least two ways of thinking: Dev plus Ops. 

Dev and Ops have different perspectives and diverging values. Their ideas of how the world works and should work, vary and attract their own kinds of attention. Not to mention, they’re also measured in distinctive ways. When they’re joined together during a DevOps transformation, they’re likely to clash and, before you know it, you have a conflict at hand. 

What might these conflicts look like, you ask? 

Problem 1

Developers are evaluated by how much change they introduce. The more new features they’ve coded, the better. On the other hand, Ops are measured by how stable and fast the platform is. And what is at direct odds with that? New features and change. 

Whereas developers are praised for dishing out change, we blame Ops when something breaks down (often as a result of a Dev change). In fact, the only time Ops might hear a single compliment is on Sysadmin Appreciation Day. 

Problem 2

The other problem is that Dev and Ops do have one thing in common: they’re not going anywhere. They work there because they want to. If developers wanted to handle system updates or cared about networking, they would work in Ops. The same goes for Ops; they are there because they want to be there. 

See where I’m going with this? 

Unless you invest in coaching and training, Dev and Ops will always be in conflict with one another. And while DevOps might be the future, that doesn’t make older concepts, such as soft skills, a thing of the past. 

Below, I’ll discuss the complexities of conflict in different areas of software development, such as product management, development teams, security. I’ll also show you how you can address them.

The complexities of conflict

A new world for product management

At first glance, product managers might have it easy in a DevOps transformation. The new way of working might suit them well because they’re no longer expected to deliver fully detailed product ideas.

On the other hand, they might lose some influence within the organization when their product ideas are compared to the real thing during the short feedback loops that come with DevOps. Some product managers might begin to resent this loss and as a result start pushing back. This brings us into yet another conflict. 

I have seen many successful transformations come to a grinding halt because the Head of Product had a few drinks with the CEO, complained about no longer being in charge, and suggested that someone more trustworthy, A.K.A. the Head of Product, should be the one pulling the strings. Don’t let that happen to your transformation.

“Works on my machine”

The Head of Product isn’t the only one who might cause conflict, however. 

As responsibilities shift, it’s no longer about the individual. Instead, the collective goal becomes the priority. Unfortunately, it’s difficult to go from “Well, it works on my machine” to “We share the responsibility for our value stream” without running into some sort of struggle.

Some will hide behind their own idea of “sharing” in order to avoid taking any responsibility at all. Others will argue that “sharing responsibilities” only means that their team members need to change and that they can keep doing whatever they were doing before. The better prepared you are for these small potential clashes, the less likely they’ll erupt into large-scale conflicts.

Security is for everyone

Security and compliance personnel are no longer the Men in Black who show up, interrupt the workday and dictate their will. The new reality asks them to collaborate with engineers to deliver a strong result instead of demanding change. Some security and compliance members might refuse this initially as it requires stepping down from their ivory towers and getting their hands dirty. 

In addition, not all developers are used to owning the security of their code. And sadly, most companies don’t invest the time that’s needed for them to learn how to deal with this. At the end, all you get are disgruntled employees who are unprepared to take on responsibilities they didn’t sign up for. 

If there’s anything to take away from this, it’s that this is an arena that’s ripe for conflict.

Cynical slackers fighting for their existence

Then we get to those who have created a nice niche for themselves, those who reign without lifting a finger. We all know them, we all have them. 

They’re too important to lose because, well, nobody really understands what they do. But that won’t last under a DevOps transformation. Once everything is translated into scripts and code, their daily work becomes transparent to all—suddenly, their cushy spot doesn’t look so cozy. 

These “cynical slackers” know that their way of working is under threat, so don’t be surprised if they start conflict before the transformation even begins.

The indispensables becomes dispensable

A real DevOps transformation will involve a lot of automation, specifically automation to replace existing manual processes. Before the transformation, these manual processes were usually carried out by real people. People that could either have focused on this as a small part of their role, or it could have been their entire job.

Naturally, when someone’s no longer needed, alarm bells start ringing. Not only might someone lose an important task, they might also lose their identities, values, and jobs. Inevitably, conflict will arise when someone has to fight for their role and value within an organization. 

Conflicts come with the territory

After some time, you’ll transform into a fully-fledged DevOps company. You might start to notice that things are running smoother and that your sitreps are getting more and more reliable. But on the downside, you might start to think that conflict is just an everyday part of your business. 

Now, that’s not necessarily untrue, but your reaction will determine whether that conflict turns into growth.

Since DevOps is built on short feedback loops, you need to train your employees to give and receive feedback. For example, once you’ve aligned your teams around value streams, they’ll begin communicating more with different parts of your company. While this is something that team members are happy to do, maybe even excited about, they’ll need to be well-versed in how to interact with experts in other areas. Otherwise, conflicts will grow and fester into an unresolvable wound. 

There’s a high chance that all the conflicts you were able to dodge before will swim to the surface. And that’s exactly why avoiding conflict is not a sustainable solution. It might work in the short term, but as a long-term corporate strategy it fails.

Why transform then?

So, is all of this bad? Should you not go into a DevOps-transformation? Why, au contraire! 

DevOps transformations, like all Agile transformations, shed light on pre-existing problems. Looking the other way won’t make them disappear.

As I wrote in a previous blog post, you can compare this situation to a parent walking through their child's room at night. Imagine a bunch of sharp, pointy toys lying on the floor. If the parent keeps the lights off, they might avoid stepping on one by sheer luck. But that doesn’t make the room any cleaner or prettier. Plus, there’s a high chance they’ll end up with some pointy bits stuck in their feet. Try to see a DevOps transformation as the parent turning on the lights and cleaning up the toys.

The question that remains is this: How do we ease into a DevOps transformation? 

The answer lies in the culture, the 70%.

Anyone undergoing a transformation needs to invest time into getting people on the same page. By creating an implicit and explicit set of rules for everyone, the actual corporate structure will support the harmony of your transformation and the overall happiness of your employees.

Literature shows that as long as you want to operate under this model, you must put energy into building and maintaining that structure and culture. For starters, “higher-ups” should have to adhere to the rules, just like everyone else. Additionally, all offenders should be subject to the same sanctions. This might sound harsh, but your culture depends on it. If those at the top follow their own rules, if offenders are tolerated, and if there’s any discontinuity within the culture, everything you’ve worked hard to build can fall apart.

How to get started on the 70%

Leaving aside the continuous work, how can you start working on the 70%?

One idea would be to provide a workshop that gives people the tools to provide and receive feedback, instructed by someone who knows all the layers of IT. Introducing a good feedback culture will go a long way in reducing conflict, since it’s at the core of our interactions. Feedback can also change if an organization’s structure changes, e.g. during a DevOps transformation. 

My second recommendation would be a workshop on handling conflicts. This might sound easy, but if you take a closer look you’ll realize it’s harder to find. First of all, the market is overrun with useless advice. You might see articles like “Top 10 ways to diffuse all your conflicts. You won’t believe number 7!” Much of what you’ll read won’t even be applicable in day-to-day situations.

At Eficode, we have a workshop on this. Just like our Feedback Workshop, we host it internally and externally for our clients, so you can learn what we teach our teams. 

How to continue the work

In the long run, your 70% will only thrive with a team behind it. Team members will need to be trained and have the required experience. Someone who’s been sitting at the front desk for the past few years won’t be equipped with the right knowledge, only those who’ve been in the field will. 

This team, let's call it the Culture Team, will be tasked with shaping your company, starting with upper and middle management. Who you put there will have a large impact on the rest of your company. Put process-driven people there and you can expect a company built around processes. Put a McKinsey-style consultant there and you will end up with all action and no results. So, choose carefully.

Get this part right and you’ll soon discover that this team could be the backbone of your company. They will challenge all levels starting with the intern all the way to the owner.  

Before all else, however, make sure to devote time into coaching and training your engineering teams. This will drive the results that you need in order to convince management later. And then you’ll see that, yes, conflict is at the heart of DevOps—but having the right company culture, the 70%, will help you use that conflict to drive you forward at spectacular speed.