Interview with John Willis of Docker

John Willis discusses the human factor of DevOps

Hartmut Schlosser
John Willis

High-performing organizations seem to have one common pattern: they put a high value on human capital. JAXenter editor Hartmut Schlosser talked to John Willis, Director of Ecosystem Development at Docker, Inc about how to turn human capital into high performance organizational capital.

JAXenter: Hello, we are here at the DevOps Con in Munich. With me is John Willis from Docker, great to have you here. John, you had a great keynote right now, about let’s say the Human factor of DevOps,  where you gathered a lot of interesting topics about DevOps culture. Perhaps you could shed a little bit more light on what the culture of things really means?

John Willis:  One of the things I thought about a lot at the end of last year was: how do we elevate this message up to higher levels in organization? And I started thinking, how do you describe DevOps to a CEO of a large corporation? That became kind of the theme where I wanted to build my presentation in 2016 around.

One thing we learned is that the high performing organizations that use the things we call DevOps seem to have this one common pattern.  That is, they put a high value on human capital.

Now, a lot of people in the USA won’t use the word human capital, it sounds very HR. But I don’t care. At the end of the day, this is the idea that is the way we get high performing organizations, because the title is turning human capital into high performing organizational capital. The message has to be clear that it’s about how are people working together within an organization. The tools are interesting and important, but not as important as how we figure out how to get people to collaborate.

Andrew Schaefer says that there is no talent shortage. What he’s saying is that Silicon Valley is scrambling to hire the next most-important-person.He’s saying that your talent is inside your company. What you’re missing is that you’re not a learning how to be a “learning organization”. That’s where human capital is. You can get one plus one to equal five if you can figure out how to get people to collaborate and trust, to create a high trust culture with visibility and transparency.

Then, the tools that you get are important,  but nowhere near as important as getting people to collaborate in a high trust collaborative environment. That’s where high performing organizations make break away advances from the people who don’t behave that way.

JAXenter: Now is the question is how to get there, how to become a DevOps company? Where do you start?

John Willis: That was the biggest part to me. In my presentation, I tried to sell you on the idea that it’s about human capital. There are companies that do this. And then, the second part is, in the large enterprises, we have 50 years of body of a work in certain categories that aren’t called DevOps. They isomorphically map and directly underpin what we call DevOps.

DevOps is a three-legged stool. It’s lean, learning organization, and safety culture.

First, being lean. We can learn so much from lean. By the way, if you’re a manufacturing company and you’re trying to sell DevOps,  there is a chance there is a whole body of people that completely understand what lean means and all principles there. All you have to do is to say “we already do this” to your executives.

The other one is a learning organization.  There is a good chance there is a bunch of people that either follow John Carter or Peter Senge’s “The Fifth Discipline”. So, it won’t be hard to find the people is that say, “Oh, is that what DevOps is? Oh, DevOps is lean? Oh, DevOps is learning organization?”

And third is, if you are an engineering culture, you probably already have the third leg: resilience engineering, human factors, body of work of what you are doing there. And there is incredible work there on how people think about systems thinking, how they think about blamelessness culture, and blameless postmortems.

SEE MORE: Demystifying DevOps: What are the values that constitute DevOps culture?

The whole resilience engineering people, like Cindy Decker, Dr. Cook, Dr. Wood. These are all people who get brought in when a plane crashes. They don’t  look for what the pilot did wrong, they look for the systematic view of all the things that contributed to the failure.

In a hospital, what happens when a baby dies? It is even more important in a hospital to create a systematic view, just to get to people to talk about what went wrong. Nobody wants to admit it. The nurse doesn’t want to admit that she has flipped the table and the wrong needle was used, right? These people that focus on how do you get information to find out how to make sure that it doesn’t happen again. The key is a psychological safety, which basically is trying to set a blamelessness environment.

Cindy Decker has a book called “Just Culture”.  It says we have to get away from the balance of “you broke it, you go to jail”. It’s a system view and it’s just fascinating.

The meta point here is, we can call it DevOps and that’s great. But what we really need to attack the resistance, is to say: “You already know about this stuff. There is somebody in here doing lean, there is somebody some form of resilience engineering, and there’s somebody in here studying learning organization.”

JAXenter: We are talking about the transformational process there. Do you try to think about DevOps as a grassroots movement or do you think its also necessary to have also some kind of road map process coming from management? Or is it a balance between the two?

John Willis: You know you need both. You need groundswell. Groundswell can work. You need to be really tricky and clever. That’s where my hack is, to commit some: “Hey, by the way, you are doing it, the lean, let me show you how it is lean”.

But in the end, just like any major transformation organization, you have to have executive buy-in and support. Until you get the executives to see the value…

Now a lot of executives today of some really big companies that I talked to are making really good strides in what we call DevOps. Even today just given a lot of trust in DevOps. So, I talk to the companies that are doing amazing things and I ask them: “What is your executive staff think about this?” They say: “You know what? They trust us, they are giving us the leeway to do this, but we still haven’t gotten to the point where we can show you know like the Toyota vs. General Motors story.”

SEE MORE: DevOps playbook: A practical guide for implementing DevOps

Target (the large US retailer) has probably put more investment in DevOps then any other company I have seen. They have a 15,000 sqft DevOps dojo in their headquarters allocated for the practice of DevOps, for companies to come in. I have talked to them, they still don’t have that “Aha, Target is beating everybody else because they are doing DevOps”.

We are still early. The lucky ones have executive buy-in that says, “You know what, I believe what your doing is your right. I can see incremental change. But, I still do want to see the Harvard Business Review version of our story”.

So, it’s a tricky game.

JAXenter: We talked a lot about culture. But there is obviously also technological aspects, e.g. microservices, container technologies, new world of cloud platform. Do you think a connection between technological things has an impact on cultural change?

John Willis: There is an interesting divergence, right? There is a different level of abstraction. I will argue all the time that if the cultural aspect isn’t right, then everything reasonable is going to fail at some point unless you get really lucky.

Then, at the far end from there is just tools. I think selection of tools is important. I love things like Chef. I love Docker. I always use Jenkins and Git for this. The point is, I think there is a balance of the right tools. You got the culture and the tools: Perfect tools, everything perfect and you got it just right, bad culture, done!

And there is a middle layer, which is really important. Which is this kind of meta-ideas. Cloud native and microservice architectures in the sense of a meta way change my business. I have to redevelop my software to be very component or bounded in that infrastructure microservices and fit the SOA version too.

That’s important and more important than the tools, less important than the culture. That convergence. One of the most beautiful convergences that we have seen. we just got lucky! We got 10 years of domain driven, SOA, Eric Erins, twelve-factor apps, microservices altogether.

SEE MORE: Microservices and DevOps accelerate API-first movement

At the same time, this adoption of Windows containers to Docker to production grade. All the sudden, probably in 2015, they both meet and both on parallel threads independent of each other… Oh my goodness, microservices and containers, they work great! We kind of got lucky as a industry. Cloud native as a methodology for decoupling, and how do you deal with network computing, that kind of thing.

This is a really interesting convergence that just happens to be at the same time between containers, cloud-native things like frameworks, and microservices architectures, this all plays really well.

Again, more important in tools, less important in culture.

JAXenter: Thank you really much for your great insights.


This transcript has been edited for clarity.


go on, you know you wanna

Hartmut Schlosser
Hartmut Schlosser is an editor for JAXenter and a specialist in Java Enterprise-Technologies, Eclipse & ALM, Android and Business Technology. Before working at S&S Media he studied Computer Science, Music, Anthropology and French Philology.

comments powered by Disqus