If DevOps is, at a really basic level, about getting different teams to work together, then you could say that DevOps is a discipline that promotes empathy. It’s an interesting idea, and one that’s explored in Viktor Farcic’s book The DevOps Paradox.
What’s particularly significant about the notion of empathy existing inside DevOps is that it could help us to focus on exactly what we’re trying to achieve by employing it. In turn, this could help us develop or evolve the way we actually do DevOps – so, instead of worrying about a new toolchain, or new platform purchases, we could, perhaps, just explore ways of getting people to simply understand what their respective needs are.
However, in the DevOps Paradox there are a number of different insights on empathy in DevOps and what it means not just for the field itself, but also its place in a modern business. Let’s take a look at some DevOps experts thoughts on empathy and DevOps.
“Empathy helps developers put the user at the center of what they do”
Jeff Sussna (@jeffsussna) is an IT consultant and coach that helps organizations to design, build and deliver products quickly.
“There’s a lot of confusion and anxiety about [empathy’s] meaning, and a lot of people tend to misunderstand it. Sometimes people think empathy means wallowing in someone else’s pain. In fact, there’s actually a philosopher from Yale University who is now putting out the idea that empathy is actually bad, and that it’s the cause of all of the world’s problems and what we need instead is compassion.
“From my perspective, that represents a misunderstanding of both empathy and compassion, but my favorite is when people say things like, “Sociopaths are really good at empathizing”. My answer to that is, if you have a sociopath in your organization, you have a much bigger problem, and DevOps isn’t going to solve it. At that point, you have an HR problem. What you need to distinguish between is emotional empathy and cognitive empathy, and I use cognitive empathy in the context of DevOps in a very simple way, which is the ability to think about things as if from another’s perspective.
“If you’re a developer and you think, ‘What is the experience of deploying and running my application going to be?’ you’re thinking about it from the perspective of the operations person.
“If you’re an operations person and you’re thinking in terms of, ‘What is the experience going to be when you need to spin up a test server in a matter of hours in order to test a hotfix because all of your testing swim lanes are full of other things, and what does that mean for my process of provisioning servers?’ then you’re thinking about things from the tester’s point of view.
“And so, to me, that’s empathy, and that’s empathizing, which is really at the heart of customer service. It’s at the heart of design thinking, and it’s at the heart of product development. What is it that our customers are trying to accomplish, what help do they need from us, and how can we help them?”
“As soon as you have empathy you can understand why you provide value”
“Empathy is one of the most advanced bricks you can have for building human interaction. If we are able to achieve so many different things—with different people, different opinions, and different cultures—it’s because we, as humans, are capable of having high levels of empathy.
“As soon as you have empathy, you can understand why you provide value. If you don’t, then what’s the point of trying to create value? It will only be from your point of view, and there are over seven billion other people in the world. So, ultimately, we need empathy to understand what we are going to do with our tools.”
“Let’s not wait for culture to change: culture is in the rearview mirror”
As CSO of PraxisFlow, Kevin Behr spends his time working with clients who seek to develop their DevOps process. His 25 years of experience have been driven by a passion for engaging with the complex problems that large IT organizations face, and how we can use DevOps to solve them. You can follow Kevin on Twitter at @kevinbehr.
What do we mean when we talk about empathy in DevOps? We’re saying that we understand what it feels like to do what you’re doing and that I’ll never do that to you again. So, let’s build a system together that will allow us to never be there.
DevOps to me has evolved into a lot of tools because we’re humans, and humans love tools of all kinds. As a species, we’ve defined ourselves by our tools and technologies. And, as a species, we also talk about culture a lot, but, to my mind, culture is a rearview mirror. Culture is just all the things that we’ve done: our organizational disposition.
The way to change culture is to do things differently. Let’s not wait for culture, because culture is in the rearview mirror: it’s the past. If you’re in a transition, then what are you transitioning toward and what does that mean about how you need to act?
The very interesting thing about DevOps is that while frequently, its mission is to create a change in the culture of an organization, this change requires far more than coordination: it also requires pure collaboration, and co-laboring. These can be particularly awkward to achieve given the likelihood that we haven’t worked with the people in an organization before. And it can become intensely awkward, when those people may have already made villains out of each other because they couldn’t get what they wanted. The goal of the DevOps process is to create a new culture, despite these challenges….
….When you manage to introduce empathy to a team, the development and the operations people seem finally to come together. You suddenly hear someone in operations say, ‘Oh, can we do that differently? When you threw that thing at me last time, it gave me a black eye and I had to stay up for four days straight!’ And the developer is like, ‘It did? How did it do that? Next time, if something happens, please call me, I want to come help.’ That empathy of figuring out what went wrong, and working together, is what builds trust.”
“The CFO doesn’t give a shit about empathy”
Chris Riley (@HoardingInfo) is a self-proclaimed bad coder turned editor of Sweetcode.io at fixate.io, a content marketing firm for those who sell to technical audiences. Through this, he’s involved with DevOps, SecOps, big data, machine learning, and blockchain. He’s a member of the DevOps Institute Board of Regents, a position he’s held for over four years.
“…The CFO doesn’t give a shit about empathy, and the person with the money may not care about that at all. The HR department might, but that’s the problem with selling anything. You have to speak their language, and the CFO is going to respond to money. Either you’re saving us money, or you’re making us more money, and I think DevOps is doing both, which is cool. I think what’s nice about that explanation is the fact it doesn’t seem insurmountable. It’s kind of like how Pixar was structured.
“After Steve Jobs started at Pixar, he structured all of the work environments where the idea was to create chance encounters among the employees, so that the graphic designer of one movie would talk to the application developer of another, even when they don’t even have any real reason to interact with each other. The way they did it at Pixar was that, as everybody has to go to the bathroom, they put the bathrooms in a large communal area where these people are going to run into each other—that’s what created that empathy. They understand what each other’s job is. They’re excited about each other’s movies. They’re excited about what they’re working on, and they’re aware of that in everything they do. It’s a really good explanation.”
What do you think? Can DevOps help promote empathy inside engineering teams and across wider businesses? Or is there anything else we should be doing?