What Would Dr. Deming Do? Modern IT Operations, Service Catalogs, and Configuration Management | Digital CxO Summit

Hey, everybody. Uh, this presentation is called What would Dr. Deming Do in Modern IT Operations, service Catalogs, and Configuration Management.

I know that's a mouthful, but I've been doing a lot of series about, uh, uh, we'll talk about who Dr. Demming is, but if he, he, he had died in 1993, but, um, he, he, he, he is pro most, one of the most prolific management consultants, management theorists. And so I, I've been using a lot of his ideas to, um, to just look at like, the things we're doing today and, and what would be his thoughts.

So my name is John Willis. I also go by the handle of Blu. And, uh, just, um, the reason I'm so passionate about Dr.

Deming is, um, I had my own sort of journey. It, it was about 10 year journey and, uh, just, I finished a book about a year ago, actually, but it was published here in August, and, uh, it's out on Kindle, and, and it'll be out paperback in January, but called Demi's Journey. It's Profound Knowledge, and we'll talk a little bit about that before we get into sort of the modern questions of what he would, what he would propose.

Um, but anyway, it's, it's a sort of long history of, uh, his life in journey and the ideas that he espoused. Um, who I, who me, when I, um, like I said, I'm John Willis. I guess I'm most probably known for one of the founders of the DevOps movement.

I had the fortunate opportunity to write the, uh, which I think is still considered a canonical book on DevOps, which is called the Devs Handbook with Gene Kim Patrick Debar, and Joe Humble. I've done about 12 books, including my latest, which is the Profound Knowledge Book over the, um, you know, uh, basically a 45 year degree. I mean, that degree, uh, career.

Um, and, uh, just, uh, some notable ones. Investors Unlimited is a new, a new book that came out about a year ago. And then, um, and right now I'm focusing on, uh, I work a lot with tech, strong tech, strong ai, but, uh, open context.

So they have some ideas that really have driven me towards this idea of like service catalogs and what we're Deming do. So I've been really looking into and working very closely with them, um, as an advisor. So, and by the, the Barcode is the link to find my book if you're so inclined.

Um, so, um, if you don't know Dr. Demi, you probably do. Um, you know, his quotes are sort of all over most DevOps presentations.

You know, quality is everybody's responsibility. Learning is not compulsory, neither is survival. It's a great one.

Um, there's some, there is some debate on which ones really were attributed. Turns out there was this, uh, vortex of every quote ever wound up as Dr. Deming.

So not all of 'em actually are Dr. Deming, or there are some of the ideas have been mutated, but that happens a lot with a lot of famous, uh, quotes. Um, in, in God we trust all others bring data that may or may not be his, but one of the ones I love is a bad system would beat a good person every time.

And, uh, and every system is perfectly designed to get the result that it does. Seems very simplistic, but so profound. Um, Deming, um, the, a couple of short things about Deming was he actually started out as a mathematical physicist.

Um, he really found his way in, uh, uh, in epistemology theory of knowledge, was a real student of that. And then ultimately his business card would say he was a statistician. He was also a professor.

I would say he, he delved deeply into psychology. Um, he was born of systems thinking from the earliest days he was actually an agriculturist. First, most people would think him as an industrialist.

Most of your industrial engineering degrees will cover something around him. And in my book, I proposed that he was a founder. I've, I've done these presentations called Demming to DevOps.

And, you know, so I would say he was a DevOps and, and a futurist because, you know, some of his ideas, uh, certainly in my book, in fact, the last third of my book would, is kind of what would Demming do in the cyber world. Um, and I really sort of looked through the sort of like, what would he do if, if when the executive order came out, you know, if they called him in. 'cause by the way, they called him in World War ii, they called him in the census.

They've called him in many times. So if he was alive, he probably would've got brought in, uh, by Biden for the executive order. You know, the whole solo winds debacle.

Um, there's really three main areas that, you know, again, this is, um, a half an hour presentation, but like three main areas if you really wanna understand. Dr. Demming really is, uh, lesser known as, uh, what, what is we call analytical statistics, but most people might have heard is just statistical process control.

I'll give you a little bit of overview of that. Probably most known for his 14 points. That's how I, uh, how I got, so in his, uh, his, his first real sort of book for, for the Masses was called, uh, out of the Crisis.

And in there he describes his 14 points of management, a lesser known, um, theory of his is what's called the system of found knowledge. That was in his last book, the year he died, uh, called New Economics. And really is the core of my book, you know, Deming's Journey to Profound Knowledge.

And, and I'll go through each one of these quickly. Um, the analytical statistics usually comes down to people sort of describing something called a control chart. Uh, it's a lot deeper.

Uh, but, and, and, and by the way, Demming coined the concept of analytical statistics. In fact, when he was doing it in the seventies and eighties, the, the academia was just furious with him. They like, you know, they, they were more sort of, uh, enumerated statistics.

You know, numbers, numbers matter. Um, but the, the idea quickly of, of a control chart is you take a time series of data and you basically use analytical statistics or statistics to basically draw the, the, the information that you're looking. And there's what's called an upper control limit and a lower control limit.

And then there's sort of medium. And, and again, it could be medium mode, it could be different types of statistical analysis, but you're trying to look for patterns and data, and the patterns are the things that tell you, this is where it gets really awesome. Um, like I said, I can go into a whole hour of this's, fascinating stuff.

I'll say this, that, you know, in, in modern times, we use this, this, these types of tools from anything from toasters to nuclear power plants. Unfortunately we don't use them in, um, in it in software development. Uh, this is a, a, a really good, um, from the software Kraken sub stack, um, Adam Hawkins, he sits, uh, up this, um, he takes SLOs from, um, or Ssli, sorry, SLIs from, um, from a Datadog, and he graphs 'em, and you can sort of see like this, you know, between the sort of the upper, the red dots, so the upper and control limit.

So this is sort of crazy data. And again, it would be interesting to analyze this here if we had more time. But, but the, the biggest thing was there seemed to be a noise pattern or, or a pattern all the way up until sort of April.

And then, then something went crazy, and then somebody probably tried to readjust. And then, you know, middle of May, we got back to, uh, to where we were. 99, they were outta their mind.

That's the blue line, right? But it was just, the data didn't show that, uh, Demis 14 points, um, that I'm not gonna go through all of 'em. I'll take a quick run to a couple.

I think five, uh, improved constantly and forever system, you know, production service, seven institute leadership and nine breakdown barriers. But this is how, if you really wanna understand Deming, you know, just Google Demis 14 points and you'll see that how much it relates to DevOps and how, um, you know, that's how I got sort of baptized by Deming is somebody challenged me to go ahead and read the 14 points and come back to them and tell 'em how, how this, this person didn't. So influence.

We've actually influenced agile, lean, and, and, and clearly DevOps. So never stop improving. Um, so to one of my, uh, security mentors is Shannon Leets.

Um, she's an amazing, um, hacker, um, DevSecOps extraordinaire. She wrote the DevSecOps, the original DevSecOps Manifesto. And, and this idea that she has is, um, always improving.

And so what she doesn't do is she doesn't do sort of reactive monitoring of, of security analysis. She does this proactive. She looks for, um, adversaries and she sort of tracks adversaries and can tell when they come onto the system, her system, when they, when they leave, and then she can sees the scientific method.

And it is the core of never stop improving, using scientific method, you know, to basically make predictions that if she does this, the adversaries will come less or they'll stay shorter. Um, the, um, the don't manage don't lead, right? The, a great example is this is how we manage our systems today.

We're usually, you know, we, we, we create these artificial buckets of P ones, P twos, p threes, whatever. And most organizations can only have, they only have enough resources to manage the P one. So they just sort of, the p twos don't even get managed.

And, and there's sort of an arbitrary notion of what, you know, like somebody just decides, well, that's a P one. I mean, there's, I know there's criteria, but let, let's face it, it's not operationally defined with absolute clarity. So the, the fine line between a P one and a P two might be somebody wrote on a napkin the amount of time it was down, right?

Um, the longer point is that we could be managing this way differently, probably through the statistical process control, looking at data, let the data tell us what type of incident it is, right? And again, this, uh, I talk about this in my book, both of these, um, all these sort of points. I, I have an example in my book about, and then, uh, the no silos is, uh, another sort of the interesting one.

This was, um, the Equifax breach, um, if you can remember that, right? And there was this, um, it was sort of a, um, a Conway's law organizational structure that basically, you know, the breach was the breach. The real problem was all the disorganization that happened to deal with the breach, right?

So everybody's gonna get attacked. The question is, how is your organization prepared? And it was actually the house of representative committee investigation wrote a, the brilliant report about how the CISO reported to the chief legal officer, not to the C I O or not to the C E O and, and all sorts of hijinks.

Um, so the idea, and then the last piece of those sort of three, right? Is the system profound knowledge. And this is the thing I think I find most interesting about documenting.

'cause what he said is, all systems are complex, right? These are all complex systems. And complexity is part of our, you know, system thinking complexity.

And the way we have to understand 'em is we have to apply these four elements, like a, a, a, you know, sort of the multiple parts of a lens of a camera to be able to understand. And we can't use all four of these. They have to work in conjunction, then we won't really understand complex systems.

And first is the, the epistemology theory of knowledge. How do we actually know what we know? Um, you know, you've probably heard of plan, do, study, act, right?

It's really just a form of scientific method. It's hypothesis thing. The only way we know is through an epistemology.

The, uh, the way to sort of, um, empirical evidence. We have to test it. We have to check the results.

The second, um, sort of element is theory of variation. That's statistical pro control. That's analytical statistics.

That is, okay, how do we know what we know? How do we sort of understand what we know, right? Like in Datadog, SS l i, like, we get to see the data.

The third is critical, which is how the theory of psychology is how people are motivated, right? We could have all the data and we could have all the knowledge, but if we don't understand your intrinsic or extrinsic not notion of how something works or, um, your biases like the, the built in human biases, right? And then last but not least, a systems thinking like integrate all four.

It's, it's, you know, the way you need to look, you know, always look sort of outer, outer parts of the system. And, and again, well, my book is about his journey to pick up how he picked this up in Japan, how he picked it up in, uh, different parts. So the first story I wanna tell is, if you haven't heard a Knight Capital story, right?

This was basically a system admin. Um, is this, this is a configuration like service catalog configuration. There was some changes made to this company called Knight Capital.

Knight Capital was at the time the second largest high frequency trading on the N Y S E and nasdaq. Um, and so through, again, some form of, uh, mis hygiene. And this is, uh, you know, um, uh, you know, could be considered a counterfactual 'cause I'm just going by some data.

I wasn't there. But basically, um, a mis comma on an eight cluster deployment. So basically one of the nodes in the cluster didn't get updated, happened to be a trading algorithm.

And, um, so what happened was to just, again, another set of complex conditions, um, they literally wa they, they, um, they lost, uh, 440 million in 45 minutes. They were outta business basically in 24 hours. Um, and, and so like, again, this idea of like the, the, the way we think about how we manage our catalogs and our infrastructure and all that, right?

And again, it's easy to say, but it is, this is like as glaring as it gets, you know, second largest, um, high frequency trader out of business in 24 hours. 3 billion. And, um, they, I think the leverage was in the billions, like the, the amount owed and how who had to buy things out to, to clear up the debt.

Um, so they got an, they got a, um, a cease and desist of course in the SS you C, which is again, something I don't think anybody ever wants to get. And, and what I did is I took the cease and desist and I played it through Deming's. Again, this is 2012 demming thousand 1993.

But if Demming would've looked at it, he said, he would say, you know, they clearly didn't know their environment. Again, if anybody who understands the notion of counterfactual, we weren't there. But even what, neither was the s e c, that's a strong complaint from some of my friends.

But, but if we can just play along, we could say that they really didn't know their environment. They were making a trade to a, I mean, there's highest impact from a monetary perspective code you could even imagine. And it was clear they didn't know their environment or didn't safeguard their environment.

Um, they didn't have insufficient, uh, or, uh, insufficient to ensure orderly installation of code, right? Again, why was the, what was the sort of process built? But the bigger thing was, I've, I've talked to, you know, after this, I went around and talked to other people who worked high frequency trading, and they said, you know, like, these things can happen, but they won't happen for 45 minutes.

There are circuit breakers, there are, you know, like worst case to happen in a five minute interval, right? So there's another variation or statistical process control, or what's normal, what, you know, the, the, the, the, the trading. Um, you know, it's funny, they, they had put in, if you read flash crash, they, uh, after that flash crash, they, they went ahead and put circuit breakers in the stock market, but they, those are for price increases or drops, but not for volume.

So this was before they even had volume circuit breakers in the, uh, exchanges. And then, like I said, psychology, there was a whole, um, like was there, was it reasonable guys, at least the s e c thought that there was, um, there was not really reasonably designed, uh, response to significant and compliance incidents, right? There wasn't sort of a hygiene of like, Hey, don't, and, and that was typical of Wall Street back then, right?

Like somebody raising their hand and saying, do not deploy that code. You know, like, how dare you, you, you even suggest that my code not be right like that. There was a lot of that in Wall Street, um, probably still is too.

And then, um, and this is my, this was the secs were, it is not mine. Inca inadequate understanding of the whole system. So the other thing I I've spent some fair amount of time on is like the whole notion of SS r e and how Demming would react.

And I'm giving you the sort of the, the, the, the, the, um, the, the sort of the fire hose version of this, right? But if we look at the way we talk about s r e, we talk about SLAs, Sloss, and SLIs, right? And, and you really, and I, I'll say this, you know, I'll, I'll leave you with this.

Demi hated MBOs. He hated management by results, and he would've hated OKRs. I have old presentation on that and, and, and like pinging me, or we have a conversation or read some of my blogs to go into that, but he would've loved SS r e because the idea that like what he hated was the idea that a result would be tied to something that you really don't have control over, right?

And, and so like, so you get a reward or you get sort of in trouble or, you know, get, you know, whatever you maybe get fired because it's something that the system is in control of. The person is, in fact, Demming said 94% of all problems are system related. Only 6% of human, in fact, if he was alive today, I think he'd say 97 are system related, and three, you know, 3%.

But, um, but the reason why he would like the S S L A, you know, the SLOs and SLIs is SLIs really are your knowledge. It's, it's decoupled from some arbitrary thou shout, sell 10% more this year, or this team must improve revenue 10%. This is actually built on, you know, the, your SLIs or several indicators are hypothesis.

You know, we believe that the data we tracked the SS l o is the sort of the tracking that the, the, the sort of the, the question of how do we, you know, the, the s l i is the how do we know what we know? The s l O is the, you know, how do we understand what we know, right? And then the psychology is that sort of decoupling.

Anyway, um, believe me when I tell you Deming would've loved sre. So then the interesting thing I like about, like, about the, the, the broad spectrum of service catalogs, infrastructure, all the things that we sort of, that we deal with managing our infrastructure, is that Demming would've loved this idea of social technical engineering. Um, uh, there, there's a whole body of science that this came out of coal miners and, and sort of psychologists and, and, uh, sociologists who studied coal miners, um, tris, if you want to look up the, the sort of the sources of this.

Um, but, but the idea of the social teal engineering for theming about, and, and so here, the first off, let's start with, I mean, like what he would've thought about best practice, and he didn't like best practice. In fact, in his, uh, new economics book, he clearly states, when you think about the list of so-called best practices, you realize they are just a hodgepodge of beliefs that often contradict one another, right? So this notion of cargo culting best practices, um, you know, like the, the, you know, is sort of as we sort of think about the, kind of the ante pattern of social technical engineering, right?

Um, also he went on to say, best practices are seduced, or I'm sorry, are seductive. Because when we see an organization that is winning with products or service, our natural childlike reaction is to want to copy what that organization. So, so let's start off the premise is that, that, you know, in the social technical engineering construct, the first thing we do, the first thing we don't do is just look to see, oh, what's the best practice?

Or if you hear somebody come in and start mandating best practices, you should basically run, because Demming would basically yell. Um, and so if we look at things like agile, um, on best practices or thinking about like how Demming would think about it, like, I think he would be pretty excited about, um, you know, ensuring timely, important work, easily adaptability, clear visibility, visibility. A big part of that variation, 'cause it's not just the super parts control, is like control charts to, to visualize the patterns, the things he probably would've said were or lacking profound knowledge is, you know, the, the, the multiple interpretations in an organization of what agile really means, right?

Do agile. And then this group says, I don't know, let's figure it out for ourself. This group, uh, confusion, same thing, confusion of flavor to adapt, um, you know, the training and certification complexities, right?

That when you get into this idea that there are sort of belts or, you know, there are belts or six Sigmas belts, but, but these sort of, um, bands of like, you, you get this level sort of, or a scrum master or, uh, those things sort of erode the actual learning. And Deming was, you know, if you look at 14 points, he'll, he'll clearly describe, you know, some of the, the, he also has this idea of deadly sins, right? The seven deadly sins.

Um, the Scrum certified project matter introduces radical changes, right? Like, and the sort of change happening, which isn't team-based, right? The, that my first introduction was Scrum.

Like, I went to say something then, like, they handed me this booklet about and said, you can't talk. I'm like, yeah, this doesn't really work for me. Um, um, you know, that difficulty in seeking advice from peers, um, you know, um, motivated team members adapt to changing agile approaches.

There's just, you know, it's it, this idea of just putting one word around something and saying, especially when leadership says we're doing agile or we're doing safe, you know, so it could go on and on about safe. Same problem, right? Like, like that can be, it's not a problem.

Like, like, again, a lot of people would argue the benefits or disadvantages of safe, but, but it isn't a problem like figuring out how to do safe yourself. It's this idea that you could use this word as an abstraction to just, you know, bat people on the heads, bang, people on the heads, um, microservices, right? I think Deming would've been pretty excited in some of the aspects, clearest preparation of responsibilities, scalable and flexible systems, right?

From a profound start. The places where, again, very similar, where I think he would've said that lacked profound knowledge is independent management by teams like this. Each team's making his own decision.

Teams are sort of, you find that like the whole goal of Microsoft probably should have been a teams of team of teams, but actually doesn't play out that well. And more often than not. Again, that's not an indictment on microservices.

It's an indictment on human behavior. Um, you know, lack of consensus on architects, same thing. Uncertainty about the a p i definitions, the documentation increased meeting overhead again, um, you know, I don't, there's not a lot I've read about demming in meetings, but it drives me crazy when I go into these organizations and like, they're spending probably 30, 40, maybe 50% of the time in meetings talking about the things that they're gonna do.

I think demming, if like he, if he was able to do like a qualitative analysis in a modern organization, he would be furious. Um, you know, and then you have the risk of parallel development. Again, that comes back to, you know, Demming was very much a system stinker.

Like any, anytime he saw an organization sort of siloing or, or sort of making these kind of mistakes, he would, um, in fact, he was known for getting angry. And, you know, he would yell at le yell at CEOs, you know, in fact, CEOs would try to hire him, and he would basically lecture them before he'd even accept the gig, right? Uh, C I c D, um, you know, I, you know, again, Demi's very technical.

So like, it not the, like, I can't, Ima I think he would've probably done some commits and merges. I, if he was alive today, um, probably wrote, written some code. I think he'd be all over generative AI and, uh, graphs, we'll talk about that in a minute.

Um, but the deployment freedom, anytime the sort of un constraints of humans basically feeling good about what they do, accomplishment, giving people the, the ability to actually complete meaningful work. Um, so those are all the things that, that are, uh, big tenets of cis ent. Why we sort of love this, this concept, you know, the core of DevOps not the only thing, but, but a core principle.

But, um, but I think here again, like, you know, the areas where we get into sort of lack of profound knowledge, you know, localized change, optional changes. You have this sort of, um, mutation, you know, I've gone into shops where there's, you know, there's probably, you know, a hundred different jenkin files, constructs, different templates. People are using it differently.

So now you've, you've taken this great idea and you've turned it into this, um, sort of beast, um, um, you know, critical supply chain, like the, the whole DevSecOps, things like the, all these sort of flow and supply chain for software supply chain that doesn't include security or security is still an after effect, right? That's, you know, one of the most famous stories related to Demming is his work at Hawthorne and Hawthorne was probably where Dr. Shoot created the control chart.

Really, the control chart story, by the way, is the original shift left story of how a factory needed to get rid of physical or minimize the physical inspection, uh, infrastructure's code. Again, I think the narrative is, is um, is the same. Uh, there's, you know, I, I was the ninth person in at chef and my, you know, I, I, I, I, I was, I grew up on infrastructures code.

You know, I, I'm a big proponent of, you know, configuration management. Uh, so there's some beautiful things of infrastructure code that doesn't really have to, if you, if you stayed with me this far, you probably already know those. But again, if we get, if we look at the sort of the lack of profound knowledge, if you remember those four elements in the lens, you know, there's still some cri there's sort of this mismatch of, and we have to sort of, you know, excuse the, um, American football, um, punt, but we punt on the systems that just a little bit too hard, like mainframe systems, which were a big part of our some old legacy Java code, right?

So we, we wind up having, again, this little bit of non-system approach. Infrastructure code is brilliant and it's brilliant for the things we manage. Um, but, um, you know, so, so that we, we tend to take care of the easier things.

Um, we still have like how, you know, again, there's some great work on testing and test driven, um, infrastructure or test driven development for infrastructure as code. But again, like this sort of, um, this, you know, sort of missing match, you know, sort of jagged edge of like, it sort of diminishes the value. Um, and then there's a lot of, you know, unfortunately there's been a lot of choices, tructure as code, you know, going from sort of CF engine.

I've been in shops where they have, they're running certain things on CF engine, they're still running certain things on puppets, certain things on chef, you know, Ansible, you know, now you've got Terraform, now you've got the open tf, right? Like, again, it, like not a bad thing that all these happen, but it could be a bad thing if you've got now what, five different sort of implementations of infrastructure code running around. Um, so then going back to the, the organization, I've been working with this open context.

So the question then is, you know, what would Demi think about all this and what, you know, what we'd be interested in. So the questions that you, we would wind up asking is, how do we know what we know in an infrastructure? You know?

And, and there's always been this longstanding notion of can we build a configuration management database, A C M D B? And the reason I've been interested in the open context team is this has been like, I, you know, my whole career starting back in the eighties have been about how do we get an effective way to understand what we know? And there really has never been.

And, and I think the, the interesting thing now is, so, so the questions are should like, again, my 40 plus years here, you know, why is the component here? What, what are the systems depend on? Or who wrote the code?

You know, are they still here? Who, like, where are these people? I've been in qualitative analysis where you ask questions and nobody even knows who owns that code or that system.

Um, you know, where are the environments? What are the customers that depend on it? Like, like those questions, you know, the what is, you know, they lead to friction.

Difficult troubleshooting, of course, more severe incidents because you can't even understand the dependency structure or the ownership, or how do you get into the war room. It creates increased re risk inefficiency and toil. And, and then the, the cognitive overload of all this, you, again, Demming was a big fan of joy of work.

People ha giving the capability to do meaningful and joyful work, which is productive for the organization. But we put these things in the way because we, we make these decisions like, you know what, our C M D B will only be 30% accurate, and we just have to live with that, right? Well, what you not just living with the fact that it's, it's 30% accurate.

You're living with all this friction difficulty burnout. So again, there's a little bit of, um, so, but imagine that, imagine that you could, and, and let me just skip to it. What some of the modern people who are thinking about, and open context is one of many who are thinking about how do we solve this problem in the new world?

We have some extra killer tools. One is we can get scoop up a lot of information from GitHub or whatever your variant of GitHub GitLab like, so like, it gives us so much information that we didn't have, especially as companies sort of move more and more and almost exclusively to these models. We also have this really powerful, like the, the maturity of graph databases.

This is an example, very simple construct. You don't understand graph databases. You know, you got, you got two pears and then two people in a car.

You set the relationships. Now think about using that for like, this is like, oh my goodness, I wish we would've had this 30 years ago. I mean, we did, but not, uh, only like, like expansively complex data scientists could have used it, but we have this now.

In fact, it gets even more interesting with degenerative AI and lms. Now you have graphs that can, can feed data to an l m You have LMSs that can feed data, large language models to graphs. And now, so you get this interesting tooling subset.

So imagine you can sort of pull out everything from your cloud configuration, everything from GitHub, and now you can be not 30% accurate, like 70, 80% accurate. And, and one of the things I learned about configuration management over years, when you're 30% accurate, you're never gonna get accurate when you get above 60 or 70%. 'cause I've worked on this problem many years.

You actually get a sustainable level of accuracy in one scenario. You're just so below the threshold that you just never, it, you know, it, it, it, anybody who uses, you know, or tries to use it for effective incident management or your configuration is, it's just not trustworthy. But once you get to a certain threshold, it's reasonably trustworthy.

You put more attention, more spotlight. And it actually, it's, it's, if you have, I, I know we've gone a little bit over, but if you ever read sort of some of the books about how, uh, New York, um, in the seventies came out of the idea, it's the broken windows. You know, it's like if you see it is an old house, abandoned house, and it's got broken windows, if you, uh, people, you know, kids will just throw rocks, break more windows, but if you clean it up, people aren't just gonna throw rock, you know, rocks at windows of a clean looking house.

And that's what they did in the subway systems. They, they cleaned up New York City based on the broken windows. It's, it's really sort of very similar to the, I know it's kind of a weird jump, but it's similar to C M D B if it's, if it's terribly inaccurate, it's broken windows.

Anyway. So, um, like I said, I, I hope you enjoyed this presentation. Um, I would encourage you, if you don't, if you wanna learn more about Deming's journey, um, I, I say it's sort of like, um, uh, uh, Michael Lewis or, or Bill Bryson's version of this, this, this character called Edwards Demming and his journey throughout his career.

Well, thank you very much.