Exploring DevOps with Gene Kim, Author and Researcher
Alignment between IT and business is a core issue facing virtually every CIO.
Watch on YouTube
46:46 
Alignment between IT and business is a core issue facing virtually every CIO. Different perspectives, constraints, and goals can present obstacles to the business gaining the highest value from IT.
Author, researcher, and company founder, Gene Kim, is on the forefront of DevOps, an approach that brings development and operations together in one seamless flow. This episode explores DevOps with the background, suggestions, and practical advice you can use.
Michael:
(00:03) DevOps. We hear this term amongst CIOs and IT people and you hear a lot of prominent people talking about DevOps, and yet what is DevOps? What’s the background? What does it actually mean?
(00:22) So today on episode number 127, I will be speaking with Gene Kim, who is an author, a company founder and one of the central figures in the DevOps movement. I’m Michael Krigsman and welcome to CXOTalk. Gene.
Gene:
(00:44)Thank you so much Michael, it’s been a long time since we’ve done something like this. It is great to see you again.
Michael:
(00:49) It is great to talk with you. We’ve known each other for a long time, and we’ve presented together and Gene, welcome to CXOTalk.
Gene:
(00:57) I’m delighted to be here, and by the way I’m so sad that Vala can’t be here. I even have his book. I found his book right next on my desk so I wanted to show that to him.
Michael:
(01:05) I know, Vala and we’ll hopefully see you on Friday Vala for our next show. So, Gene give us a sense of your professional background. Let’s start there to set some context.
Gene:
(01:19) Yeah, I’ve spent about 16 years studying high performing technology organizations and these were also innovations that had the best development performance development, the best operational stability and reliability, as well as the best (unclear) and security compliant. So our goal was always to understand how these remarkable organizations made there (integrated?) transformation so that the rest of us could replicate their amazing outcomes.
(01:44)So one of the biggest surprises is in my journey is that it took me straight into the heart of the DevOps movement, which I think it is so urgent and important because it really is a transformation of how we do work, very much replicating how manufacturing was transformed through the application of lean principle in the 1980s. So with no doubt in my mind that’s how to work with technology now is changing and 10 years from now we’ll look back and say it transformed, and so how we went from here to there I think is what the DevOps movement is all about.
Michael:
(02:12) So you were Chief Technology Officer and one of the founders of a company called Tripwire and then you started IT Revolution Press and you wrote a book. So tell us about your book The Phoenix Project.
Gene:
(02:25)Yeah, so The Phoenix Project is based on one of my favorite books it’s called The goal by Dr. Eliyahu M.Goldratt. And so that was written in the 1980s and it’s now integrated almost into every mainstream MBA curriculum and it’s surprised me because it’s a novel.
(02:43)It’s a novel about a plant manager who has to fix his cost and (output?) issues in 90 days otherwise they shut the plant down. So this novel is you see the problems that were part of almost every manufacturing plant around the planet and you see the transformation through the eyes of the person who was undertaking this transformation. And so when I read that book, my goodness 18, 20 years ago, you know there was no doubt in my mind that the lessons in the book were relevant to any leader in technology.
(03:11)And so, for over a decade it’s been an aspiration to write the goal for the IT context, very much as a technology leader, who is I think occupies the same space in our economy as manufacturing did 30 years ago.
(03:25)So that’s what The Phoenix Projectis, I’ll call it a homage to The Goal, about problems that almost every technology leader has around project (due date?) performance, about operational stability and reliability and especially in the age of security breaches you know, how to maintain the adequate security for prospects and clients to protect data, applications and the goals of the organization.
Michael:
(03:51) Gene, I remember when you were writing that book, and we had lots of conversations about IT failures and how DevOps can prevent IT failures and the communication issues between IT and the business. And so DevOps has something to do with all of that. So give us a context and overview of DevOps.
Gene:
(04:21)Yeah, so I think both a passion that you and I have is around the taxonomy and the causes of large project failures and technology failures. And I think you know, we can almost characterize what contributes to project failures.
(04:37)I think one of the large characteristics is thatthe (quest?) to fail tends to take a long time. You know,multiple year project right and obviously take a long time, talking about a lot of money, right and often and then as you get you know into the project execution, one of the things you often see is all the testing put at the end of the project. And so when testing periods end, often that’s when the timelines are already so compressed there’s no time to even fix the issues that are uncovered during the testing process. And then that’s not the end of the project right. The project is only creating value for our customers when it’s actually operating in production. And so then we get to the next step, which is actually the deployment, the release of the software in the production environment.
(05:18)And you know in my mind, if you look at some of the largest project failures, often they’ve ended in fury catastrophes, you know I’m thinking about the Toys’R’us deployed in 1999, you know Amazon 2001, you know LinkedIn 2009, you know the recent US Healthcare.gov you know deployment some years ago. And so if we look at one of the common causes and contributingfactors behind those type of deployment areas of significant catastrophes usually because that they’ve been only deploying only at the end of the project.
(05:53)So what DevOps represents is almost the exact opposite. Organizations are doing ten or even thousands of deployments per day, without causing chaos and disruption to the environment or let alone to our customers and you’re achieving world class reliability, stability and security, which is something that we didn’t think possible five years ago. And in my mind it is so heartening to see these DevOps principles and practices being adopted.
(06:18)Not just by organizations Like Amazon, FC, Google, Netflix. But increasingly it’s organizations like you know Capital One, GE finance, Raytheon, Nordstrom, Target, Macy’s. You know large companies or organizations that have been around for decades or even over a century.
(06:42) We had all of these great speakers at a conference called DevOps Enterprize Conference and one of the actually by far the most popular talk was given by Mark Schwartz the CEO of the US Citizenship and Immigration Services now part of the US (homeland?) security
Michael:
(06:57) One of our guests on CXOTalk infact.
Gene:
(06:59) One of my favorite episodes by the way. So you know I think it’s so exciting to see how the way we do work is being transformed. Also another exemplar is the US Patent and Trademark office, you know another guest on your show.So I think DevOps is not just for technologists it is relevant for any leaders, not just technology leaders but business leaders as well.
Michael:
(07:20) So DevOps you have the developer part and you have the operations part. So maybe split these out and explain what DevOps actually is.
Gene:
(07:31) Yeah, absolutely, so I think to be precise you know I think DevOps represents is a set of principles, that is the emergence of patterns that result in you know, very fast flow work from Dev, though test into operations while preserving world class reliability, stability, and security.
(07:55) And so these are not only does it create fast flow and reliability, it creates this safe system of work that allows small teams to quickly independently develop tests and safely deploy the code to customers. And this also allows us to maximize and develop productivity.
(08:12)Soin the eyes of a developer I think how DevOps changes our work is that developers are working in close to a production like environment you know, in their daily work. So instead of testing our code in a production like environment only during the production release one year after you wrote the code, you’re going to be running it in production ideally on the same day that you wrote it.
(08:35) You know, for operations it means that instead of doing work that comes out of ticketing machines, instead of being only involved at the last stage of the project, we are helping create the automation required to increase develop the productivity, to make these environments in demand, to allow automation that helps developers be productive. And what this all means is the organization can achieve its goals, whether it’s around delivering new features to the customer. Whether it’s being reliable and stable and secure to protect organization commitments and passing audits. So I think it really does change how we do work, whether in Dev, test, operations and security.
Michael:
(09:16) But I’m still confused though because is DevOps an ‘it’ you know, a thing, is it a philosophy of life. Because what you’re describing which is work in relatively short cycles produce concrete results quickly that everybody can see and then share it. It sounds like just sort of the ‘common sense’ in the way people are working today with some type of agile or irritative development. So what is DevOps?
Gene:
(09:53) Yeah I think the DevOps movement has I think tried to stay away from being very prescriptive, but I would say DevOps encompasses all the cultural norm, it’s the processes, the procedures, it’s the cultural norms, it’s the technical practices. All of those things right, in combination of these results in outcomes.
(10:17)I mean I guess another way to say it is I think from my perspective, I don’t care so much about the practices and procedures I care about the outcomes, right.we know that high performance deploy 30 times more frequently than the non-high performers. It can do production deployment in minutes not months. They have a change success rate when they deploy into production that’s twice as high and thy are 12 times faster to restore issues when things go wrong.
(10:44) So I would say DevOps is all of those practices that allow us to do incredible things that we didn’t even think possible five years ago. You know, do work more quickly, while being more reliable and stable.
(10:54) And so over the past few years we’ve done a lot of benchmarking to understand what are the behaviors and practices that you know, best predict performance, and there are about seven things that we found that were prerequisites to high performance.
(11:08)One was operations using version control – so I think by the way most of us were trained. Version control was for developers or maybe development teams, and what we found in our research was that everybody in the values team must be using version controls, especially operations because that’s where the most amount of variants occurs.
(11:27)You know, we found that also required was automated testing. In other words, we have to be able to test whatever we put into version control, so that we have confidence that we’re going to have good outcomes when you actually deploy into production, as opposed to only testing at the end of the project and having armies of people execute you know the test plans that were encoded in the word docs.
(11:49) You know, we need co-active monitoring in production environments, so that when something goes wrong, we find out first before our customers do, right. so that we can detect issues and correct them quickly.
(12:00) We need high trust cultures – and by the way, this is something that can only come from leadership, is to set the cultural norms that are high trust where we actively seek information, and we encourage bridging between teams. So it’s not Dev, Ops, security at each other throats, instead they all share a common goal of making development productive, being productive and secure, and that we treat failures as causes of something of genuine enquiry. We don’t create a witch-hunt trying to find who made a mistake. Instead we’re trying to create organizational learning so that we can prevent the bad things from happening again, if you can’t prevent that, then at least enable quicker detection and recovery.
(12:39)So these sound like technical practices but I think it’s more than that. It is technical practices, cultural norms that allow organizations to do great things that you know we haven’t seen before.
(12:52) By the way, I love your comment though, is it just ‘common sense’? Yeah, I think it is just common sense, but I think and we all know over the decades is that common sense is rarely common practice, and I think that’s really the goal of devOps.
Michael:
(13:07) So is it a manifesto, so and again, I’m not trying to be difficult Gene. What I’m trying to see how is DevOps communicated? Is there like a manifesto? Is it handed down from father to son and mother to daughter, and CIO to IT person working in the IT department? How is it communicated and how do you get people on the same page.
Gene:
(13:37) Yeah what great question, and these are the questions that I’ve been seeking to help answer. And I think my first passion right now is trying to understand, you know are the exemplars in the DevOps community doing what they do, and how do we accelerate the rate of transformation across all industry verticals, and then how do we increase the success rate when people embark with DevOps. Which makes you know people like Mark Schwartz, like Courtney Kissler at Nordstrom, like Heather Mickman, and Ross Trotman at Target, you know the journey has been undertaken at the US Patent and Trademark Office.
(14:20) You know the goal of the DevOps Enterprise Summit is really to understand and collect experience reports of how these organizations are transforming, what went wrong, what are the biggest problems so that we can increase success rate as we go forward.
(14:35)By the way one of my favorite parts of the DevOps Enterprise summit last year was that I asked every one of the 50 speakers was to end with one slide of the following one of two titles. Here’s what I don’t know how to do or, here’s what I’m looking for help on. What came out was essentially a research roadmap because the top five issues that were being verbalized was one, what are the cultural issues around transition, especially for leaders.
(15:03) Two, is what are the roles and responsibilities, especially for next generation IT operations. Three is everybody wants to go faster, Dev, Ops, the organizations that we serve but the people in security and compliance keep saying no.
(15:21)The most important one was howdo you build automated testing for the likes of applications where we all are often 100% reliant on manual testing. And the fifth is metrics. What metrics can we use to drive our DevOps improvement programs? And so, the entire program for the DevOps Enterprise Summit in October is really organized around trying to answer those questions.
(15:42) And I think doing things like this you know we can help the community of leaders that are pushing DevOps transformations, you know help better achieve their goals and I think we elevate to save practice in the industry.
(15:54) So in affect then and correct me if I’m wrong, DevOps is a well, it’s a set of practices, a philosophy and therefor a set of practices that can take expression in many different ways. But fundamentally, and I don’t know if the term govern – I was going to say governs the interactions between development people, operations people and the business people.
Gene:
(16:30) Yeah absolutely right. I mean and you know it sounds like a platitude. It sounds like a com by ya moment and yet, there’s nothing laughable about culture right, and I actually think Dr. Steven Spear at MIT, he said you know what culture really is a trained responsein the organization of how to response the stimulus, right, and so part of the goal - of part of the responsibility of leadership is to set those cultural norms. And as we know from our common experiences Michael, like when we have leadership that don’t trust each other something like terrible can happen and that happens especially acutely when you have organizations like development and operations, you know where they have almost at times diametrically pathologically opposite goals.
(17:16)You know development motivated by get that feature to market quickly, right and then we can make changes faster than ever. And then on the other hand you have operations who ismeasured on reliability and stability and that leads to the desired outcome of to make no changes ever.
(17:30) And so you take those two diametric opposite goals and you put them next to each other in the org chart, right, terrible things happen. And I think even how we organize ourselves almost to some extent pure against the outcomes, and so DevOps is about organization. It’s about culture, cultural norms, governance, policies, and most importantly how we can get it to work.
Michael:
(17:54) So you know in my past life I studied why IT projects fail, I know it’s a crazy thing but somebody has got to do it. And I probably wrote as much about that topic as probably almost as anybody on this planet. And you have a deep expertise as well, and one of the primary reasons that IT projects, and I think this is true in any type of projects, one of the primary reasons that projects tend not to work is because of disconnects in terms of the goals, the expectation and then the communication right, amongst the various groups. Because these types of projects by their nature cut across multiple groups, multiple departments, very often multiple companies because there’s different organizations involved.
(18:49) So, how does DevOps prevent failures that arise as a result of these types of miscommunications and expectation and alignment issues.
Gene:
(19:02) Yeah, I think a great question there, so I think here are some concrete examples of how I think DevOps embodies the notion of shared goals. You know and they all sound contrarian and certainly you know controversial, but one of them is this pattern where developers who are (pages? 19:24), right, this notion that- Werner Vogels, the CTO of Amazon he said, if you built it you must run it. Right, and so maybe if we soften that a little bit and saying you know if you helped build it you must help run it.
(19:36) I think this is the opposite of what we see in most organizations where developers write code and then the operation people will deploy it and run it and then get woken up at 2 AM.
(19:45) I think there is a quote from Patrick Lightbody, he is the head of product management, New Relic. He said, ‘we found that when we woke up developers at 2 AM defects got fixed faster than ever’. And I love that quote because it really does show you know, without that shared incentive for creating things that are stable, predictable, and reliable in operations, often we end up with you know these pathologically bad outcomes where you know we just throw stuff over the wall, right and operations must live with it, and (is set to accrued technical debt?) And then operation drowns in untimed work and is unable to actually fulfil its commitments to the organization.
(20:24) You know, I think another example is you know just like in manufacturing there is this movement called design for manufacturing and you know the breakthrough was is that they found that often the industrial engineers were designing parts in such a way that made them very prone to be misconnected in production or it was easy to over tighten screws, or putting things on backwards. And so the design pattern was you know let’s make these things impossible to misassemble. You know the part could be wildly symmetrical, it would be impossible to over tighten.
(21:00)And so the equivalent in our space is that you design for operation, so that you have resilience built in to how we architect the application, and we actually do make it impossible to misconfigure. We actually test and break things in production so that we have practice fixing things when things go wrong so that you know we know how to handle things that would be catastrophic for another organisation (and this is another part of our daily work?).
(21:27)So you know, I think these are examples of behaviors and a set of structures that create wildly different outcomes that we would see in a typical failed IT platform. And, it’s not just for Amazon and Google. This is for organizations like the US Citizenship and Immigration Services. It’s for Macy’s it’s for you know, real organizations that have been doing real great things for you know for decades.
Michael:
(21:54) So when you say design for resilience are you talking about technology, or are you talking about communication among people?
Gene:
(22:04) I think it’s both. You know, one of the famous stories in the DevOps community is the first Amazon cloud failure that happened in 2011, it was April 22nd 2011 and this was when the Amazon’s e-status implemented on and it took them (unclear and became Reddit? 22:22) and almost every Amazon customer with one very curious exception which wasNetflix. And so for weeks, everybody was asking what is Netflix doing differently that caused such a different outcome for them. So the leading theory was you know, it’s obvious you know, Netflix’s is Amazons largest customer. Clearly Amazon gave them a special feature you know that said, do not crash, right, that (a lot of them?) survives the outage.
(22:49)But the real answer was some weeks later in this famous blog post that essentially revealed two critical decisions that they had made very early on, years earlier. One was that we can have no single point of failure risk, of which Amazon was one of them. They said, Amazon will never be there when we need them most. But the second design decision was even more astonishing, they said, in order to survive failure, we are going to have to fail all the time and that’s when they unveiled this thing called Chaos Monkey.
(23:21) So, Chaos Monkey of course is this now famous piece of code that they ran daily, and it randomly kills production servers, and it randomly kills processes you know in production you know every day in the cloud. So, you can imagine you know, once they start running this they become very good at surviving outages.
(23:44)And so, I think is it technology, yes. But is it a startling cultural norm that would be considered crazy for most organizations. And I think that to the answer is yes. I think you know that we all know that DevOps is here, you know whether it’s five years from now or 10 years from now, when that becomes a widely adopted practice.
(24:05) Incidentally one of the things that Mark Swartz talked about at his keynote at the DevOps Enterprise Summit was the fact that they were doing Chaos Monkey like testing before the launch of the new immigration application. Why? Because he wanted to have confidence that you know when they announced and released the functionality to citizens and citizens to be, that it would actually work in production, under production like loads. So you know, I think this is just another great example of how these practices are being adopted you know across every industry vertical.
Michael:
(24:40) We have a question from Alan Berkson, who as what about DevOps and ITIL, and explaining ITIL very quickly for people who don’t know what that is.
Gene:
(24:54) Yeah, ITIL is something that I have a great deal of appreciation for. In fact, a previous book and I had written was around the idea of how do you sort of bootstrap ITIL processes. What ITIL represents is the codification of all the up-and-coming processes that we need within IT operations to get world-class availability, and it was written by the office of OGC, part of the British government.
(25:20)And so it defines how you change management, configuration management, lease management, vendor management and so forth. And you know, I would say that you know, there is no doubt in my mind that you can make them consistent with each other, but I think what is different about DevOps that has (some of the implications) that ITIL is how we do the change management and the configurations management practice as well.
(25:46) In other words I think ITIL works very well when maybe you are doing hundreds of changes or hundreds and thousands of changes per week. But with DevOps we are potentially doing hundreds of thousands of changes per day, and so this means that we can’t have manual configuration management practices. We can’t have a lot of change approval boards we can’t do releases manually.
(26:05) I think what DevOps really does it automates these management process to make it very predictable so that we can do them on demand, and even have them performed by developers, which is something that I think was you know very alien to ITIL and auditors.
(26:20)It means that configurations management is done automatically and how I think we improve changes is done very differently. There was a talk from Salesforce at the DevOps Enterprise Summit that described how once they have automated how they deploy code and configurations into production. They got the change management for to say those can now be considered standard changes. In other words you don’t have to get explicit approval first.
(26:49) However, any manual changes will still require change approvals which would often take you know, days or weeks. So, I think these are patterns showing how organizations are adapting to these different ways are working, recognizing that they reduce risk as opposed to you know the gut reaction of which might be, or my gosh (it isn’t reducing 27: 09) risk.
Michael:
(27:10) So Gene, if an organization wants to adopt DevOps, how do they go about it.
Gene:
(27:16)You know, one of the things that we noticed in the DevOps enterprise Summit was that the book, The Phoenix Project was used often as a way to accelerate the awareness of DevOps. I think the Phoenix Project book is really designed to elicit the reaction of ‘holy cow this is us!’ The organisation being this fictional organisation that’s you know at the brink of exponential failure due to a failed project and having chronic uptime issues, and security and audit issues are really based on 15 years of experience at seeing organizations going through the same cycle over and over again, trapped in this downward spiral.
(27:56) We are also working on another book that will come out later this year called the DevOps Cookbook, which is really intended to be the prescriptive companion guide to the Phoenix Project, describing how did the organisation in the Phoenix Project achieve their seemingly miraculous outcomes, and that book is really based on the study of high performers that have gone through transformation.
(28:19) Another way that we are working on helping the community is doing this DevOps Enterprise Summit, and there’s no better way to learn how organizations success form than hearing directly from those leaders why they started the transformation, what problems were they seeking to solve, what did they do about it, and what were their outcomes.
(28:30) And so in October will be hosting the DevOps Enterprise Summit in San Francisco, where we’ll be having 50 species again, focused on the top five problem areas, and I think there is going to be about 1500 people there. And I have got to tell you, there’s no three days where I learn more than the three days from last year, and that’s fully my expectation for this year.
(29:03)Another thing that we sort of started pointing people to is the DevOps (sys) Summit and although I think that these are tended more for the technical crowd, and the fact that this is held at the USPTO Offices in DC, Mark Swartz was one of the keynote speakers. It just shows that this is something that many many technical leaders, leaders of large technology organizations care about enough for them to show up and help frame the why and how and I think that shows how important the DevOps sys events has in DevOps transformations.
Michael:
(29:36) So we’ve spoke about culture, so in a sense and again, correct me if I’m wrong. So in a sense DevOps is one part management philosophy, one part state of being, one part set of understanding of how technical organizations like IT historically tend to work with non-technical organizations like business, and then a set of practices to help these groups work together consistently, based on a set of methods and mechanisms. And ultimately, developing a culture which is an ingrained set of practices we could say, so that this interaction and communication happens automatically and with great consistency.
Gene:
(30:45) That’s a great summary and actually there is one more I would add without looking at the draft of the DevOps Cookbook here that I’ve forgot. There is actually one other element which is architecture. And the reason why this is so interesting is that the way that I was trained you know, 15 years ago was architecture was you know, you delegate a way right and it’s not the job of a leader to care about architecture.
(31:11)The thing with DevOps it’s showing us is that it’s the exact opposite, because architecture is one of the most important things that a leader should be caring about. In other words, what we need to achieve high performance is in architecture that allows small groups to work with autonomy and freedom, and safety without having to coordinate with hundreds or even thousands of other developers every time they want to deploy into production.
(31:30)So I think the legacy of so many organizations is that everything is so tightly coupled together, that every time we want to push out a small change we have to coordinate with you know hundreds of other teams.
(31:50) And if we look at the way that organizations like Amazon, Netflix and Google work, you know they have essentially been able to scale and develop the productivity linearly with a number of developers, right which is opposite of the way so many of us were trained. You know with Frederick Brooks taught us in the Mythical Man-Monthand his top generation of leaders was that if you double the number of developers, most likely you will double the testing effort, the integration effort, and ultimately the deployment effort to actually get it in the hands of the customers.
(32:20) And I think what DevOps shows us is under certain conditions, you know we can actually break the Mythical Man-Month and we canatually scale the productivity linearly with the number of developers, and there’s no technical leader who should care about that, right because ultimately this means you know, how can we keep developers productive and ultimately achieve you know the goals of the organization. So, you can’t do that without the right architect.
Michael:
(32:52) So from an IT perspective, what do we actually want from IT and what is the lesson here for IT, and then I’m going to come back and ask you the same thing about the business side, but IT, what do we want from IT and what are the lessons?
Gene:
(33:07) Yeah, I think what we want from technology has always been the same, right. Ultimately, more and more goals of the organization are reliant upon technology. I think 90% of all capital projects have a technology component, and 50% of all capital spending is technology related. So, I think for any business leader to say that, you know technology isn’t important to us, technology can be (safely?) outsourced you know to another organisation with different organizational goals. You know, I think it’s a fallacy.
(33:40)So, by the way it’s not just about executing projects. It’s about a lot of in-services reliably so that they’re available and that they are also secure to safeguard customer data and ultimately, organizational outcomes.
(33:57) I think what’s changed, so I think that’s been the same right, 30 years ago 40 years ago, those goals are the same. However, I think what has changed is the expectation of time to market. You know I think 30 years ago David Cobcroft, one of the architects who at Netflix who is now at (Value Ventures? 34:16), he made this observation you know 30 years ago back in the end of the mainframe days. You know large major projects would take three years, right and potentially hundreds of millions of dollars. You know, 20 years ago with open platforms they went down to may be a year and tens of millions of dollars. You know, these days it may take tens of thousands of dollars to make in a month.
(34:39) Right, so whether it’s been to develop a mobile app, to deliver data and analytics capabilities, deliver a feature, these days it’s just so easy there’s no capital required. So really it’s true. People want things faster because it’s cheaper and the skill sets that are out there. I think the job of and responsibility of IT leadership is how do we create that organization that can promptly fulfil those commitments so they can actually do tens, hundreds, or even thousands of performance a day, you know and not waiting years but showing concrete results in weeks or months.
Michael:
(35:12) But the business also wants innovation from IT, it’s one of the issues that makes the CIO job just so difficult because you want the CIO and IT to do things better, faster and cheaper, and yet at the same time you also want them to do things new. Help us innovate. Help us push the envelope but do it with fewer resources.
Gene:
(35:40)You know one of the stories that I find most exciting and not startling was a story told by Jason Cox, at Disney at the DevOps Enterprise Summit last year. So his title is Director of Distributed Engineering at Disney, and so in some ways his job looks, you know very traditional and he owns the middleware services, but also runs a service called Embedded Ops.
(36:11)And so the goal of the Embedded Ops is that whenever someone in the line of business says, hey, we want to launch this Disney store. We need 40 terabytes of storage in three weeks, can you help us right, and maybe my cousin Vinny wrote it.
(36:24) You know I think in the old days we might have said you know go (unclear 36:27) and there is no way that you can engage at this late in the process and get what you want from us, right. Instead, his response was, maybe we can help you. So right, and he assigned some engineers to it and they tried to establish is this a 1F to E, 2TE, 3TE, you know, is it one, two, or three engineering project and can we on-board them to you know a capability that they had inside the organization. And so the outcome was that they were able to on-board them onto the service, and give them 40 terabytes of storage, and they were able to launch on time, you know in three weeks.
(34:04)And the way what is so amazing about this story is it helped the business group achieve their goals, they had the capability internally to deliver those technically. They could get them on board safely onto these platforms and the line of business was willing to pay for it.
(37:23) So I think this notion of embedding operation engineers into the line of business, where the get the air cover and the funding happily paid for and achieve things that couldn’t be done before. It’s just amazing, so different than I think the traditional command and control, operation organisation, where we have plans that you know brought seven years and if you’re not part of that plan, you know the business is left stranded.
Michael:
(37:52) You know Gene, I have to say I’m just amazed at the breadth of your knowledge of this topic. I mean it’s just you are, you are a font of wisdom and knowledge. So, if we adopt DevOps then are we going to reduce costs. So if I’m a business person and IT is coming to me and saying we are going to do this new thing, it’s called DevOps, tell me, what does it mean to me. Tell me what it means to the business person?
Gene:
(38:23)You know one of my favorite quotes came from Courtney Kissler, she is the Head of Technology for almost all of the major parts in Nordstrom and she said, our DevOps journey started when we stopped optimizing for cost, and instead started optimizing for speed. Right, and so you know I think for them the journey was like, if we need and Omni channel, we tell presence it’s not just physical stores but it’s e-commerce, mobile etc. right, we can’t be left behind. Right, it is an exponential threat you know to us if we can’t deliver these capabilities to the market in a situation where our average customer age is is getting older and older, right.
(39:04) I mean you chart that curve out far enough right, you know all our customers potentially die, so I love this quote, we have to stop optimizing our technology organizations for cost, and instead optimize for speed.
(39:18) So I think that sort of gets us out of this trap of you know how do we not reduce IT operations budget by 3% and instead let’s have a totally different conversation of what does it take to be able to you know get Omni channel capabilities.
(39:34)And so I think the question is does it make things cheaper? Well, it could but I think more important I think organizations rarely win on you know just cost efficiency, right. I think it’s often these days it’s more and more it’s actually won by innovation and time to market. I think DevOps enables that this idea that we can quickly deliver the functionality to customers. We can experiment with functionality to understand which one actually best fulfils customer goals. Right, and there is a growing school of thought is that says it is by out experimenting the competition that actually enables us to win in the marketplace.
(40:10) So I think it can be about cost, but I think in actuality the caculated decisions that organizations make is that no, we are willing to pay more right, to be able to get to the market faster to one, get in the game and two, when the game.
Michael:
(40:28) Okay Gene, well we have five minutes left but we have a lot to talk about still, so maybe we need to talk quickly. So, I’m a CIO and I’m hearing this and yeah, this is great. But then I go back to the office and what management is telling me is cut the cost. You know, cut the cost. And I go back and I say, well Gene Kim said that businesses win by innovation. What do I do, and they say cut the cost. How do I respond Gene?
Gene:
(41:07) Yeah, I think one of the scenes in the Phoenix Project is you know I think will resonate with most technology leaders which is on the one hand you have business leadership saying, you know we are going to cut costs another 2% this year. And yet on the other hand there is this endless backlog of projects that need to get done.
(41:28) Right, and so if we were running a restaurant and there was a line around the block. In fact it’s not a line around the block, it’s like a line around the entire city, right. And at certain points you know, we have to ask the question at what point do we need to increase the number of you know tables, or maybe increase the number of restaurants to satisfy demand, right.
(41:46) I think what this story really shows us is that what we need out of IT is so great that you know the survival of the organization often depends on it. And so you know I think we need to reframe this question you know, is what you’re doing, is what you’re waiting for so important that you are actually willing to fund it, right. And I think that brings up the next question which is do you have confidence that if we had the funding that would actually achieve those goals.
(42:14) So which brings up the next question which is, you know if we do things the old way in large waterfall projects, right expecting only outcomes at the end where we don’t financially fund testing and integrate that daily work of Dev and operations, you know do we really have confidence that that money is going to get transformed into the desired outcomes, and I think that where we start having a real conversation about you know, do we need to do things differently.
(42:38) And for that I would recommend anybody to go to the videos on the DevOps Enterprise Summit and listen to the stories from technology leaders, telling these amazing stories of how they went from here to there, right. And you know I think it’s those lessons that we are trying to quantify to help technology leaders you know, replicate those transformations.
Michael:
(42:50) So, in our last couple of minutes, your final piece of advice. I’m always an advocate for the CIO, and you know, you know as much more about DevOps than probably anybody alive, so give the CIO advice, just short, pithy advice before we close. What should the CIO do?
Gene:
(43:28)You know I would say there’s two parts. One is you know, we’ve cut all the videos and stories from the DevOps Enterprise Summit and I would say listen to those stories to see if the problems and the solution you know resonate you know with you. And you know I think we’ve done a pretty good job in getting experience reports from every major industry vertical from very recognised organizations with a heritage and legacy of success.
(44:02) I think the second thing is looking at these studies of the benchmarking that we’ve done – and I’ll send all these links to you, but we’ve done a state of DevOps survey that has now spanned 20,000 organizations, and with a real goal of understanding what are the behaviors and practices that lead to high performance and for that matter how they measure high performance. And we measure it by lead time to go from code committed to running it in production, how many times we deploy. You know, what is there change success rate as we go into production and what was the meantime to prepare. And we found seven, eight behaviors that are mandatory for high-performance and see if that resonates with you.
(44:40) I think the combination of those two things should give us confidence to have a more concrete discussion of what’s not working in the status quo, and how do we get to this ideal better state. I don’t care whether we call it DevOps or not, but really DevOps is intended to be the umbrella of the common experience we’ve had as we transform from the old that ways, to a better way that we can actually see you know through our own eyes.
Michael:
(45:02) Well you know we are just about out of time, but I tell you what Gene, if you send me some of those links, I will put them on the CXOTalk show page for this episode which will create a great resources for people.
Gene:
(45:16)Thank you so much.
Michael:
(45:18) Well thank you. So before we leave tell us about your upcoming conference and I want to ask everybody sign up for the CXOTalk newsletter. But Gene, tell us about your conference.
Gene:
(45:30)Absolutely, so it’s going to be held on October 19 to 21. It’s called the DevOps Enterprise Summit you can find more information about it at www.devopsenterprise.io and it will real get a promotion code, just for the CXOTalk listenership for a special offer with a discount code and I’d love to see you all there.
Michael:
(45:48) Fantastic. Well, we have been talking with Gene Kim, who is a company founder, he is a DevOps researcher, he is an author. He does a whole lot of things and does them really well. And this has been a true education for CXOTalk, for our listeners on episode 127. Gene, thank you so much for taking the time today.
Gene:
(46:13) Michael congratulations on all the great work that you’ve done recently, and congratulations on episode number 127.
Michael:
(46:20) Everybody thank you so much for watching and on Friday we are going to be speaking with the Chief Marketing Officer for HCL Technologies, which is one of the largest Indian outsourcing firms on the face of the planet. You’ve been watching CXOTalk, thank you so much and Gene Kim our guest thank you. Bye bye everybody.
Amazon www.amazon.com
CapitalOne: www.capitalone.com
DevOps Enterprise Summit: www.devopsenterprise.io
Disney: www.disney.com
GE Finance: www.gecapital.com
Google: www.google.com
IT Revolution Press: www.itrevolution.com
Macy’s: www.macys.com
Netflix: www.netflix.com
New Relic: www.newrelic.com
Nordstrom: www.nordstrom.com
Raytheon: www.raytheon.com
Target: www.target.com
The Goal: A Process of Ongoing Improvement, Dr. Eliyahu M. Goldratt: http://www.amazon.com/Goal-Process-Ongoing-Improvement-ebook/dp/B002LHRM2O/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1439545925&sr=1-1&keywords=The+goal
The Phoenix Project: http://www.amazon.com/The-Phoenix-Project-Helping-Business-ebook/dp/B00AZRBLHO
Tripwire: www.tripwire.com
USCIS: www.uscis.gov
USPTO: www.uspto.gov