Mike: Hey everyone, this is Mike, and I’m really excited to have Gene Kim here with me today. As many of you know, he’s one of the leading minds in DevOps and he’s contributed tons of research that we all end up putting into practice at our organizations. He leads DevOps Enterprise Summit and, of course, he’s the author of The Phoenix Project. So, Gene, it’s really an honor to have you on the show. Thanks for joining me today.
Gene: Hey, Mike. Delighted to be here with you. And it was just terrific being onsite at Compuware in Detroit with Dr. Mik Kersten in January. That was a, that was an incredible experience and I can’t tell you just how much I learned. It was awesome.
View this post on Instagram
As always, we had to show our guests the #compuwarecorp data center, where we’ve removed most of our servers and now use primarily to house two @ibm z14 mainframes running mission-critical workloads, the rest in the #cloud. . Thanks for joining us, Gene Kim and Mik Kersten! . Learn about our Two-platform IT story at Compuware.com/2platform. . #devops #digitaltransformation #agile #devops #technology #tech #business #digital #transformation #progress #detroit #modern #datacenter
Compuware CEO Chris O’Malley showing Compuware’s modern data center to Tasktop CEO Dr. Mik Kersten and DevOps pioneer Gene Kim
Mike: Well, that’s awesome to hear. And, you know, we loved having you guys too, especially because we’ve been evangelizing DevOps throughout our organization for I think four or five years now, so, a lot of our employees know who you are, and I think a lot of our listeners might know who you are as well. But I’m interested in hearing how you became so fascinated with DevOps in the first place and really what led you to become one of the leading pioneers in this space?
Gene: Oh, great question. Well, I’ve been studying high performing technology organizations since 1999, so that’s a journey that started for me back when I was the CTO and technical founder of a company called a Tripwire in the information security and compliance space. And so I was there for 13 years. I left in 2010. But I’m so grateful because it really was there where I got to study these amazing organizations that were doing dev and ops and security differently than everybody else sometime around 2004 to 2005.
I think what made me so receptive to the DevOps movement when I was introduced to it in 2010 was the fact that so many of our organizations, we’re stuck in this downward spiral. And it doesn’t matter whether in Dev, QA, Ops, security. Without doing things like DevOps suggests, we see horrendous outcomes, not just in our functional silo, but ultimately we fail the organizations that we serve.
And so, I went to the first DevOps Days in Mountain View. I was invited by my good friend John Willis and Damon Edwards. And that was when I met Patrick Debois. And I met this crazy group of people who were talking about doing things in a radically different way, really founded on Lean principles. And it was even within the first 15 minutes, I had the feeling I might have just found my tribe. And so, that’s how I got sucked into the DevOps movement.
Gene: And I tried to integrate as many of those learnings into this book I was writing at the time, The Phoenix Project. So, that was something I was working on fulltime from 2010 to 2013. And so, it has just been a delight that for so many people The Phoenix Project is one of the banners they raise as an example of how to get other people onboard to find other like-minded thinkers.
The first half of the book is really designed to illicit the problems that the absence of DevOps causes, just all the things that go wrong across all our functional silos that ultimately harm the organizations that we serve. Because achievement of almost every goal of every organization these days requires technology. So, it’s a great time to be in the game. With all this talk about digital disruption and so forth, it’s really ups the stakes and validates the contribution that technology organizations can be and should be making for their organizations.
Mike: And speaking of The Phoenix Project, in fact, that was one of the first books that we basically disseminated across Compuware when we were going through the initial phases of our transformation. And I think that was actually a key component to making sure the entire company got on the same page and understood where we were coming from and where we needed to go. So, it was a big help to us, and I would recommend that other organizations also read that. I know it’s definitely been a hit for companies that have made the transformation like Compuware has.
Gene: Actually, one of the things that I would want everyone to know is that Chris O’Malley made a huge impression on so many of us when he did the Fireside Chat with me at the DevOps Enterprise Summit in October of 2018, and I bring that up for two reasons:
But Chris’s response to me was the exact opposite. He said Finance, accountants, order administration, people in the back office, they need to understand how the business works. How does a software company actually operate? Where does value come from? And so, The Phoenix Project was a way to make sure they understood the work that technologists do every day is how the company creates value for the customers. So, I just thought that was delightful beyond words.
Mike: And it’s so true. I wonder if that is part of how DevOps—or, I guess technology in general, but seeing as we’re speaking about DevOps—is that part of how it has evolved. Where when you first started researching it and observing it all those years ago, was it really technologist-focused and now it’s sort of wrapping in all of these other organizations across the company? How has it evolved? How is it working?
Gene: Yeah, that’s a great question. I think in the early days—well, without a doubt it was a very classic Dev versus Ops. A set of those stories, the most famous ones, were actually about the release management team, who are kind of stuck in the middle between the developers running the code and the people on the other side of the brick wall. It was just flung over the brick wall. And so, that’s where a lot of the deployment automation stories—Chef, Puppet, Ansible, Salt—those are really the tools and technologies that kind of came out of that decades-long struggle.
I guess the question becomes why the struggle happened during deployments, and I think it’s because a deployment is sometimes the most complex activity that you have in a technology organization because you require work from so many different people across the value stream.
And so you can actually go a year, maybe even years, without having those parts actually talk to each other. But during a deployment, especially if it’s under pressure, you’re having to do that, and it has to work under conditions of incredible uncertainty, incredible time constraints, constraints of every type. And I think over the years, we thought that that problem has been solved. I don’t want to say solved for everybody, but I think the patterns of how we solve that are well known in deployment automation, automated testing, continuous build, continuous testing, continuous deployment, proactive telemetry—spanning across all those functions.
I think one of the things I’ve learned in the DevOps Enterprise Summit, where we study how large complex organizations are adopting DevOps principles and patterns and sharing how they solve these problems, what problems still remain a—it’s clear to me that one of the conclusions is that increasingly, the obstacles are not now between the classic Dev and Ops part of the value stream.
Increasingly, it is between technology and the business; the constraints are on product owners, information security and compliance, the project management and the funding models.
Those increasingly don’t sound like technology problems, but they very much are.
Increasingly, they sound very much like problems that must be a co-owned by business leadership as well. And so, one of our goals for the past many years has been to advise them some, have experienced reports shared, not just by technology leaders but technology leaders onstage with their business counterparts.
And the reason why Dr. Mik Kersten joined me for the visit to Compuware in Detroit was that he wrote a book called Project to Product, and we had so many questions for Chris O’Malley that came as a result of the Fireside Chat session. I was so delighted that we were able to do part two of that. Chris has some incredible insights to share on that.
Mike: You know, that gets to my next question. I spoke with Mik recently—and that episode is live now—and he had some really great things to talk about since that visit that you guys made to Compuware. And I’m wondering if there’s anything specific that you took away from that visit. I know you already had done the Fireside Chat with Chris at a DOES and a lot came out of that, and you mentioned that this was sort of like a round two for you. Was there anything new or anything that you guys were able to elaborate on and kind of get a better understanding from?
Gene: Yeah, so thank you for helping make that video. I can’t wait to be able to post that. I think the goal of that interview was that it really encapsulates so much of what we learned early in the day from Chris. I would say there are three big ones that just had a huge impression on me.
I wanted to ask why that was so important. Chris was very articulate and adamant that the goal was to be able to show that the transformation could be cost-neutral, that he wasn’t going to the board within the first quarters of him being CEO and asking for more money. That was just fantastic to hear.
But an aha moment I had was, I wondered how it must have felt for that CIO at that time to hear that the empire, the complex estate that he or she had built up over a decade, was now going to be dismantled. And I have a lot of sympathy for how that must feel and the emotions you must go through to finally move you to understand that this is actually, it was the right thing for the business. So that was certainly one fantastic takeaway.
The technology leader who might say to the emptying of the data center, “Over my dead body,” that’s not going to be the leader who’s going to be focused on what the customer wants. I loved when Chris O’malley said, “If the customer won’t pay us for it, get rid of it.”
That focus on the customer translates just as much to the data center, just as much to every functional areas of business, including as we discussed, finance, accounting, order administration and so forth. We need to know about what we’re trying to provide for the customer and how are we going to do that.
That sounds very obvious and yet I can see very clearly how technology leaders need to be able to at least boil it down to that so that they know how to allocate cycles towards either future development, technical debt reduction, risk reduction or features.
Mike: That last one’s a really great point. You know, in particular, Compuware’s customers are massive enterprises. Compuware, we’re not massive—we’re a large software company, but we’re not as big as a lot of our customers. For them, things are a lot slower-moving and in a lot of cases it’s harder to scale things, it’s harder to shift and be agile.
What are your thoughts on how you scale DevOps, or how it scales differently at a large established enterprise, in particular those running systems of record like the mainframe?
Gene: I think for one, we should know that it is possible, regardless of technology, and I think Compuware is a great example. Another great example in my mind is CSG, the largest bill printing company in the U.S. Scott Prugh has spoken at the DevOps Enterprise Summit for now five years in a row.
And there have been examples like Walmart, where they’re doing genuinely transformative things, and our friends at IBM are also doing equally transformative things in all areas of their software business, including the mainframe. All the proof points coming from the mainframe community and the vendors, they’re showing you that this is possible. I think the first thing we need to do is negate the objection that that’s not possible. We know it is through existence proofs.
I think in the ideal, we would all want the zealous support and the tone to be set from the very top, from the CEO of the company. I think the unfortunate fact is that most organizations will never have that, not today. And I think that’s why it’s so important for me and so many people on the program committees that we show how business and technology leaders work together to achieve goals, so they can ladder up and eventually convince the person at the top that the work that we’re doing is important. Given that we don’t have that, these things are the work of rebels and the motivated rebellion working together to overthrow an ancient, powerful and sometimes unjust order.
And I think that’s really what the DevOps enterprise community is all about. It’s technology leaders recognizing that things are far from ideal, that we can do far better. And they have the bravery and the awareness of the business mission and the passion to work in a different way and to have the ability to inspire their teams and people around them and recognize individuals, to create teams that have great technical practices with great architectures to achieve the mission orders of magnitude better than what was being done before.
I’m so pleased that over five years, we’ve had over I think what was 250 plus the case studies across almost every industry vertical showing how these things are happening. And nearly half of the people who have presented at the DevOps Enterprise Summit over the past five years have been promoted, many more than once. So, to me, this is just an indication that they’re being recognized by their organizations as people who are creating value and being elevated to create more value.
I think that’s how, in large organizations, these things happen. And hopefully what is just in small pockets eventually becomes the way the average organization works and then soon most of the organizations work.
Mike: Awesome. Thanks for all of that powerful insight. And, you know, I think a lot of people are probably wondering, because you have so much great insight to share, if you’re working on anything new that we can all be looking forward to.
Gene: Well, I’m certainly working on the DevOps Enterprise Summit for 2019, that’s coming up in London in June and Las Vegas in October. And Chris O’Malley will almost certainly be a part of both of those if nothing disastrous happens.
And I’m just starting to publicly talk about a book that will be coming out later this year called The Unicorn project. It’s essentially The Phoenix Project retold, but from the perspective of Development and architecture. So, it really is an attempt to do justice to all the stories being told within the DevOps enterprise community of all the heroes, things they have had to do and all the treacherous things they had to face in order to change the way that technology was done at some of the most recognized brands in almost every industry vertical.
In my mind, I sort of think of it as a novel about rebellion. Sort of a combination between Hogan’s Heroes, The A Team and the movie Brazil. And so that should be coming out I think November 2019.
Mike: Okay, awesome. Well, I’m definitely looking forward to reading that and I’m sure we’ll get copies for everyone at Compuware just like we did with The Phoenix Project. Thanks so much for sharing all that insight. It’s been awesome chatting with you.
Gene: Likewise. Thank you again.