When it comes to enterprise security, bad habits, shortcuts, and oversights can have the power to do major, irreparable damage to a company.
Gene Kim on the critical role CIOs play in the success or failure of DevOps
Since the release of his first co-authored book, “The Phoenix Project,” Gene Kim has dedicated the past three years to understanding what makes companies that are successful with DevOps different. In particular, he's been interested in how large, complex organizations are implementing DevOps principles and practices to become as productive as the likes of Google, Netflix and Amazon.
His learnings, as highlighted by nearly 50 case studies in the new release, “The DevOps Handbook,” underscored the importance of the CIO role in fostering the ideal environment for DevOps to thrive. We caught up with Kim to learn more.
The Enterprisers Project (TEP): Why is the CIO so critical to the success or failure of a DevOps transformation?
Kim: Leaders have a very critical role in DevOps transformations that they cannot delegate away. They’re responsible for the architecture, the technical practices being used in the organization, and setting the cultural norms. Only leaders can do this.
The shape of the org chart is not what predicts performance. It’s really how teams interact with each other. Ron van Kemenade, CIO of ING Bank, spoke about this at DevOps Enterprise London. He said, “The org chart looked the same back in 2011 as it does now. What’s different is how teams are led, and how we describe the role of team leader.”
TEP: So how can CIOs organize their teams to encourage more interaction?
Kim: One thing CIOs always ask is how do I design my organization differently than before. Instead of putting all the DBAs in one place, all the storage engineers in another place, network engineers in another place, InfoSec in another place, etc—how does DevOps change how I organize my teams? I'd say there are a few classic archetypes.
Functional orientation is very much all central services. You organize by expertise. Leaders often do this when they want to optimize the cost or optimize for expertise. In a United States Naval aircraft carrier, they’ll put all the reactor people in one place, aviation in another place, etc. Often to escalate issues, you have to go up three or four levels of management before they even have someone in common in the reporting chain.
On the opposite side, you have market-driven teams. That’s the notion of small, cross-functional teams that can independently deliver value to the customer without having to rely on other people. For instance, it'd be sales, marketing, engineering, and support all in one team. When we think about Amazon or Netflix, that’s market orientation. Those teams are self-sufficient. They deliver features as well as support their own service.
TEP: Is there a middle ground leaders should aim for?
Kim: There’s a matrix model, where ops engineers are embedded into the lines of business. Jason Cox, director of systems engineering at The Walt Disney Company, recently said he has 50 to 100 ops engineers that he embeds into the lines of business and into the dev teams to encourage them to be as productive as if they were at a Google or an Amazon. How great is that? Their priority comes from the team. They don’t have to open up tickets. They don’t have to prioritize a bunch of other projects. They are there to help the team. How much does that change the culture, when basically, everyone is working toward one goal and you don’t have to worry about other concerns?
It makes me think of something John Allspaw, CTO at Etsy, said that I’ll just never forget. He said, “Suppose you have two teams. One is just developers, and the other team is developers with an ops person.” He said, “I would bet on the second team every time, because you have to have someone who can ask questions like, ‘What kind of workload is this? Is this I/O-intensive, CPU-intensive? What kind of database do we need to build? What kind of database should we select? Do we have one of these already?’”
What this says to me is when you have genuinely shared goals between dev and ops, you really do get fabulously better outcomes.
TEP: What else can leaders do to set their DevOps organizations up for success?
Kim: There's a quote the “DevOps Handbook” from Steve Farley, VP of IT at Nationwide Insurance. He said, “We have 5,000 technology professionals, and since 2011 we have been committed to creating a culture of learning. Part of that is something we call ‘Teaching Thursday,’ where each week we create time for our associates to learn. For two hours, each associate is expected to learn something. If they can’t learn anything, teach something.”
It really moved me to hear someone in the highest levels of leadership reinforce the norm that the most important thing you can do for the organization is to learn. Because the reality is, we all need that commitment to innovation in order to win in the marketplace — we have to outlearn the competition. Every technology leader should be talking like that. The job of leaders is to create the conditions so that people — especially those closest to the work — can experiment and learn. This is so contrary to the way managers have been trained for the last century — the command-and-control model. The dynamic, continuous learning model takes a high level of commitment and a lot of trust that doing it this way is actually going to pay off in the end.
TEP: What does the future hold for DevOps?
Kim: The DevOps movement has barely begun. Despite how much we hear about, it’s barely started. IDC says there are eight million developers and eight million ops people on the planet. I would say five percent or less are actually using DevOps principles and practices. We know that the high performers are two to three orders of magnitude more productive. They have higher employee satisfaction. They have lower rates of burnout. They’re creating better organizational performance. So the mission at hand is how do we elevate the state of the practice for the entire industry. We have 95 percent more to go.
What's rewarding for me is that we have 48 case studies in the “DevOps Handbook” and nearly 100 talks at the DevOps Enterprise Summit. There is a weight of evidence out there that not only is it possible, but DevOps creates amazing benefits for organizations. I hope these stories make it safer and easier for other to follow in their footsteps.