How Hearst built its DevOps organization: A 4-step process

Hearst, a holding company with hundreds of individual businesses, hired me to build a DevOps group within those organizations. Over my four years with the company, my journey has taken me beyond that: I have helped create a broad DevOps community across all the businesses.

As the vice president of DevOps, I found that we had an existing community of leaders, but the engineering team did not. So rather than just focusing on transformational change, I thought that if we could build a foundational community across all these different businesses, we would not only break down the barriers among the teams but also address the barriers among the organizations themselves—and that would be incredibly powerful.

My talk at DevOps Enterprise Summit this year centers on the approach I used to accomplish this. My framework both encompasses my method and is straightforward to implement. Here's my four-step process, which may seem easy on the surface but requires deep commitment and passion to be successful.

How to Build a DevOps Toolchain That Scales

1. Discover the culture

Each one of the businesses is run autonomously, so each time I went into a business, it would be a fresh start. That meant that all the effort and hard work I put in for one business I had to expend all over again for the next one. While this could have been viewed as a barrier, I embraced it as an opportunity.

I had to navigate the waters of two types of culture. There was the macro-culture—the bigger culture that the business leaders wanted the world to see and wanted to instill throughout the organization. And there were micro-cultures within the teams—operations, development, product management, etc.

[ See more: DevOps Enterprise Summit 2018 Las Vegas ]

These cultures overlapped in places, but if I was going to produce transformational change and understand which teams were going to be affected by that, I had to understand the different cultures and how I was going to contextually shift among them quickly.

There is a reason for this focus: Cultures have an impact on decision making. And understanding whether the cultural grain was going with or against my changes could help me prepare for either alignment or resistance.

One way I did that was by building trust with the various departments. For example, I sat with engineers so I could understand what their day-to-day life was like.

I didn't want someone trying to tell me about it; I wanted to be immersed in part of their lives.

Having a technical background allowed us to have a common language and connection. Sitting with the engineers, I was able to jump in and help them troubleshoot problems. In one case, we were looking to tune the alerting system to reduce alert fatigue. It was a classic case of "we don’t have enough time to solve this problem."

I told the engineers to put me on the on-call rotation so that I could troubleshoot issues with them, even at 3am. By doing that I was able to build up trust with the engineers and truly be part of their culture.

2. Discover the person

Discovering the person is really about identifying drivers, incentives, and fears. Once you have a handle on the culture, you can start to understand the individuals.

Most organizations have key people that others turn to for advice and support. These people don’t have to be managers; in fact, often they're not. Start with these people, since they're likely to influence the team culture.

Begin by trying to understand what drives the individuals. Typically, humans are driven by a combination of extrinsic and intrinsic rewards. You need to identify what makes up this combination. But knowing what drives a person is only half the equation for influencing change; you must also understand how the organization creates incentives for each individual.

You're trying to find out whether there's cognitive dissonance between the incentives and the drivers, because if the incentives are diametrically opposed to your change initiative, you're likely to face opposition. That’s why business leaders need both to say that they support the change and explain why it’s important.

And that message needs to be backed up, not just with words in an email or an all-hands meeting, but with incentives as well. For example, placing a target on automating testing or deployment as part of an individual's review makes it clear that the business values the action, and it can be measured. This helps to incentivize the person to embrace the change while making expectations clear and achievable.

The last part of this step is understanding what it is about the change that frightens people. The fear can be loss of control—that's especially true for middle management—but it can also be the fear of losing credibility.

The biggest fear is the fear of losing one's identity.  For instance, by asking a person to move off an application that's been the focus of her work and expertise for a number of years and with which she self-identifies, you're endangering her identity at work. And that could feed into a fear of obsolescence or even a fear of getting fired.

You're trying to create a safe environment that allays fears and allows risk. This is less challenging when you know what drives a person, how that person is incentivized, and what her key fears are.

3. Discover the value

This is the most important aspect. If you do all the other things and you provide no value at the end, it's not sustainable. You run the risk of wasting people's time.

The business world sees value very differently than do technical staff. Engineers may see value in removing barriers that block their objectives; this would allow them to work on interesting challenges. Alternatively, the business may see value as driving revenue, reducing costs, and improving customer satisfaction.

Derive a list of the top five things that business leaders would love to see in the coming year that would meet their definition of value. Then ask the engineers the top five things they would love to change that would do the same for them.

Then compare those two lists; they almost never cross, because the things the engineers want to change are very tactical, and the things the business wants to change are very strategic. But most of the time the changes at the tactical level will result in business value; it just needs to be communicated in a way that leadership can consume.

For instance, suppose that an engineer or frontline manager says he wants to automate something and it's going to require a little bit of investment up front. Then that person goes to leadership explaining what he wants to do and outlining all the amazing technical things that can be accomplished by this change.

However, the business executives hear a different message because they're listening for their definition of value. Therefore, helping engineers format their value proposition in a way that shows the business value helps to align both parties.

That goes the other way with the business as well; the contact point there is more often product management. And this is where DevOps comes in more heavily; if you approach DevOps as a collaboration between product management and development, each one has a voice. This transparency means that when a decision is made, all parties are confident that it's aligned with the overall vision and direction of the individual teams and the company.

[If] you approach DevOps as a collaboration between product management and development, each one has a voice.

4. Combine, then influence

Finally, take all of the information that you have learned and use it to influence the change that you want to see in the organization. Remember, you can change a process or tool quickly, but you can influence a culture only over time. The shifts you wish to see happen slowly, so be patient. Large changes in culture or behaviors that you pass down as mandates are often not long-lasting.

Remember to set appropriate expectations with leadership and update them frequently. As with the software you create, it’s never really "done." You're constantly adding, manipulating, changing, and enhancing your application—and you must do the same with your DevOps initiatives. 

Just like the software you create, it’s never really "done." 

In the end, you want to get the strongest understanding possible of the culture, environment, people, and perceived real value. Using that information, you can create a realistic timeline and level of effort to achieve a systemic and effective change plan. Influence the culture to ensure that it is one that is conducive to the changes both short and long term.

For more on how to build your DevOps organization, see my presentation at DevOps Enterprise Summit in Las Vegas, which runs October 22–24, 2018. TechBeacon readers can get $300 off registration using code DEVOPS300.

Topics: DevOps