John Willis on the Deming Journey to Profound Knowledge in IT & DevOps

304
0

Scroll down for how to subscribe, transcript, and more


My guest for Episode #524 of the Lean Blog Interviews Podcast is John Willis, an accomplished IT management expert with over 45 years of experience. His extensive body of work includes contributions to Deming's Journey to Profound Knowledge and co-authoring The DevOps Handbook.

He hosts a podcast that I was recently on, “Profound.” Check out my episode.

John focuses his current research on DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Over the course of his career, he has sold companies to Docker and Dell, and he played a foundational role at Opscode (now Chef).

In addition, John founded Gulf Breeze Software, an award-winning IBM business partner recognized for its successful deployment of Tivoli technology for enterprise clients. He has authored six IBM Redbooks on enterprise systems management and served as the founder and chief architect of Chain Bridge Systems. Altogether, John has written more than 11 books and launched over 10 startups, cementing his reputation as a significant innovator in the IT industry.

In this episode, the discussion navigates the intersection of lean principles, agile methodologies, and Deming's philosophies as they apply to modern IT and operations. John delves into how systems thinking, profound knowledge, and psychological safety underpin effective incident management and cybersecurity practices. The conversation explores practical challenges and the proactive strategies necessary for integrating legacy improvement methods with today's cloud innovations and infrastructure as code.

Throughout the episode, John examines the real-world application of these timeless principles, offering listeners actionable insights into continuous improvement and risk management. He highlights the importance of questioning established norms and embracing complexity to drive operational excellence, providing a compelling roadmap for navigating the evolving digital landscape.

Questions, Notes, and Highlights:

  • Could you share your origin story regarding Lean and continuous improvement–specifically, what you learned during your early years at Exxon?
  • How have you seen Deming's principle of eliminating fear put into practice in IT and entrepreneurial settings?
  • Is the phenomenon you described an established fact or more of a hypothesis?
  • How can we confirm or measure the validity of that knowledge?
  • Why do you consider cyberterrorism one of today's most significant threats?

This podcast is part of the #LeanCommunicators network



Full Video of the Episode:


Thanks for listening or watching!

This podcast is part of the Lean Communicators network — check it out!


Automated Transcript (Not Guaranteed to be Defect Free)

Mark Graban:
Hi, welcome to Lean Blog Interviews. I'm your host, Mark Graban. Our guest today is John Willis. He's an accomplished IT management expert with over 45 years of experience. His extensive body of work includes his book Deming's Journey to Profound Knowledge, and he co-authored The DevOps Handbook. He also hosts a podcast I was recently on called Profound. That phrase from Dr. Deming–profound knowledge–sparked our conversation. We get to turn the tables and continue the dialogue. So, before I tell you more about John, welcome to the podcast. How are you?

John Willis:
Oh, great Mark, thank you. I think I mentioned on our other podcast that when I first went looking for Deming, some of your blogs were the first I found–and we'll get into how I got into him. I'd been following you long before I even knew you.

Mark Graban:
Yeah, yeah. We crossed paths at the Global Lean Summit last September, produced by Jared Thatcher and Anna Thatcher. I'm glad we met there. It was a great event. I'm going to be back this year. Will you be back, John?

John Willis:
I need to talk to Jared, so yeah, probably. But I definitely want to have a conversation about some of the things we discussed.

Mark Graban:
No pressure, but it'd be good to see you there. I've really enjoyed talking with you. Let me tell you a bit more about you. You're focused on DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Over your career, you've sold companies to Docker and Dell, played a foundational role at OpsCode (now Chef), and founded Gulf Breeze Software–an award-winning IBM business partner recognized for its successful deployment of Tivoli technology for enterprise clients. You've authored six IBM Red Books on enterprise systems management and served as the founder and chief architect of Chainbridge Systems. Altogether, you've written more than 11 books and launched over 10 startups, cementing your reputation as a significant innovator in IT. I think there's a lot to talk about–and if a listener says, “I don't work in software, agile, or DevOps,” keep listening, because this conversation has applicability in many realms, wouldn't you agree?

John Willis:
John, I'm glad you said that, because as we get into Deming–I mean, one of the beauties of what Deming did was showing the world you could do more than just statistical quality parts control. You can use those methodologies and ideas that you and I have embraced. So, yes–give me about ten minutes before I jump in!

Mark Graban:
Give us a chance. John, I love to ask people about their origin story when it comes to Lean or continuous improvement or Dr. Deming. In your book, it sounds like there was a kind of roundabout, indirect path to Deming. Could you tell us, decade by decade, starting with your time at Exxon and what you learned then?

John Willis:
There are two ways to look at my career: one, I'm the “dog and the squirrel” who's always chasing the next interesting thing; or two, I'm an innovator who catches a wave just before the next decade of change. You choose your poison. I started out at Exxon Corporation in the early '80s–1979, 1980–and it was the oil boom. It wasn't just about oil prices; it was about full geophysical discovery. One of my claims to fame that actually launched me into the software business was getting the first commercial Cray–the hundredth Cray ever made, a supercomputer. For you young folks, these were as big as a room–they were the GPUs of their day. I even wrote an accounting system for that because it was the first time anyone had used a supercomputer for a commercial endeavor. My first 10 years were spent writing IBM mainframe assembler code–a baptism by fire for coding in general. Then, when I left Exxon, I found there were great opportunities in what later became known as Silicon Valley, right outside of Northern Virginia, where much of the early Internet was being born. I went to work for a software company there, and that got me into the software world. I always felt the corporate experience was a valuable taste before deciding if you want to be an independent–there's a certain puzzle to it.

I got to see what it meant to be in a company of 50 people going through an IPO–it was like learning the industry. I made a fair amount of money when I was about 22, then blew it all because I was young and single, and eventually found my way into what started to become distributed computing in the late '80s and early '90s. We created a company to manage mainframes, desktops, and everything in between. We eventually sold it and made some money there. That period also led me into more modern things. I was heavily involved in operations–my career was all about figuring out how to help a bank run, from software delivery to security to physical infrastructure. As the early cloud era and DevOps were emerging, even before DevOps was called DevOps, we saw the distribution patterns of Agile and Lean. I even recall that at one event–an early DevOps Days in Mountain View, at LinkedIn–I got on a panel with Gene Kim. I had read his book Visible Ops (the coffee-stained bible for many operations folks), but I didn't know him face-to-face. After the panel, Damon Edwards came up to me saying, “That was Gene Kim,” and I went looking for him. Later, we met at South by Southwest, had coffee, and he told me about his book he was writing–the Phoenix Project.

Mark Graban:
Yeah.

John Willis:
And I was like, wow, this is really interesting. Gene gave me the greatest gift by urging me to read a particular book in bold caps. He'd tell me, “You must read this book,” and I did. I read Toyota Production System, High Velocity Edge–I had no idea who some of these authors were until he sent me that email. I became infatuated. As we continued talking, I got deeper into Deming's ideas. I even started a presentation called “Deming to DevOps,” where I explained how a non-deterministic mathematical physicist was, over 70-80 years, laying out what we now put on PowerPoint or Google Slides in our Deming presentations. That conversation led us to talk about writing a book that was more prescriptive than The Phoenix Project. We gathered evidence from our conferences, and that became The DevOps Handbook. But on another note, I started running the first few DevOps Days in the U.S. with Damon Edwards and another colleague. I even hosted an open space discussion on theory of constraints with a friend who reads at least one research paper a week. Every time we met, someone said, “Oh John, it all goes back to Deming.” So I dove into Deming's work–studying his 14 points–and I was hooked. I spent a solid year trying to figure out who this guy was. Eventually, I built an audio-only project called Deming to DevOps that laid out these concepts.

I then turned my focus to writing a book that told a story in a style reminiscent of Michael Lewis–one that could appeal both to non-technical readers (like my mother-in-law) and to subject-matter experts. In that book, I noticed that while many biographies of Deming spent five to 15 pages on his life, the majority was dedicated to his management theories. I wanted to tell a storytelling book in a Michael Lewis style about a man who could have been a Michael Lewis character–profound, challenging, and yet deeply human.

Mark Graban:
Yeah.

John Willis:
Every time I've had the chance to be with folks like Bill Bellows–people who explain systems thinking–I've been amazed. I mean, the discussion of Deming's ideas sometimes seemed almost too profound to capture in a single presentation. And I've always said, for people in operations, Deming's work is like a lighthouse that brings us back when we're lost at sea.

Mark Graban:
Yeah.

John Willis:
I've seen it in everything–from software release incidents where everyone but the delivery manager agrees that the product shouldn't go out, to those moments when we rely on blameless postmortems to truly understand what happened. Too many people want a magic bullet. They dive into Deming's principles expecting an instant fix, but there's always work to be done.

Mark Graban:
Right. And you mentioned one instance involving fear–when people are afraid to speak up. I'm thinking of Deming's 14 points, especially the idea of eliminating fear from the workplace. How have you seen that operationalized in IT and entrepreneurial settings?

John Willis:
In IT operations, incident management is a critical area where Deming's principles come into play. For example, I've witnessed scenarios where people avoid walking down a hall at GE Capital for fear of running into a black belt or an executive who might grill them on their performance. I have another story–if you've heard of Ubuntu, created by Mark Shuttleworth, or worked at Canonical, you might recall how the CEO would literally monitor everyone's schedule. His presence alone could make employees anxious. This type of fear disrupts the joy of work and hampers innovation.

Mark Graban:
Yeah, fear saps the joy out of work. And in your book, you use the term “psychological safety” (citing Amy Edmondson) to explain this phenomenon. Do you have any stories or examples that reinforce the idea that people are afraid to speak up, and what can be done to counter that?

John Willis:
Absolutely. In IT, incidents are often triggered by a small failure that escalates because people are too afraid to speak up. You've got to understand that blaming individuals isn't productive–there's rarely a single root cause. Instead, many organizations now conduct blameless postmortems. I've seen teams use techniques like the Five Whys not as a way to assign blame, but to uncover multiple layers of what might have gone wrong. This process, combined with statistical analysis and psychological insights, helps build a culture where everyone feels safe to voice concerns, even if the answer isn't immediately clear.

Mark Graban:
Right.

John Willis:
When you do that, you begin to see a pattern. You realize that the problem is systemic, not just about one person's error. That's when you start thinking: “Do I really know what's happening?” And then you use data and analysis–control charts, for example–to see where things are off. In a way, it forces you to ask, “Is this just a guess or a hypothesis?” And that's the essence of continuously improving the process.

Mark Graban:
Yeah.

John Willis:
It's about questioning what we think we know and then verifying it through disciplined analysis. When you combine that with psychological safety and systems thinking, you get a framework that truly supports continuous improvement.

Mark Graban:
Exactly.

John Willis:
I'd even go as far as saying that if I had two words to improve technology and business, they'd be “systems thinking.”

Mark Graban:
Absolutely.

John Willis:
We can look at incidents–whether it's a software release or a physical outage–and ask, “Do we really know why this happened?” And in doing so, we adopt a mindset that's about learning and improving rather than blaming.

Mark Graban:
Right. And that leads us into another topic: you mentioned that some phenomena in IT are more hypotheses than established facts. Is that how you view it?

John Willis:
Yes, exactly. In many cases, what we think is the root cause is really just an educated guess. We have to build a system to validate that knowledge. That's why we continuously collect data, run statistical tests, and foster an environment where questioning is encouraged. It's not about having all the answers from the start–it's about building a culture where discovery happens every day.

Mark Graban:
Yeah. And this brings us to another interesting aspect of our discussion: cyber terrorism. You mentioned it as one of today's biggest threats. Can you elaborate on that?

John Willis:
Certainly. I believe cyber terrorism is even more dangerous than many realize. For instance, I've seen cases where cyber terrorists managed to infiltrate a water treatment plant's control system–using something as simple as a remote routing cursor mouse. In one scenario, during the week of the Super Bowl, an operator simply ignored anomalous activity on autopilot until it was too late. This isn't just theoretical; it's a real risk in today's interconnected systems.

Mark Graban:
Yeah.

John Willis:
There's a lot of research coming out, including reports from CISA, that highlight how vulnerable our critical infrastructure is. Whether it's our telecom networks, water supplies, or power grids, these systems are at risk, and the consequences of an attack could be catastrophic. The underlying issue is that we tend to be reactive rather than proactive when it comes to these systemic risks.

Mark Graban:
Exactly. It seems like we wait until something terrible happens before we take action.

John Willis:
Right. We see this in many incidents. Take, for example, the way some airlines and banks handle disruptions. The incident might be classified as a minor issue–a P1 or P2 event–but when you aggregate all these “minor” incidents, the data reveals a pattern of systemic vulnerability. I often quote a friend of mine who says, “Incidents are unplanned investments in knowledge.” In other words, every incident, no matter how small, is an opportunity to learn and improve.

Mark Graban:
That's a powerful way to look at it.

John Willis:
Exactly. And it forces us to question the status quo. When we look at incidents not as isolated failures but as part of a larger system, we begin to appreciate the importance of continuous improvement. Whether it's using control charts, conducting rigorous postmortems, or implementing systems thinking, it all adds up to a culture of learning and resilience.

Mark Graban:
Yeah. And speaking of systems thinking, you've talked about how Deming's work has influenced modern IT and operational practices. How do you see those principles applied today?

John Willis:
Deming took concepts that were once confined to manufacturing and applied them universally. His ideas about variation, statistical process control, and continuous improvement aren't just relevant to factories–they're fundamental to modern IT operations, incident management, and even cybersecurity. When we talk about psychological safety and systems thinking, we're really echoing his ideas in a digital context.

Mark Graban:
Absolutely. And in your work, you also explore how these principles can be a blueprint for handling the complexity of today's systems, right?

John Willis:
Yes. I even developed an audio project called Deming to DevOps that outlines how a non-deterministic approach to management can be applied to IT infrastructure, security, and even AI. It's about recognizing that our systems are too complex to be described by a single root cause. Instead, we need a multi-layered approach that integrates data analysis, psychological insights, and above all, a culture that embraces learning from every incident.

Mark Graban:
Yeah. Our conversation today really spans a wide spectrum–from the early days at Exxon to the modern challenges of cyber terrorism and the evolution of IT operations. Before we wrap up, I know you have another book coming out about the history of AI. Can you tell us a bit about that?

John Willis:
Sure. I've been working on a book titled Rebels of Reason. It's essentially a storytelling account of the history of AI, written in a style that I'd say is reminiscent of Michael Lewis. The book captures the evolution of AI from its nascent stages to where we are today–exploring the human side of technology and how the pioneers of AI thought differently from the mainstream. It's an exploration of why understanding the history of AI is crucial for deciphering what's hype and what's not in today's technological landscape.

Mark Graban:
That sounds fascinating. I look forward to reading it when the first distributor copies come out in April or May.

John Willis:
Great. I'm excited about it too. It's my attempt to tell the story of the rebels who didn't give up and who saw the world differently–those who helped us get to where we are now, much like the journey we've been discussing today.

Mark Graban:
Fantastic. John, thanks again for being here today. It's been a truly enriching conversation.

John Willis:
Thank you, Mark. It was a pleasure. I look forward to seeing you at some of the conferences, and of course, on the podcast again soon.


What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.


Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:

Get New Posts Sent To You

Select list(s):
Previous articleRegistration Open Now! Deming-Based Workshops in Toronto and Cincinnati
Mark Graban
Mark Graban is an internationally-recognized consultant, author, and professional speaker, and podcaster with experience in healthcare, manufacturing, and startups. Mark's new book is The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation. He is also the author of Measures of Success: React Less, Lead Better, Improve More, the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, and the anthology Practicing Lean. Mark is also a Senior Advisor to the technology company KaiNexus.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.