What We Can Learn from Deming about Building Great Products with John Willis

Have you ever heard of W. Edwards Deming? What about... the Toyota way? Lean? DevOps?

John Willis is one of the pioneers of the DevOps movement, and, has recently released a book "Deming's Journey to the Profound Knowledge". In this latest episode of Quality Bits you'll hear more about this book, and the ideas of Deming that we can still learn so much from when wanting to build high-quality products and teams.

Find John on:

• His website: http://www.johnwillis.com/
• LinkedIn: https://www.linkedin.com/in/johnwillisatlanta/

Mentions and resources:

• Article "Standing on the Shoulders of Giants" by Eliyahu M. Goldratt 
• Books 📚 :
  • "Deming's Journey to Profound Knowledge: How Deming Helped Win a War, Altered the Face of Industry, and Holds the Key to Our Future" by John Willis
  • "The DevOps Handbook, Second Edition: How to Create World-Class Agility, Reliability, & Security in Technology Organizations" by Gene Kim, Jez Humble, Patrick Debois, John Willis
  • "The Goal: A Process of Ongoing Improvement" by  Eliyahu M. Goldratt
  • "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" by Gene Kim, Kevin Behr, George Spafford 
  • "Toyota Kata" by Mike Rother
  • "The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition" by Steven J. Spear
  • "Wiring the Winning Organization: Liberating Our Collective Greatness through Slowification, Simplification, and Amplification" by Gene Kim, Steven J. Spear
  • "Out of the Crisis" by W. Edwards Deming
  • "The New Economics for Industry, Government, Education" by W. Edwards Deming
  • "Thinking in Systems" by Donella H. Meadows 

Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases

Follow Quality Bits host Lina Zubyte on:

• Mastodon: https://mastodon.social/@linazubyte
• X: https://twitter.com/buggylina
• LinkedIn: https://www.linkedin.com/in/linazubyte/
• Website: https://qualitybits.tech/

Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.

If you like this podcast and would like to support its making, feel free to buy me a coffee: https://www.buymeacoffee.com/linazubyte

Thank you for listening! ✨

Transcript

00:00:04 Lina Zubyte 

Hi everyone, welcome to Quality Bits - a podcast about building high quality products and teams. I'm your host, Lina Zubyte. John Willis is an author, an evangelist - as he himself says. He has sometimes been labeled as the godfather of DevOps. With multiple years up his sleeve working in tech, he has gathered lots of great knowledge and has been sharing it as well. His most recent book about Deming is a great read and I definitely recommend to check it out. In this episode, we're talking about Deming as a person, the ideas that he has had, and an overall John's idea on quality. Enjoy this conversation. 

00:01:06 

Hello John, welcome to Quality Bits. I'm so excited to have you here today. 

00:01:11 John Willis 

Hey, it's great to be here. 

00:01:14 Lina Zubyte 

I've just read your book in a week. I was so obsessed about it. It was such a wonderful book that I kept telling my friends about it. I know it's not the only book you have written. You have many more books, but the interesting thing is that in introduction when a person was describing you, they said that John would not like the systems that weren't optimized. That that would annoy you. And I was like, alright, that sounds like a very interesting person that I could connect with. So how would you describe yourself? 

00:01:50 John Willis 

Yeah, that's a curse and a blessing, right? The way you look at things, if you sort of, I don't know how I got into that bug very early, but maybe it was my first job at Exxon. Working with geophysics and you know, just discovering oil, I guess it always sort of gave me a scientific mindset, which is sort of always questioning, you know, we’ll talk a little bit about Dev OPS at some point, but I'm sort of the OPS side of this DevOps equation. From my first job, I ran large operations back in mainframes in the 80s. The joke I sell is when you get to my age you round down, you know, hen you're younger - you round up on how much experience you have, right? I round down. So I'll say 40, you know, with a little chuckle saying it's a little more, my fear is I'm getting awfully close to 50. So I don't know what I’ll do then. Depending on which books you count or not count it's probably about 12 books. Depending on which startups you count or don't count, it's about startups, give or take some like really quick failures. Sometimes I don't count those, but yeah. I've done some executive roles. And I think at this point I'm done with startups. 

00:02:57 

But I've said that before, you know, when I was a Chef, I thought that was my last startup, and that was 10 years ago now. But I'm pretty sure now I'm done with startups. So when I went through the sort of last one I was working with, I noticed a lot of my friends are doing this, fractional CTO, fractional CMO roles and in the end day I'm an evangelist, you know and for whatever of that means, I'm technical, I can present, I write books, I can talk to executives. It's sort of a role that is not well defined. But it's what I do and I thought, you know, the people who understand my role, why don't I try putting out, you know, my shingle is a fractional evangelist. 

00:03:36 

And people responded well, right? So, in fact, my biggest problem was in all that highfalutin description of myself, I'm actually not well organized. And I wanted to be careful not to take on too many clients because I could have zero clients. So I think I found a right mix, you know, a proportional. I'm doing work for MongoDB and the good news is, you know, part of the thing I've been really shifting towards is how is this generative AI, all this stuff we're starting to see explode, how is it going to work in our world? You know, infrastructure, operations, IT. What's going to be the technical debt, the burden? In my three clients I’m very much focused on how I can sort of work through those DevOps, DevSecOps, Re and Generative AI as it sort of applies to the world that we're in, the DevOps, DevSecOps, quality, you know, all that stuff. So that's been great. Yeah. And talking about like, what do I do besides... 

00:04:35 

You know, I sort of joke like I typically have a day job. My day job is my clients and my kids are out of the house now. So it used to be: I do my day job, I do some stuff with my kids. Now I can't find them anymore. They're old enough on their own. They've got lives of their own. But I'd go then do sort of hobby stuff. And most of my real hobby stuff is technology either thinking about a new book or, you know, researching ideas. But actually, every once in a while I pick up my guitar. I started playing guitar when I was like 13 years old, I was in rock bands in the 70s, so I always say I'm a better guitar collector than I am player, but I keep guitars around the house. You know, there's like one over there. I got one downstairs. So just it reminds me that I should just pick it up and play more often. 

00:05:22 Lina Zubyte 

Yeah, it's easy to take, right? As an easy habit forming. 

00:05:26 John Willis 

Yeah, yeah, yeah. 

00:05:27 Lina Zubyte 

So you are one of the DevOps movement founders. What's the story there? How did this happen? 

00:05:33 John Willis 

Yeah. You know, the thing I like to say, there's a gentleman, Eliyahu Goldratt  - wrote the famous book “The Goal” and he has a famous paper called “The Shoulder of Giants”. So I always like to point out that when we talk about like people come and say ohh John, you're the godfather of DevOps and like no, that's not really true. Patrick Dubois is the godfather. But if you want to use sort of godfather metaphors, I'm the “signorelli”, I guess you call it. But the real point is this is a movement that is built incredibly by a shoulder of giants community, right? So like when somebody says you're one of the founders and it just means that I was in the right place right time I instigated some things, but the community of just incredible people have created what we have as DevOps today. So maybe I helped light a fire. I got really lucky. A good friend of mine, one of my best friends, Andrew Clay Shafer, who also is considered one of the founders of the DevOps movement...  

00:06:25 

I heard him on a podcast one time and I knew him. He was one of the co-founders of Puppet Labs, the infrastructure as code company, and he was talking about this idea of agile infrastructure or agile operations. So I knew enough about agile to be dangerous because I was an ops person. I had to deal with agile people. But didn't really fully understand it, but I knew it was an important aspect of how IT was sort of evolving. So this would have been the mid to late 2000s, right? 2008 or 9 or 7. And so I called him up. I was like when I heard the podcast, I felt like I was driving when I was listening, I almost drove off the road. I gotta know more about whatever that is. And he said there were some people in Europe that were focusing on this idea. And I found Patrick Dubois, who is indeed, that godfather of DevOps. And I reached out to him, and I was actually at the time I was doing a lot of cloud work with Canonical. 

00:07:20 

A bunch of folks, they knew this had to be red and hot. And Patrick said that he was running a conference, a DevOps day. I don’t know if it was day or days. But it was in Ghent and it was the first DevOps days. And I'd worked for Canonical and Simon Wardley, Wardley maps, Patrick said, if you can get Canonical, we'll send you over, we'll give them a logo sponsorship. So I called Simon and I said: “Simon, we should be involved in this. This is important. I think it's going to be a big deal “. And he said no problem. And it was amazing. 

00:07:49 

Ghent was this birth of just people from around the world, and just incredible people. The people that just left and spread DevOps in Australia, spread the DevOps in the UK and Europe. And I went back and spread DevOps in the US. And I had a good friend, Damon Edwards. We started doing, like a lot of enterprise operations stuff, but we kind of converted quickly to DevOps and we created the first DevOps conference at LinkedIn, in Mountain View. I think that was 2010, I believe, yeah. Well, maybe about 2009, I'm sorry, yeah. And just to put in perspective, there were like probably 40 or 50 people in the first DevOps days in Ghent. We had almost 300 people like 8 months later. 

00:08:34 

It was of course the Silicon Valley... And then we, me and Damon helped, and there were others... Andrew Clay Shafer, Mark Hinkle.... I can go on and on. And I apologize if I'm forgetting your name. We helped start a few other cities and just been involved and then sort of last but least around the sort of DevOps movement is I got really lucky meeting Gene Kim, wrote the Phoenix project and many more. When the Phoenix project came out, the novel. There was going to be a need for a prescriptive guide and we started talking about a DevOps cookbook which turned into the DevOps Handbook, which is sort of still today... We co-wrote it with a couple of other people, Patrick and Jez Humble and it is, I think, still today and not because I'm 1/4 of the knowledge that went into it, but I think it is still the canonical resource for DevOps. 

00:09:23 Lina Zubyte 

We may have referenced “The DevOps handbook” already in the podcast in the previous episodes... So what is quality to you?
 
00:09:32 John Willis 

Ah yeah, that's a good one. You know it's interesting. Of course, like everything else, especially when you try to put it in perspective or context of what does it mean in sort of a business, what does it mean in IT? What does it mean in IT business? What does it mean in sort of development, operations and testing, right? We can go down a lot of fun rabbit holes. But if I bring it back to most of the research I've done around this topic. There's no way of getting out of bringing Deming up at this point. I think most people would think that Deming and I think he's even been asked this. He would say it's the reduction of variation. 

00:10:14 

But I think if he had to redo on some of his earlier quotes, I think he'd say understanding variation, because I think it's not just maniacally reducing variation, because at some point there is diminishing returns, another point, it's not pragmatic. So I think it's understanding variation. So what does that mean? That means it needs to apply Systems Thinking. It needs to apply variation, understanding variation, so analytical statistics really, using math. And then you know it needs to understand intuition, cognitive biases. And then I think the other thing is sort of how we think about solving problems like, you know, fancy word, epistemology. But really, theory of knowledge or just scientific method, how do we know what we think we know, right? So I think that's a good umbrella that fits all examples if it's whether you're building, you know, cars on an assembly line, you're writing software, you're testing software, you're trying to operate software. I think that thinking about quality that way enables you to get a consistency and get results. 

00:11:23 Lina Zubyte 

To be honest, I did not know much about Ed Deming. I listened to your podcast. I read your book and I really, really enjoyed it. So the book that I'm talking about is called “Deming’s Journey to Profound Knowledge”. In the very start, you caught my attention because you said that Deming was labeled as the prophet of quality. And I was like, I'm working in a quality field for over 10 years. What? Who is this person? The whole book had so many great ideas that I was like, wow, this is where it's coming from. It's years back. Talking to various people in this podcast, I realise that a lot of ideas are circling back. A lot of things we say that, oh, this is modern. This is recent. It's not that modern. It's not that recent. There have been so many people that have been telling the exact same thing years back. Why do you think Deming was labeled as the prophet of quality? What makes him the prophet of quality? 

00:12:21 John Willis 

So I think as I said earlier, if Deming could ever redo on the way he answered some of those questions about quality, he'd probably say understanding as opposed to just reduce variation. You know, I'm a psycho-fan of Deming, right? So I'm just going to admit it... As I got deeper in the book I realized that I need to be careful because there's just so many narratives to this what we have and what we call quality and the modern concepts in which a lot of them, you know, I know you work with and there's large communities that are really in the right direction now. A long way to say that I'd almost take that out. Just because there's so many aspects... But there are these nexus points and when we look at where quality comes today...  If we work our way back and this is actually what I did. I did meet Gene Kim when he was halfway done with the Phoenix project. The Phoenix project was a modern day rewrite of a book I referenced earlier - “The goal” by a guy named Eliyahu Goldratt. 

00:13:14 

And before Gene would give me an early copy of what he was working on, he said: “you really should read “The Goal” and I read “The goal” by Eliyahu Goldratt and then I was like, oh, my goodness, this person understands me. And I read a whole bunch more books by him and it was actually at the first DevOps days.... We did, basically, it was an open space discussion about Eliyahu Goldratt and his notion on what they call theory of constraints. And Ben Rockwood was like John, you do know this all goes back to Deming? And, by the way, when I've done podcasts with people who love Deming like I do, they almost all have this journey of somewhere along the way, they learned to Lean. And then they wanted to know where Lean came from, and then they worked their way back. And this is what I did. I said OK, where did this DevOps thing really come from? And you start looking, you say, well, a lot of it was something, you know, a lot of it came from Agile. Well, where did the Lean come from? Where did that come from? 

00:14:05 

Well, almost all of it comes from the canonical work at Toyota and Toyota Product systems, right? So and again, if we wanted to say, like, these are points in time, a lot of things that happened in Japan and quality. But we can point to a narrative that tells us back to what Toyota was doing from, like, the 70s, really starting in the 60s. And then you should have peel that back a little bit and like what was going on between end of World War 2 and when Toyota started this insanely accelerated pace of quality and delivery? I cover this in the book, some of the research of how many assembly workers to produce cars and it's just by the time we get into the 80s and Doctor Spears says it's a decimation and Toyota is decimating GM, Ford and Chrysler. 

00:14:58 

And so if you look at what happened in Japan in World War II... There was a rebuilding process, right? MacArthur was over there. Japan was in rumble and part of it was self fulfilling. MacArthur had to sort of manage stuff and he couldn't even make phone calls. People couldn't drive anywhere. So there was this attempt to bring these smart Americans over to help take some of their ideas and Deming was one of those people. And Deming happened to click with a group of, you know, Deming at the end of the day he would call himself a statistician, like that was on his business card and there was a group of wartime statisticians that were sort of banned from doing work. That story itself is like, amazing how this group called JUICE winds up figuring out a way to get Deming to come over and but probably the best story of Denny's influence in Japan in 1950 is... 

00:15:49 

He's in a room with documented 80% of the controlling wealth in Japan in 1950, and he tells them in this meeting that if they follow his guidelines, they'll be a world power in five years and in a little less than five years, they take the number two spot over Germany. Only behind the US and I've done the research where like there you know, there's a lot of Toyota early 60S was influenced directly by Deming’s work. And again Deming's work comes with a whole lot of other people and Deming was the first to share as a doctor Sheward - the statistical process control. But anyway, that's a fun narrative and almost everybody who becomes a Deming fan, their story is exactly like mine. They just kept digging and digging and digging. And back to what? Ben Rockwood, who told me that, like, John, it all goes back to Deming. I always challenge people, if you're like, well, I'm just not gonna listen to this person who's on a podcast whom I never heard of before either. Go look at Deming’s 14 points. Just Google it and see if those 14 points don't resonate the way you think about how you do your job. 

00:16:55 Lina Zubyte 

Yeah, it resonated with me so much. There were so many points, like even this example of Japan. Right now when we think of Japan, we think of quality, but that was not the case. The fact that made in Japan was understood like, oh, this is terrible quality. This is a part of history that a lot of us cannot even comprehend and that they did not believe in their even ability to restore. And Deming was the person who was to consult them who believed maybe more in them, they than they did. 

00:17:33 John Willis 

One of best quotes is that he believed in them more than they believed in themselves. 

00:17:37 Lina Zubyte 

Exactly. And that was also like this cultural thing, right? That maybe because in their culture, they're sort of listening to what someone is saying and trying to do it, even though they did not believe it - they still did it and they made it. And it was funny how in one of the stories you shared, it was that Deming said that you will be in this level in five years, but actually he was wrong because they were there in 4. 

00:18:03 John Willis 

And, you know, and the interesting thing is there's these debates, like who really, what American created the... Sort of the arrogance of Americans, right? What American created the miracle in Japan?? And the thing I say clearly in my book is Japan, the Japanese created the miracle in Japan. Deming came over and helped. There were others but one of the things is that there was this perfect marriage of a culture of failure. You know, I call it the tsunami culture. They were used to rebuilding, they had a resilience. There was an intrinsic motivation of the way they thought about things and Deming had this notion of understanding data. And you know in in a lot of his philosophy of how people should be taught it was just a perfect melding of the union of things they both agreed on. And then both the things they both shared with each other. One of the characters in my book was this woman Doris Quinn and she spent the last years of Deming’s life travelling with him. And she has incredible stories about him. 

00:19:09 

But I proposed to her that could it be true that Deming learned as much from the Japanese as he taught them? And she said, huh, that's a great point. And so there was this sort of beautiful melding of a culture that sort of understood rebuilding who understood how to rebuild, not over obsess on failure. And then the notion of that like you think of things like your community, your neighbors, you do things for a whole different motivational level and just that combination was, you know, and then the belief that he had in them. And he loved the culture. There's a book, his secretary made a book of all these notes that he had done over years and he loved sake. He loved kabuki theater. He loved Japan. He loved the people. He loved the culture. He loved everything about it. So it was just a perfect marriage to create a perfect sort of tsunami, which becomes Japan from like the 70s to like almost year 2000 and still today, but at least some of the American companies and the quality movement has at least gotten some of the discussions on par. 

00:20:22 Lina Zubyte 

Yeah, I think it's not necessarily that this person did something. I think the ideas are so relevant. Even when he gave a lecture and then he realizes that this is not the audience. That we should be talking to the top management rather than the workers, and that he would be rougher with the top management... The funny thing is, I was so resonating with that, working in some kind of overarching software quality role because not only this, but most of the things even Conway's law, right? We are actually just the representation of the top and so many times trying to change something, I would dig deeper and there would be a much deeper problem why there was some bug. A bug doesn't matter even. There would be something much harder and more difficult to tackle and Deming already said: we should build quality in. When I was reading this, I was like what? 

00:21:22 

It's exactly what we're trying to say now and this fact that there's also people involved that you have to talk to the right people and that management has to reflect the ideas as well to the company and only then we can do the change because if the system is not allowing people to change, then it's a lost cause. So it really, really resonated with me. What is the system of profound knowledge? There are four elements. Could you explain it? 

00:21:50 John Willis 

Sure, yeah. The one other thing I want to say is that there's some great sort of points of which you now have: the one point which was he realized he was talking wrong people, and then he asked Ishikawa that, hey, I need to talk to leadership. And he was very like... If he talked to a worker, he'd let them ask questions all day long, he'd guide them. But he was brutal with management. And then after he became well known, you know, the story of... He was basically forgotten after World War 2 in America, he actually helped win the war. I cover this. And then after the war they go back to the old system. And it's not until America tries to understand in the 80s or late 70s of why Japan is just beating us on everything from quality and cost... And the NBC does a documentary, and I use a little bit of literary license here, but the CEO of Ford realizes, Ohh, I need to talk to this guy. And he's.... You know nobody, even America knows who he is. And in this documentary people realize, oh, wow, it's an American that taught them how to beat us. And again, that's an overloaded statement. 

00:22:59 

So all these leaders of Xerox and they would all be General Motors, Ford, they'd all be calling Deming in the 80s. And he would basically...  the CEO and the Peterson would call him and say, hey, you know, we want to bring you in and Deming would say, well, we're gonna work together and, you know, the CEO would say, “oh, no, no, no. I'm the CEO of Ford! I'll get you the right people.” Deming kind of almost hang up on. And they call back like don't hang up on me, you know. And again, I'm using a little with my own literary license. But it wasn't too far off. And they'd say Dr. Deming, you have to understand, I'm the President of Ford Motors. I can't be spending this time on this. And he's like, his point was, if you don't take this serious enough to work with me, then I'm not going to waste my time working you. And about the third time, the CEO gets hung up on he's like OK, alright, I'll work with you. Don't hang up, I’ll work with you. So I love that you caught that whole story of even that started back in cause I tell the Peters to start all the time I forget that actually started actually in Japan. 

00:23:56 

But profound knowledge is interesting. Just like if I tell you go look at or somebody look at Deming’s 14 points. You're like, oh, by the time I get through this profound knowledge pretty quickly, you can go, oh, I kind of do all that stuff or I want to do all that stuff. And part of the book, like one of the journeys of the book, is, it's called Deming’s journey to profound Knowledge, which was he didn't invent these ideas, he just codified them, actually, in his last book, when he's 90, in his 90s, he puts it all together in his sort of aha moment and calls it system of profound knowledge. And so my one of the things when I realized I was going to write this book, like, really write it, not just take notes and keep telling myself, I'm going to write the book. 

00:24:40 

I had to understand, where did he get these four? So let me take the four and I put them in a certain order because I think they make sense now, like true Deming-ites would say: “Ohh, there's no order. You need to do all four.” And I know that, that's true. They all work together. But I think the reason I put them in this order is 1 is what it's called the theory of knowledge. And so theory knowledge I mentioned earlier is really sort of epistemology. It's the scientific method, you know, it's if you've read Mike Rother’s “Toyota Kata”, it's called improvement kata, you might have heard it as PDSA: plan do study act. And it's how do we know what we think we know? 

00:25:24 

Right? Because all these things are abstractions, me and you can be told a story about how the infrastructure and how software works. And I have friends who have done this experiment... And then have two people go in two different rooms and whiteboard the architecture out and then compare notes and they look different. Right? So we know that's a human condition called mental models. So the question is, once we understand that, then the real sort of first question should always be... We only think we know what we know, so let's basically figure out a way to sort of like at least get a higher probability it's been attributed to Deming as a quote. I actually can't find it in any of his any of the writings that I have, but it's a good quote. So he probably did say it. He'd say that “quality means a predictable degree of uniformity and dependability suited to the customer”, right? Or some cost load which means it is a prediction. 

00:26:19 

It's hypothesis. So the more we can think like scientists than what we do. And don't be, you know, sort of brash and arrogant and say, Oh no, it works that way. You know, I mean, it's like I can go on and on, but like, Toyota had this idea of go to Kemba, right? If something broke they didn't call a floor manager on it at his desk, reading the newspaper, and the manager’d say, oh, we've seen that before. Don't worry about it. The manager would actually literally come down to the floor and they would discuss. All that stuff that I do cover in the book. So that's the first question. How do we think like scientists? Doctor Spear, who wrote High Velocity Edge and now a new book with Gene Kim, the winning organizations? I'm sorry. Gene Kim’s gonna kill me for not getting the name right, but maybe you put it on the show notes, but he said. He did one of the most downloaded Harvard Business Review articles and it was some variant of decoding the Toyota production DNA and one of his sort of themes that he did and I love turning the code around, which is Toyota was a community of scientists continuing experiment. That means everybody. 

00:27:26 

Sweeping the floor. Putting the brakes on the assembly line, right? So right, so that's the first. The 2nd is understanding variation. So back to what I was saying early, it's not about just reducing variation, it's understanding variation and this is where you get into trouble where if you don't understand like some variation or Black Swans and if you try to fix them. You're wasting your time. Some variations are just part of the system, and the people in that system don't have control over it, right? And most people would confirm for the understanding variation as part of profound knowledge as statistical process control. But it's analytical statistics. It's using sort of math and statistics to try to validate what you think you know. Like if the first question of theory knowledge is how do I know what I know? Then let's use some tools. 

00:28:15 

Try to see what is this sort of... And then this. So even if you get those two right, there's a cognitive trap that always sits with all humans, which is understanding psychology. So that's the third lens. Which is, you know, what is the biases? What is your sort of motivation? What you know, there's people say extrinsic or intrinsic. Well, there's actually lots of variants of intrinsic motivation. So you could set a whole podcast on intrinsic motivation types. But the point being understanding why I'm trying to help you understand some complex problem or solve some problem? And I can show you all the epistemology. And so the scientific method. I can show you all the statistical analysis, but if you just don't believe because you have a background, there's some cognitive bias we're going to spin our wheels. So this is another brilliant point Deming included this.  

00:29:15 
 
And then the wrapper for all of it is what he calls appreciation for our system, which is basically systems thinking. And they all work together. And I've been doing this, like I said, honestly, it's about 46 years I've been doing this professionally in some form of working with large infrastructure. I've not seen a better explanation of how to deal with complex systems and everything we do is a complex system. So if you got a better, I mean, there's some add-ons. You know, I mean, I probably don't want to get into to Taguchi loss function, but look it up. And so Deming late, in his career, I mean late is like 88/89, he starts understanding Taguchi's work and how valuable that is, so you could almost add Taguchi's work as a wrapper on profound knowledge. But yeah, that's the basics. And that's my book. My book is basically the journey from him working, you know, and his internship at Hawthorn works. That's where the Hawthorne effect was discovered. For his work in the Census Bureau and creating the first sort of statistical census. Was him working in top secret programs during the war, helping us win the war? It's him going over Japan helping Japan. And it's him from 80 to 93 doing the most profound work of his career, working with almost every large Fortune 100, Fortune 200 Corporations in the US, helping them understand quality. 

00:30:37 Lina Zubyte 

I loved his ideas and I could finally have the words to describe some work I was doing, which was wonderful. I think there was one quote as well in the book saying that Deming has said or would have said likely that quality is not that much about the product. Quality is about the process. And I was like finally I have the words to describe what I'm doing because I'm not just finding a bug in the product. There's so much more there. 

00:31:05 John Willis 

There's so much in this in that. I love the fact that you're sort of nailing this. I mean, you know, I think most of the people who take the time to read this book are pretty much... you wouldn't. You'd be pretty much in tune with, you know, if you got past the first or second chapter and you didn't like it, you would probably be not the kind of people that would be on a podcast us, right? And that's not because I'm brilliant. I think these are just universal, really good ideas. 

00:31:32 

But the idea of the process, there's so much there. It plays on system thinking and this is where a lot of people get upset and hopefully you won't either. You know, Deming hated  MBOs. That's OK. I think everybody's OK with that. And Drucker later in his career I think sort of almost apologized for like creating MBOS, right? But because he said that the idea of results was not the point. It was the method. If you did something, if you accomplish something great, why don't, how come you didn't do it the next year? How come you didn't do it last year? Because you're not... and this is what Toyota was amazing at. Once they knew something worked, they focused on sharing the process of why it worked with everyone else. 

00:32:22 

And I think we lose sight of that. And, you know, I obviously think Deming would have hated OKRs for the same reason. Now, I know that that the initial idea behind the OKRs... It was the right idea, but the implementations are very much results. Objectives and key results, and Deming would be like you know, I don't care about the results. And I know a lot of people will be like: doesn't care about results? How does he make money? Well, if you take a systems approach. You make money. Things do work out better. And so he was more about the method and there's a term I don't think Deming ever used, but it's used a lot, it’s management by means. 

00:33:01 

Like what did it mean? Why does it matter? Deming would say, what's the method? And so that goes back to the process. It's about understanding the process and that goes back to, you know, understanding variation. There's certain things in the process that are part of the process that that group of people are not able to change. And so firing or giving people promotions, Deming would say that you know 96% is system and only four percent is human. I think it was like he said, it was 99.7 in this system. And so if you're basically rewarding people or firing people on a system that they can't change, then you're tampering - is what he would call it. And so it is about the process and understanding the process in terms of things that are within the system or outside the system or, you know, the inner connectivity of different systems. So your process is key. 

00:33:59 Lina Zubyte 

Yeah. The first time I heard the “systems thinking” I was like what is this? And I was not sure if I would like it or not, even though I am quite a philosophical human being. I have mathematics degree which also surprised me that Deming was a statistician. I was like ohh I should maybe read those statistics theories, you know? But the systems thinking there were multiple amazing stories in your book that I think are worth telling. I told my friends random ones like operation Cat drop... 

00:34:30 John Willis 

Yeah, yeah. 

00:34:31 Lina Zubyte 

Let's not spoil this one, but check it out. It's wonderful. I think I should write down an impressions article and share some of my favorite stories that you told there. Thinking about systems thinking, you also use one analogy about the elephant. If you touch the elephant just the tail, you may think it's a rope. There's even this cartoon. Years ago I would use that cartoon to show what a QA is. Because I see the QA very often as a person who steps back and sees the big picture of what is the system. So many times I was like this person joining different people together so that they collaborate. Being a team glue, that's the term sometimes you would say for QAs. And finally now I can put it to words and maybe it's not necessarily the tester role that I see necessary here but more someone to help people collaborate, because somehow on the way we lost it and we struggled to see the big picture because we just look at our box and our task in front of us. 

00:35:33 John Willis 

Yeah. And that goes back to your question of what quality is, right? Quality is (and this is where Taguchi gets pretty interesting) and I feel the exact quote...but basically Taguchi would say... Quality is: the net result is how it affects society and what he meant society, he meant like you need to think about it is not just your boxes as you just said. It's a lot of boxes and so and a lot of times we get, you know, sort of the way maybe a Western culture thinks, right? Or some non-Deming approach and sometimes we call command and control. We get siloed into and OKRs and MBOs drift us towards this as well. We are like, yeah, like I'd like to make it better for the next box. But I've got to basically hit this number or do that thing, do that thing. And so what we're doing is creating these pieces that don't fit. 

00:36:23 

And so if you read Deming's books, the out of the crisis and new economics, he just goes on and on about the pieces that don't fit and why this doesn't work. Your analogy of the box is perfectly right because we fall into these systemic models in most of our Western culture businesses where we are forced to be within the box and our leadership is not giving us the ability to, so to think about the other boxes. They're sort of like perpetuating through, OKRs or MBOs or, you know, firing. And so if I'm a downstream box, if you will, I love your box and there's nothing I can do if you just give me terrible quality. 

00:37:04 

And if I can't change your box or I can't have a leader that can say, hey, how come y'all are not doing this together? And this is, I mean QA is like one of the more interesting things when you start thinking about Deming’s ideas because you're in a lot of cases, I know DevOps sort of tries to put you in front of the box, which is in the beginning, but traditionally you all have been on the end of the chain and you see it more clearly, you see your career probably is just war stories of disconnected boxes by the time it got to you. And well, wait a minute, why can't we all work together? Right? So yeah. No, I think it's a great perception and insight of how sort of took away from the book, and your career of like what you know works and what doesn't work. 

00:37:53 Lina Zubyte 

I think yeah, it had lots of great learnings for me. One of the points of those 14 management principles that Deming has is: cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. When I read this, I was thinking about the fact that after a few years working in QA, me and another QA were talking that we should make ourselves obsolete. That was sort of revolutionary. What kind of QA would like to make themselves obsolete? But the more I work in the field, the more I realize that it's not that there's no inspection or no checks or no failures. They are there, but we have to almost normalize it. So that Deming said to eliminate the need of inspection, I was like, wow. I'm surprised that this was said years ago. What are your thoughts on this point? And do you have any examples in the modern software context? How are companies working with this? 

00:38:57 John Willis 

Yeah. So I'll leave the reader to read the Hawthorn chapter, and in sort of a beginning of discussion on some work that you know, Deming learned a lot from a Doctor Sheward. And really that this whole idea of variation was a lot about reducing inspection at a telephone factory. Remember the 20s: telephone is like quantum physics. It's the most interesting thing happening. People are calling people that they haven't seen in years. You know, your aunt moves to California, you're in New York and you could actually talk to them. So this is a phenomenon. And they're like the Bell labs, the, you know, Western. They're building factories and phones that are at an incredible rate. 

00:39:37 

And a lot of inspectors and shoot figures out like this is a terrible way to do things, but if we pull it all the way up to the DevOps movement, the original character in Andrew Clay Shafer, who I mentioned earlier was the original one. In fact, he's the one that introduced the blind people and the elephant to the DevOps community. That's how I learned about it. But he also had this beautiful character in even before we call it DevOps.. He gave a presentation on agile infrastructure at a large conference before the DevOps term was even coined and he wrote this little picture and a lot of people have seen it. It's the wall of confusion. So the dev on one side of the wall, Ops on the other side of the wall, and the idea was we had to smash down that wall. And when I saw that the first time, like, this is my life, it's like the developers throw the coat over the wall and like I catch it, I say hey, it doesn't work. You send it back. And then like: it's not you, it's me. No, no, it's you. 

00:40:32 

That has been most of my career prior to DevOps and so we sort of worked on this idea of how do we break, crash that wall - we create collaboration. And what was the next wall? It was quality and QA. And I think early in DevOps it was just obvious and it's not eliminate inspection. It is like we've got these incredibly important intelligent people that know how to do... to stress and test the quality of this code. Like we took Dev and Ops and put them together, got rid of a wall. Let's remove the wall and see if we can't get them. And then so what we see early on in sort of the DevOps, you know a lot of lean and agile help promote this is - let's get quality in it to sign the requirements. 

00:41:20 

Why are we not doing that? Why aren't we letting quality build in automation while we build the code, right? And then you have things like test driven development and there's all sorts of debates on that. But the point is we're not eliminating your expertise. We are trying to bring your expertise into the fold in a collaborative way. And so that I think has been one of the more successful... I mean the Dev and Ops crashing the wall was sort of the step one, but I think probably the thing we saw more prominent in the sort of explosion of DevOps to the point that it has changed.... And it has changed economies. You wouldn’t have Uber, Airbnb and you know, I think you can go back and say, like, you know, Amazon and Google and Microsoft couldn't operate at the scale that they do now. If they weren't doing, you know, they started with sort of solving these problems before DevOps. 

00:42:13 

But you know, I think the better example is some of the commerce we've had over the last decade and a half, like the ubers, and that stuff was not possible with the notion that I know that because I like I was selling products to these companies, right? And a lot of it was open source. So you weren't really selling. But yeah, I mean it wasn't sort of eliminated inspection. It was you sort of integrate inspection. 

00:42:36 Lina Zubyte 

I really like this point. It's such an interesting conversation and I have so many more quotes marked down from the book. However, the time is running out, so I would like to ask you the last question, which is what is the one piece of advice you'd give for building high quality products and teams? 

00:42:55 John Willis 

You know, I think that I said earlier that I think a quote that I think that Deming would like to take back as they asked him what is, if you can give me sort of one sentence on what quality is he says it's reducing variation. And I think at the end of the day he probably would say you know, understanding variation. I think if you told me I had to give you one sentence I'd tell you it's profound knowledge. But if you would say no, no, John, I want one sentence. I'd say creating a culture that understands systems, like a systemic culture of understanding systems thinking. 

00:43:29 

I think that sort of breaks down and enables all the other sort of system of profound knowledge opportunities and then you know like you said, you didn't know it. I was the same way. I started hearing people talk about system thinking before I even sort of understood Deming’s work and then somebody said you should read Donella Meadows "Thinking in systems”. And it's a curse and a blessing because once you read that book, you will see everything in systems and you'll annoy your kids, your wife, your family, your significant other because you can't now escape, which is a beautiful thing, but it's also could be annoying to others. But yeah, systems thinking. 

00:44:09 Lina Zubyte 

I feel like I got hooked on systems thinking as well, and I'm definitely adding the books that got mentioned in this conversation in the episode notes, and we just scratched the surface of the topic. It's fascinating. I highly recommend everyone read your book and thank you so much for your time. 

00:44:29 John Willis 

Well, thank you for reaching out. I had a lot of fun, especially, you know, your background and all you know. So I think it's great. Your enthusiasm is infectious, so that's awesome. 

00:44:40 Lina Zubyte 

That's it for today's episode. Thank you so much for listening. All references and mentions you're going to find in the episode notes, and until the next time do not forget to continue caring about and building those high-quality products and teams. Bye.