 was two years ago to the day that I was in New York City. I was in a deli, in Carnegie deli in Manhattan, to be exact. It was cold and it was rainy and everybody seemed to be in a bad mood, or maybe that's just Manhattan. And I realized that driving in Manhattan is not really for the faint of heart or the weak, but they encourage you in New York. If you're ever in New York City, they're very encouraging folks. Several people had already told me that I was number one and that I could go do things to myself that I don't think are technically physically possible. So encouraging, right? I mean they're on your side. I was listening to a gentleman talk to me over a cup of coffee about an opportunity at a company called Hearst, Hearst Business Media to be exact, and he was discussing how these 10 business units that make up HBM were going through transformational journeys, through Lean and DevOps and Agile, and I was supposed to come in and help them along this journey. They're split basically in three verticals. There's the healthcare vertical, there is the transportation vertical, and the smallest of the three is finance. And it's interesting because Hearst invests in these organizations, not just in resources, but also in allowing them to maintain a high degree of autonomy, which means that you have 10 unique, very individual business units that operate like individual organizations. I was highly intrigued and I decided to take the job, so a few weeks later I started, and the first order of business for me was to go out to each of these business units and get to know the engineers to understand how they made software and how their organizations ran. For the most part, as far as DevOps was concerned, you had kind of three camps. You had the folks who had a DevOps team, which is essentially ops rebranded. You had someone who had a DevOps evangelist. This was sort of the internal DevOps Sherpa that was trying to help shepherd the DevOps transformation, but was kind of the only person actually interested in DevOps, beating a lone drum kind of thing, right? And then you had folks that just hadn't really started at all. They'd go into conferences, they had some interest in it, but hadn't figured out, like, what is the first step for us? So I realized, however, that each of those business units all were facing more or less similar challenges, if not the same challenges. They were all incredibly unique, just like everyone else. And so what I decided to do was, instead of just having these BUs communicate with one another at a high level, which they were good at already, so the executives got together of course during budget season, but the engineers never really talked to one another. So I was going to create this sort of broad DevOps community across all 10 business units. So an interesting challenge, so I started thinking, that's me, or it's supposed to be me, I started thinking to myself, like, how am I going to go about doing this? And usually when we go to make decisions, we tend to look at things that have worked for us in the past, right? If it worked for us before, surely it'll work again. But I also recognize that, you know, I have two shortcomings. Well, I actually have a lot of shortcomings, but we'll just focus on two for right now. One of which is I sometimes get so hung up on past experiences that it becomes a bias for myself. I don't allow myself the room or the opportunity to really focus on innovation. Like, how can we do this better this time? My other shortcoming that can sometimes really get in the way is I tend to get wrapped around the axle when technology is involved. I'm an engineer in my heart and soul. I went to Georgia Tech, you know, Double E, and so if there's technology involved, I really want to get involved too. And so I tend to kind of sometimes go overboard. I'll give you an example. So when my son was very young, he was reliant upon a sound machine to sleep. So I came up with what I think is arguably a brilliant idea, to move the sound machine a little farther away from the bed every night, right, to wean him off of this thing. You know, I thought, well, we could attach like an extension cord, move it down the hallway. My wife said at the time, you know, why don't you just turn the volume down a little bit more each night? That's the only, yeah, if you want to do it the easy way, right? But I'm an engineer. Like, that's just not how we roll. So what I really couldn't tell her was I'd already purchased the domain name and had Arduino boxes set up and I bought a Lego train so that I could like graph it and graph it as it moved down the hallway there. So, you know, I could have gone a little overboard in that situation. No one will ever know really for sure. But so knowing these two sort of issues that I can potentially have, I was like, okay, how can I resolve this? So what I decided to do is create a roadmap. And the idea behind this was to use not just my past experiences, but the past experiences of others in our industry. You know, I reached out to thought leaders. You know, as an example, I called up Gene Kim, who's down in Portland, I'm in Seattle, and I've known for many years now. And I said, you know, Gene, this is my idea. What do you think? You know, I'll never forget what he said to me. He said, Polly, how did you get this phone number? And so, and you know, that really stuck with me, right? Because what Gene was trying to say was, you know, you need to have really solid communication skills to be able to really do DevOps well to collaborate. And so I took this roadmap and I went out to the business units. And I talked to the leadership there and I said, Listen, this is what we're going to do. We're going to focus focus on culture and process and we're going to focus on tools and we're going to do it in that order, right? And yes, I understand that that you have very unique challenges and we will focus on those, but we're also going to focus on the broader community. Because really, I think the value here, the real sort of opportunity is to get these business units to communicate the engineers to share. And so I also created a maturity model and the maturity model is essentially used internally for the business unit to kind of gauge where they were on that journey, right? What's their maturation? So I decided to start with something very simplistic. The idea was, okay, let's do something small, something simple. I mean, we're talking about a very large effort with a lot of moving pieces. And then we can build on that. And so I started with with chat, which I didn't invent chat, of course, and neither did Hearst. And prior to this, Hearst had chat, but it was the sort of chat that you're familiar with in an enterprise, right? In other words, link was pushed down to your desktop or laptop, whether you wanted it or not. And it was linked into AD and it was a great tool for you to basically go out and find another individual and have this sort of ad hoc one-on-one conversation. And you could pull, you know, John or Jane in also, but it didn't have a very organic feel. It had a very enterprise feel. And so I decided to take a different tactic, right? Again, thinking back about how would DevOps do this? And so instead, I said, let's create a cause, let's rally people around the cause, and then the tool will shake itself out. So we'll start with culture, then we'll go to process, and the tool will just figure out as we go. And so the cause was pretty simple. Let's just get folks together so we can talk. And we're going to do it in the thousands, so let's try and figure out a process that's going to work. And the benefit here is that we can have knowledge here and help each other out. Ideally, if you're going through a problem, and I've already gone through it, I want to be able to share my experiences. It started out fairly slow. We moved up to about 50 folks fairly rapidly. And the nice thing about this is it's completely opt in. So you can either join us on the journey or not. It's entirely up to you, and that's okay if you decide not to. We created some guidelines or codes of conduct inside. Now, this was done by the community. So the idea was from the very beginning, the community would police itself. There is no police in charge of this. It's ours. And this worked out incredibly well. We ballooned from 50 to well over 1,000. We're on our way to 2,000 people in there now. And there was some concern in the beginning from some managers that people were not going to do their job. They're just going to hang out and chat all day and watch cat videos. By the way, this is an accurate representation of how I play golf. And I think a reasonable response to missing a one foot putt. And so I wasn't worried about that, right? I was actually really worried and concerned that no one was going to use it at all. You know how it is, right? It's another tool I got to keep up with. I've got a full-time job. I don't have time to do this crap. We were both wrong. People did use it, and they used it appropriately. And now we had some fun too. We have some silly channels to have some fun in. But people ended up helping each other very quickly. Now the beginning, it started inside the BU as you'd probably expect, right? You had people talking inside of teams. It was very isolated, very siloed. And we started working to break that apart and get people to communicate across business units. Before long, we saw people between business units coming in and helping each other, you know, in things like outages and incidents, and then the sort of real magic happened. And that's when we saw these self-forming cross-functional teams across business unit boundaries where people were getting together to create innovative solutions. And in some cases actually creating products that could be sold and generate revenue for the business. Now the amazing thing here, as a manager, the amazing thing here is you didn't need a manager, right? People are smart. You hire incredibly intelligent, innovative, creative people. So just get out of their way, just give them the right tools and create a process that everyone can agree on that's inclusive. That's DevOps, right? So this worked amazingly well. So I'm like, all right, mission accomplished. I can sort of just drop the microphone and walk away. Well, not exactly, right? The interesting thing here was, I like to use analogies, and the interesting thing here to me was it was sort of like we were creating a new product together, both literally and figuratively. So I was thinking, this is sort of like creating a DevOps airplane, right? This DevOps transformation was a new type of aircraft we were building in a cross-functional team with very little guidance from management. There's a new type of plane. It could see 300 people. It ran on solar power, something we'd never seen before, so we weren't sure what to expect. And we got a volunteer pilot from some of the engineers. They strapped himself into the cockpit, and we pulled it out onto the runway, pushing the throttle forward. It rumbles down the runway, and he pulls back on the yoke, and the nose lifts up. And we all watch in awe as the plane careens into the trees at the end of the runway in this massive spectacular fireball. And so, luckily the pilot escaped with very little injuries, but something didn't work. Something didn't help that plane slip the surly bonds of gravity, right? What were we missing? Now, I tend to think that these types of things are like puzzles, right? But more like riddles than puzzles. You kind of feel like you have all the moving pieces, but at the same time, we had all the moving pieces, and yet I'm still missing something out of this, right? And so, I kind of think of this sort of joke about an engineer who goes in for a job, and the prospective employer says, well, it says here on your resume that, you know, you're incredibly quick at math. That's very impressive. What's 32 times 47? The engineer without skipping a B goes 36. And the employer goes, that's not even close. And he goes, no, but it was quick. So, the answer was right in front of me, excuse me, but I wasn't seeing it. And I was like, okay, I got to figure this out because I have the roadmap. It's built from solid foundational principles and documents. I had all the artifacts to support this thing, both from myself and from other thought leaders in the industry. I had a maturity model that was well thought out and well groomed, and it failed. So, I went back out to the business units. I went to the leaders and I said, listen, we need to have an open and honest conversation. I knew I could do that with the engineers, but I wasn't sure I could do that with the leadership. It's a different breed, right? And so, I said, I'm gonna be very honest. I'm gonna make myself vulnerable, right? There may be hugging, there could be tears, maybe we do trust falls. I don't know what's gonna happen, but we gotta get to the bottom of this. And I need the root cause of why this plane crashed. Now, the good news is they weren't. They were very open, they were very honest, and I came away from all 10 conversations with essentially two root cause of the crash. Unfortunately, they're both my fault, but that's okay, right? That's actually good because the only person you can control in your life is really yourself. So, I felt pretty good about that, and I came away with basically one. I came in with this roadmap at the beginning of 2015. Everyone loved the roadmap. Everyone said these are great foundational ideas. They all make sense. We absolutely should be doing these things. But I've already budgeted for 2015. All my resources are already allocated, now you came in and dumped this on me. I don't see how I can be successful. Basically, I feel like you're setting me up to fail. Okay, fair enough. Number two, that roadmap is highly prescriptive. Now, it's highly prescriptive from whose perspective, the leaders. Why? Because I created that roadmap with the engineers, and I didn't create it with leadership in the room, right? Myopic again, right? We talked about my shortcomings. I fell victim to them anyway. I got so wrapped up. I love engineers. I'm an engineer. So, I love sitting with engineers, and I love working with engineers. I love being an engineer, and so unfortunately, I forgot that there were other people involved in this transformation. Okay, so in 2016, let's take a whole new approach, right? A fresh new DevOps approach. By the end of 2016, DevOps will smell like a fresh Carolina pine forest, right? And so, the idea here was I'm gonna hire a team, and we're gonna basically do sort of very highly dedicated engagements, almost like a consultancy. And so, I needed three very different skill sets that would complement each other very well. So, I hired Ahern Blythe, Levi Smith, and Alex Alley. And the idea here was that we were going to create this sort of Tiger team. I get now that it's really hard to get these initiatives started. It's not so hard once they're going, but you need some assistance. So, we were gonna do this internally, and we started with creating value stream mapping workshops. So, we would go around to each business unit and get a sense for what they were doing, how they were doing it. You'd create a current state map of your value stream, a future state, and then an actual tactical plan to get there. So, that tangible asset was something leadership wanted. Like, show me where I can get an ROI on this. I need some numbers. Whereas, the engineers were like, show me how I can make my life better day to day. Probably the most valuable thing we did. And I think one of the best kickoff points for any DevOps transformation I've ever seen. I took my maturity model and my roadmap. Those are the actual documents. And I threw those into the trash and went to the business units and said, listen, you guys have all the contextual knowledge of how you do your work. The world you live in, I do not. And it's wrong for me to come in and say I do inadvertently or otherwise. So, let's build it together. Let's make it specialized for your business unit. And let's set it up so that in 2016 we have the budget to do the things that have the biggest business priority in the business technical impact. So, now, mission accomplished, right? So, we take that, you know, version two of the airplanes, all licensed, shiny. We get a new volunteer pilot. She straps herself into the cockpit, rumbles out onto the runway, throttles up and takes off. She pulls back on the stick. The nose lifts up. We see the plane lift into the air and everyone is super excited. It's like we finally think we've got this thing going. It clears the trees at the end of the runway and then settles back into the forest. Another spectacular fireball. Our pilot stumbles out of the forest, hair a little singed, but otherwise okay. So, what went wrong? So, now I'm thinking back, I don't understand. So, I literally have everyone on board. We have all the support and lift we need to get this transformation not only off the ground, but flying. So, I take some time here to try and be introspective. And at the time I was reading a book by Nietzsche. He's a pretty interesting fellow. If you've never read anything he's done. Even if you don't agree with him, it's interesting perspectives. And the book was called The Birth of Tragedy. And in this book, Nietzsche talks about these two diametrically opposed perspectives. On one hand you have the Apollonian. And the Apollonian is really focused on control and order. And on the other side, the antithesis is Dionysium. And so, these folks really say listen, in order to move forward in life, you have to accept chaos. You have to accept there's gonna be some disorder. Now, when I started thinking about how this applied to what I was trying to accomplish, I thought about Apollonian as being sort of like leadership. Leaders love to prognosticate the future. They wanna plan and chart where we're gonna be. And ideally if possible, control it. In some cases they wanna know like five years out, which is a tech, as tech folks we know that's impossible. We don't even know what products we're gonna be creating in five years. On the other hand, Dionysium, I really think more along the lines of engineers. These are the artists, right? These are the folks we give a blank canvas and some basic tools and say, I need a painting of a woman in a pastoral scene and my expectation is the Mona Lisa. Now hopefully you'll iterate to get there. So who's left out? I literally have everyone included in these two perspectives. Now in our case, the person who was left out was the middle manager. And the issue here is that the middle manager has the unenviable task of having to live in both perspectives at the same time. They need to create these artifacts and these consumable products that they can send up in highly tangible form to leaders while simultaneously having to be an evangelist and an inspired leader for folks who are artists. These are very different roles to play. Oftentimes they have to switch very quickly between these roles, between meetings. So that contextual shift is very difficult. And they were the ones that weren't supporting the overall effort. It turns out middle managers have a lot more power than you think. Why? Because they're key influencers in any organization. So I need to understand why we're middle managers not supporting this effort. When everyone else was, even their boss, right? So you have all of the people that report to the middle manager loving it, you have the leaders loving it and yet still they're not on board. So anytime that I really need to understand motives why someone is acting the way they are or making decisions the way they are, I tend to look at three key factors, drivers, fears and incentives. And so incentives for the most part in our organization, like any enterprise organization with 25,000 plus employees are goal based, right? I'm not a huge fan of goals, but I also recognize like the IRS, they're not going away anytime soon and we're just gonna have to live with it. So let's make the best of it. For goals for us, I really focused heavily on reevaluating the business goals. That's where everything starts. That's the origin of your goals. I made sure that the goals that were being brought out by the business were aligned with your team goals, were aligned with DevOps principles, and that we minimized individual goals. So we put a much heavier focus on overall team goals. The idea there was to bring the middle manager in to a more collaborative mindset. And this alignment meant that everyone was working towards the same end game, right? Even the business. For us drivers, you know, you have extrinsic drivers, but really nowadays every business has reasonable comp package. I kind of think of like the carnival, I guess you'd have to be this tall to ride this ride kind of thing. Like if you're not offering decent pay and decent comp packages, I don't see how you can ever expect to get highly qualified top talent. So we didn't really focus heavily on that because after evaluation, all that was sort of a non-starter force, but intrinsic rewards in drivers, that's a totally different thing. That's something we could control and there's a lot of impact you can have here. And so I boiled down intrinsic drivers, basically the three things, right? Who you work with, who you work for, and what you work on. In our case, who you work with, this was less about just the average co-worker of yours as a middle manager, but more about the other middle managers in other business units. Now you remember earlier I talked about how we focused really heavily on getting the engineers together because leadership, executive leadership already communicated? Well, who do we leave out? Right, I left out the middle manager. Again, in my whole reckoning. And so the idea was, let's create a safe, secure environment where middle managers can communicate with other middle managers in other business units without any fear of reprisal or big brother watching me, any of that kind of stuff. And the idea is we really wanna get these problems, these challenges that we have out into the open and so that we can work together to solve them. Not just in the siloed business unit, but across the business units. Next we talked about who you work for. Now this is really where I focused more with leadership. What we didn't want was we didn't want a situation of lip service, right? Where it's like, I empower all of my middle managers. That's an easy thing to say. How do you go about actually doing that? And it's not just saying you get to make the decisions. I think it goes a step further than that. I think it's really more about creating some understandable, reasonable boundaries of innovation and say this is where you can really reach and then let people take some risks. And what you work on is last, and this was really when I went around and talked to all the different folks, it ended up being different than what I thought it was gonna be. I thought it was gonna be, listen, we don't get to work on anything fun. Actually, it turns out, it's like, listen, if you could just get rid of some of this tech debt, my life would be better and it would be more fun. And so we kind of reevaluated how are we communicating what tech debt is to the business because the business was making the decisions. And so what that really entailed was taking that tech debt, the things that you wanted to change and defining the value not in technology but in business value and then selling that up. So it's kind of just knowing your audience. And lastly, we looked at fears. Maybe my fears are not working, I guess. And so fears, in the case of middle management, is really more about this fear of obsolescence, right? If you automate and dev ops me out of a job, where do I go next? It's just gonna keep chasing me down. And this really comes, I thought of it more as like a fear of what I call CPR, a loss of CPR, which is a loss of control, a loss of power, and a loss of resources. And when we go in and we say, listen, we need you to push decision making closer to where the work is actually occurring. So what I call sort of down and outward. That's scary because what happens is the middle manager then has to lose a little bit of control and power through transference. And the way we approach this is listen, let's redefine what value is to the organization. A lot of middle managers say, well, if I have a big budget or I have a lot of people reporting to me, that's value. And if you take any of that away, it diminishes my value. I actually disagree. I think it's quite the opposite. I think it increases your value because in the end, you're not successful by the number of fiefdoms and people that you collect. You're successful based on the products that you produce and how satisfied your customers are. So we put a refocused effort on the customer first, redefining what value meant for the middle and then really supporting that change. This is really hard for some folks. It doesn't happen overnight, certainly, right? We need middle leaders. When I'm talking about these types of changes, this isn't just managing a transformational change. It's leading a transformational change and there's a big difference there. And it's hard and it's scary and it definitely doesn't happen overnight. It takes a lot of time. There is no sort of magic pill that you can take and then in tomorrow, you're a great leader. But it's what we've been doing and it's what we've been focusing on and we've seen an incredible amount of value derived from these changes. Most of them, as you probably already figured out, are cultural in nature. I didn't really mention any tools in here because the tools are sort of interchangeable. It's the easiest thing to rip out and replace. Your process is a little bit harder and that's mainly because people become very attached to the way they do things, right? This entrenched inertia around, that's how we've always done it. Or it's just your favorite process. It's just your way of doing things. And then the culture is the hardest thing to change. I actually don't believe you can change culture. I think you can influence culture by modeling behaviors and trying to drive the behaviors that you wanna see that reinforce the culture. But I think the notion of changing the culture is not actually accurate. So finally, we taxi like this third iteration of the aircraft, this DevOps transformational airplane out onto the runway. By this point, it's understandable and arguably harder to get volunteers to climb up into the cockpit. But we find something, by the way, I think this is a testament to the nature at Hearst, at HBM, and that is that we will accept risk, we'll take chances, and if it doesn't work, we'll just keep trying. And the testament there is more about me saying, hey, I need another volunteer and lots of hands shooting to the air. That's sort of your measure of are you succeeding or not? Are people willing to take risks when things don't work the first two times? So we get the pilot into the cockpit, we pull it out onto the runway, he throttles up, it rumbles down the runway, the nose lifts, the plane lifts, the wheels go up, clear the trees, and the plane is flying. Now actually, the plane is soaring. Now to end that sort of analogy in metaphors is we don't really have a destination in mind. We took off from Seattle and we're just heading east. Dionysian, right? Now we need to control enough of the aircraft through Apollonian perspective so that we don't crash, but we're just gonna head east for now and we're gonna keep iterating and we're gonna fine tune it over time. That's been our approach and it's worked really, really well. I hope that you guys would share with me later. One on one, I'd love to hear your approaches, things that have worked for you. This is a great opportunity for all of us to learn, including myself. So that's it, thank you very much. I hope you have a wonderful rest of your conference.