DevOps in the team environment

Viktor Farcic: I often see the same thing happening, with people saying, "This is my job, but that's not my job." With that being said, how do you prevent this type of thinking if different managers are giving different teams different objectives, especially ones that are not necessarily in line with the global vision because everybody thinks only, as you said, of their part of the puzzle?

Jeff Sussna: The way that I coach teams to do it is by getting them to think of each other as the customers, in the same way that the company thinks about people who pay the money to their customers. The network team has customers, and it's really funny because in DevOps, we engage in this little bit of magical thinking where we're all thinking, "Well, one key component of DevOps is the cloud." The cloud solves a bunch of problems, and I agree with that, but if you think about an AWS, Azure, or Google Cloud Platform, it's the ultimate...

Empathy in DevOps

You've both written and spoken a lot about empathy. I'm not sure whether you coined the term EmpathyOps, but can you elaborate on what you mean by empathy?

Jeff Sussna: There's a lot of confusion and anxiety about its 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...

The big DevOps guy versus the little DevOps guy

Jeff Sussna: I'm surprised at how common they are, regardless of the size of the company. For example, pretty much every single client that I've had, regardless of size, has compliance issues.

Maybe they're a start-up, but they're a healthcare start-up, which means they have to deal with HIPAA (The Health Insurance and Accountability Act of 1996); or maybe they process credit cards, which means they have to deal with PCI (Payment Card Industry); or they provide services to the Federal Government, which means they have to comply with FedRAMP, which is as draconian as any of the other compliance rule sets as you can find. Issues about audits, and segregation duties and access control; all of those things are common across my clients, regardless of their size.

"Pretty much every single client that I've had, regardless of size, has compliance issues."

—Jeff Sussna

I see the challenges between...

Changing the culture around DevOps

Viktor Farcic: When you try to change the culture, do you have a plan? I remember someone told me that you could not really predict a complex system; the only thing you can do is poke it and see what comes out.

Jeff Sussna: You're correct in thinking that you can have techniques that you use to introduce people to your system, and then you have to relate to what happens when they interact with those techniques. Everybody is a little bit different.

I teach, and when I do a coaching engagement, I always start with, depending on the size of the organization, anywhere from a week to a month spending a lot of time doing an embedded observation to really understand who and where they are. From there, I start introducing new techniques; whether it be stand-ups, continuous integration, or automated server provisioning, it really doesn't matter.

Then the fun starts when we're introducing Kanban. We're thinking, "That's straightforward...

Agile versus DevOps

Jeff Sussna: DevOps completes the Agile equation. Agile talks a lot about delivering value and working code, but the problem is that by itself, it doesn't actually deliver anything. Instead, Agile kind of stops when you have code that's been written and tested, which nobody can use, so it doesn't do anybody any good.

The reason for that is Agile grew up in the product age when you would take your code, put it on a CD, and send it to your customer, who were the ones responsible for actually deploying and operating it. Those days are pretty much gone now, so that development and operations elements are really part of the same equation. Agile can't actually deliver the value unless that code can be deployed, and that deployment environment can be operated, and the problems can be fixed, including where new code can be deployed, and so on.

I don't think development without operations is meaningful anymore; and again, to clarify, when I say "operations...