The State of DevOps in 2018 (Part 2)

The State of DevOps in 2018 — With Nathen Harvey (Part 2)

Meeting Nathen Harvey in person was a personal DevOps moment for me. As I mentioned in Part 1 of our interview, I am lazy. I didn’t want to sit in L.A. traffic for an hour to meet some guy who I could easily talk to on the phone. But I rarely get to meet my clients or interview subjects in person, so curiosity (and realizing that traffic from Hollywood to Pasadena wouldn’t be bad at 11:30 AM) caused me to conquer my inertia. When I admitted this to Nathen, he replied, “That’s very DevOps of you to meet face-to-face. That’s one of the things we need more of” to make DevOps truly work in organizations.

In this post, I’m going to run through four steps Nathen recommends to bring a DevOps mindset to their organizations. If you’re a “Dev” or an “Ops,” you’ve probably heard some (or all) of these before, but they bear repeating, especially if you haven’t yet gotten others on board.

1. Embrace failure—and help change how leadership addresses failure.

Embracing failure is a foundational principle of DevOps, going back to its early days. “We treat failure as a learning opportunity,” Nathen says. “The thing we know about our technology is it’s going to fail, and we can’t prevent those failures. So, we have to learn to adapt to those failures. We have to learn how to leverage them and figure out what goes back into the system.”

That directive in itself is straightforward. Unfortunately, most organizations, especially larger enterprises, have a history of seeking out scapegoats when something breaks. “An executive comes into a post-mortem or incident review and they want to know who to blame and who to fire,” Nathen says. “Getting them to move away from this mindset is a real struggle for a lot of organizations.”

But scapegoating rarely solves the underlying problems that lead to failures. You can see this in many of the data breaches that have been reported over the last several years. Think back to the Target data breach in 2013:

On both days the big-box store’s malware detection software, made by FireEye, sent an alert to Target’s security monitors in Bangalore, India, who then contacted Target’s security team in Minneapolis. But for some reason, they apparently didn’t respond to either alert.

Although I don’t know for sure what happened to that security team, I’m betting some heads rolled for the same reason the team failed to respond to these alerts: lack of communication. Maybe the company improved other aspects of their security practices, but unless they dramatically improved communication among the many departments involved, they risk another security breach in the future. As Nathen asserts, it’s much better to face these failures head-on and seek to repair the underlying problems together.

2. Bring everyone into the conversation—and make that conversation an ongoing priority.

I’ve written for a lot of security vendors over the last few years, and one of the main points I discuss, regardless of the type of solution these vendors sell, is the need for visibility. If your organization doesn’t break down its silos, you won’t be able to detect an attack, let alone stop it.

Nathen seemed to appreciate my security example. “It’s another example of how DevOps is moving outside of just Dev and Ops. Because security is part of that conversation. Finance is part of that conversation. Marketing is part of that conversation,” he explains.

But how does an organization make sure that everyone understands what’s being discussed? Too often, departments describe the same problem in such dissimilar ways that they seem to be speaking different languages.

Nathen says that people within a department, particularly those in technical ones, need to keep two things in mind when discussing an issue with other departments:

1. You need to be intentional and explicit when discussing issues with people in other groups, particularly non-technical ones. “You have to remember there are other people in the room and [not to] use stupid, made-up words. Oftentimes, we’ll make up a word and then use it for three disparate things,” he says.

2. Ideally, any formal meeting you have should not be the first time you talk to that person. “Go find someone in marketing and take them to lunch. Ask them what they do every day. Like, ‘What keeps you up? What do you love and hate about the work you do?’ And then share with them, so that we start to gain that understanding together. That doesn’t happen in meetings. It happens in [less formal situations], like here at the cafe,” Nathen says.

One thing we weren’t able to discuss in detail is whether the onus is on core DevOps people to reach out to all of these other departments within an organization. From my perspective, it seems unfair that that would be the case—that ideally, everyone should want to reach out to one another. But because DevOps pros know the technologies that help or hinder these other departments, they’re the ones who will most likely have to initiate the conversation. And this may be a good thing because let’s face it, the stereotype of the engineer who can’t relate to people, only systems, isn’t accurate and mostly leads to silos and misunderstandings that prevent DevOps success in the first place. If such a stereotype were true, I wouldn’t have had this conversation with Nathen—and frankly, DevOps probably would never have developed as a movement to begin with.

3. Practice failure and conversation with intention.

Of course, the first two steps requires practice, just like anything else. And not scattershot practice. It needs to be practiced with intention, so that you reshape your habits and your perspective.

Let’s look at each step separately:

Conversation: These conversations with people across departments should take place on a regular basis. As they take place, listen intently to their pain points, and show them how you can help alleviate them. In some cases, you may invite people from other departments to witness what you do and make clear they’re witnesses rather than participants.

As Nathen explains:

What we want you to do is keep your mouth shut and watch how this process works. Once you learn how this process works, then next time, we’ll want to hear your input. It’s not that we don’t want to hear your input. We just want to make sure you understand the framework.

The need to “keep your mouth shut” works both ways, and it shouldn’t be interpreted as rudeness. In fact, it’s absolutely necessary to move forward. That urge to respond—which all of us have—implies judgment rather than collaboration.

Eric Barker, author of Barking Up the Wrong Tree: The Surprising Science Behind Why Everything You Know About Success Is (Mostly) Wrong, describes it this way:

[Former FBI agent] Robin Dreeke’s number one piece of advice: “Seek someone else’s thoughts and opinions without judging them.”

Stop thinking about what you’re going to say next and focus on what they’re saying right now.

Listening isn’t shutting up. Listening is having nothing to say. There’s a difference there. If you just shut up, it means you’re still thinking about what you wanted to say. You’re just not saying it. The second that I think about my response, I’m half listening to what you’re saying because I’m really waiting for the opportunity to tell you my story.

What you do is this: as soon as you have that story or thought that you want to share, toss it. Consciously tell yourself, “I am not going to say it.”

All you should be doing is asking yourself, “What idea or thought that they mentioned do I find fascinating and want to explore?”

Ask questions. Listen. But don’t judge. Nobody — including you — likes to feel judged.

Practicing Failure: In an ideal world, we would learn quickly from any failure and anticipate anything in the future to prevent that failure from taking place again. However, we rarely find ourselves in identical situations, and even in situations that are very similar, we often will fail in some other way. So, while anticipation would be great, “It’s also important and good to practice how we respond to failures as human beings. That’s the thing that can fundamentally change your approach to it,” says Nathen.

That’s why breaking down silos are so important, Nathen says. “When you break down those walls and invite other people in, you are in essence inviting them to talk about how something broke. How there was a failure. That’s really hard to do, but you have to do that,” which is why you need to be intentional in practicing these things, he explains.

4. Automate more, not less.

Despite all the emphasis on people and process, tooling plays an integral role in DevOps success. The more you can automate, the less possibility for human error, particularly in defined and repeatable tasks.

Strangely, however, people don’t trust automation. You see that a lot with security professionals, who worry that if they didn’t do a given task themselves, there’s a risk that task hasn’t been done safely. “Like that means writing code, and that’s not what I do. There’s change involved, and human emotions become the real blockers,” Nathen adds.

Nathen points out that as these professionals see the value in automating things like security checks and remediation, they then are freed to become advisors to development and infrastructure teams to help them build more secure applications. And then all of these groups form a partnership that works together to serve the customer—which is the ultimate goal of any good business. “When they get over the hump, they’re like, ‘Why did I wait so long to start the journey? It kind of sucked as we were climbing that mountain, but now that I’m up here, this is awesome. I can’t imagine going back to the old way,” says Nathen.

Conclusion: How DevOps Approach Can Transform the Enterprise

Ultimately, however, technologies themselves don’t drive DevOps, if only because they can become obsolete over time. But the processes developed around this intersection between people and technologies can lead to businesses running faster and more efficiently and safely. “The movement around continuous delivery and integration and the tools used to do that—those are the technologies that are helping us succeed,” Nathen says.

Nathen cites his experience using Chef in the days before Chef hired him as its vice president of community development as an example of how DevOps can transform the enterprise. The reason he started using Chef in the first place was that it made his life easier and as a result, made his customers’ lives better.

He explains:

A lot of people in the DevOps movement take a leap of faith. They may be a sys admin whose work it is to put servers into a data center or manage them in the cloud. But their *job* really is to make their customers happy—and the way they do that is by making sure the technology runs smoothly and is nimble, and they can update it fast and keep it secure. And that doesn’t mean only becoming a better engineer but getting more connected with your business and your customers. Their job is to make that customer successful and happy, and make my business successful and drive those outcomes, right?

I would say so.

About the Author

Robyn Weisman

Robyn lives in Los Angeles and is the founder and principal of WriteTech Content– a content marketing firm for companies in the enterprise tech space. Robyn has written about the enterprise since 2000, both as a reporter and copywriter.