#127: Exploring DevOps with Gene Kim, Author and Researcher

#127: Exploring DevOps with Gene Kim, Author and Researcher


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?
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. 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. 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. 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. 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. 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 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. 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. 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. 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. 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. 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.
So that’s what The Phoenix Project is, 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. 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. 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.
I think one of the large characteristics is that the (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. 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 contributing factors behind those type of
deployment areas of significant catastrophes usually because that they’ve been only deploying
only at the end of the project. 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. 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. 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 One of our guests on CXOTalk infact. 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. So DevOps you have the developer part and
you have the operations part. So maybe split these out and explain what DevOps actually
is. 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.
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.
So in 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. 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. 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? 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.
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. 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.
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.
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.
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. 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.
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.
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. 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. 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. 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. 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. 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. 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. The most important one was how do 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. 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. 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. 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 response in 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.
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 is measured on reliability and stability and that leads to the desired outcome of to
make no changes ever. 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. 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. So, how does DevOps prevent failures that
arise as a result of these types of miscommunications and expectation and alignment issues. 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?), 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. 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. 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.
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. 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?). 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. So when you say design for resilience are
you talking about technology, or are you talking about communication among people? 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 and almost every Amazon customer with one very curious exception which was
Netflix. 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.
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.
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. 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. 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. 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. 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.
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.
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. 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. 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. 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) risk. So Gene, if an organization wants to adopt
DevOps, how do they go about it. 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.
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. 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. 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.
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. 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. 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. 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. 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.
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-Month and 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. And I think what DevOps shows us is under
certain conditions, you know we can actually break the Mythical Man-Month and we can atually
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. 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? 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. 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.
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?), 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.
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. 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. 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. 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. You know I think in the old days we might
have said you know go 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.
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. 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. 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? 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.
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. 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.
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.
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. 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? 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. 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.
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. 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.
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. 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? 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. 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.
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. 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. Thank you so much. 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. 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. 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. Michael congratulations on all the great work
that you’ve done recently, and congratulations on episode number 127. 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.

Posts created 34275

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top