Tactics for Tech Leadership Podcast

S2E22 – Making Use of the Theory of Constraints

—

by

Andrew Parker
in ,

Show Notes

 In this episode of the TTL Podcast, hosts Mon Chaio and Andy delve into the Theory of Constraints, an approach developed by Eliyahu Goldratt. They discuss how this methodology applies to various systems, including technical, people, and cultural systems, emphasizing its importance in software leadership. The hosts explain the core principles of the theory, such as identifying and elevating constraints, and explore its practical application through examples in both technical and organizational contexts. They highlight the necessity of continuous improvement and systems thinking, noting the challenges of aligning this approach with personal and organizational goals.

References

​

Transcript

Andy: Welcome back to another TTL podcast. Today, Mon Chaio, I thought that we’d talk a little bit about theories, specifically theories of constraint. The theory of constraints, maybe. The Eliyahu Goldratt’s theory of constraints. Now, it’s, it’s not quite our normal thing, I think, because normally we’d say, oh, what’s the scientific literature say about this? But this is more of like a philosophy, a mode of thinking that has outcomes more than an empirically studyable thing. Now, some of it is about, like, queuing theory, Theory of Constraints. But I don’t think we’re going to get into that too much. Maybe we will, maybe we won’t. But, yeah. But that’s what we’re going to do, Mon Chaio. What do you think about that?

Mon-Chaio: think that’s good. But why, Andy? So, I like talking about more philosophical things. I think, there is time and space for that. And I actually think it’s really important that we not just base ourself to things that are known, right? We ponder and philosophize about things that may be unknown and may be unknowable.

And what does that mean for us? I think that’s really important, but why Theory of Constraints? We are a podcast about software leadership. So what does this mean for our listeners? Why would they not press stop right now? And I don’t know, go listen to a different podcast.

Andy: So I have a really good summation of leadership. It’s one of many, but I like this one. Leadership is about defining what good looks like. So, if we take that, Theory of Constraints is a way of thinking about systems and making them better.

So theory of constraints, you could almost say, is how you get to define what good looks like. So at its essence, that mode of thinking is leadership. is what I would posit, why we should be talking about it.

Mon-Chaio: I love it. And when we’re talking about systems, are we talking about technical systems, people systems, cultural systems? What are we talking about here?

Andy: Can I just say yes?

Mon-Chaio: Yes, of course you can say yes. It was sort of a leading question, wasn’t it? I kind of knew what the answer was.

Andy: so yeah, we’re talking about all of them. Now, any system can be analyzed. I mean, in our very first episode on BART, we were talking about a system that’s really for analyzing human systems, people systems. Theory of Constraints, though, it came from manufacturing and looking at manufacturing systems. But since then since I think it was about the 70s when Eliyahu Goldratt first started proposing it, I think it’s been applied to a lot more.

In fact, I know it has been. So, ideas from it started showing up in Agile literature back in like 2006. There were a blog post from people at ThoughtWorks. I remember coming across it around 2008 or so. There was a master’s paper by Clarke Ching on “the project manager’s conflict.”

That there’s this inherent conflict about, do you allow change to scope and, and functionality, or do you not? Because a project manager wants to get their project done. The analysis in that, that was all Theory of Constraints. So, it works for things from how you design your distributed system so that you don’t overload a database.

This is stuff that I think software developers we would always be familiar with. But it also applies to who’s doing what work? When, and why, and how did they get it?

Mon-Chaio: And I think probably more interesting to us is that latter portion that you mentioned. You did mention queuing theory. I tend to agree with you that I don’t think that we would want to touch on queuing theory in this episode, or maybe ever. I think that tends to be more of a technical constraint problem.

And when you’re talking about overloading databases or, or load balancers and firewalls or how many parallel processes can run. I think that’s really useful. But probably it would be more interesting for us to talk about the people systems. Yes.

Andy: Yeah. And, queueing theory could show up in there, but I’ll, I’ll try to stay away from it. I’ll, I’ll, I’ll keep my grubby little, little’s law fingers off of, off of the people side of things for a minute. So let’s talk about Theory of Constraints and what it is, because we kind of talked around it. So at the highest level, Mon Chaio, what is Theory of Constraints?

Mon-Chaio: If I could summarize it, at least my understanding of it, theory of constraints says that in any system, there is some sort of bottleneck or constraint. And only valuable work in improving that system. is to relax that constraint in some way, improve that constraint. If you put improvement projects before the constraint or after the constraint, it is essentially wasted work.

That, I think, is my understanding of how I would describe it.

Andy: In Theory of Constraint Literature, you might hear people talking about chains. So, they, they think about the world in terms of these chains of work that have to happen. And that a complicated organization is a whole bunch of interconnected chains. Now, you might have a few independent chains, which is why it’s Theory of Constraints rather than Theory of Constraint. Which means that there are a few special cases where you might say that there is some other part of the system that if you improve that at the same time you’re improving one constraint. That you could work on two constraints at once. That there could be two constraints. But it’s better to think of those almost as two separate systems. because they’re kind of like in independent worlds. They have this idea of there is always a constraint somewhere. The constraint may not be under your control because your system extends beyond the boundaries of your immediate organization. So the constraint may be in your suppliers or in your customers.

Mon-Chaio: hmm.

Andy: But if you want to improve the overall flow, you have to understand that constraint, and you need to address it. And as you said, if you address a a non constraint work point, it’s kind of wasted effort, because it won’t change the overall system. Now, we could talk about improving someone’s life could be a change that you’re trying to make as a, as a manager or a leader.

That’s not necessarily wasted effort, but if we’re talking about the measurement of the overall, like, profitability or throughput of the system, which is what Theory of Constraints leads you to, to think about, yeah, it is somewhat wasted effort. So

Mon-Chaio: And We talk about many different types of systems. We mentioned there’s technical systems, there’s people systems. Even within people systems, there’s many different types of people systems. And so, I might imagine that you could use theory of constraints to analyze how to make people’s lives better, right?

How

Andy: yeah, yeah. What, what is the constraint on their happiness?

Mon-Chaio: right? And that, that system may be slightly orthogonal or not quite parallel with your value production in terms of shipping product system, and so you may have different constraints on those different chains that you have to fight through.

Andy: I like that because, you know, a central thing of Theory of Constraints is measurement.

Mon-Chaio: Mm hmm.

Andy: being able to measure a bit so that you understand if you’ve actually affected it or not. And by selecting a different measurement, like you could choose the measurement of profitability and throughput, but you could also select the measurement of happiness and fulfillment. And as you just said, they kind of produce different systems that are overlaid on the same group of people.

Mon-Chaio: Right.

Andy: So that’s, that’s kind of, that’s an interesting way of thinking about it. I hadn’t thought of it that way before. Yeah.

Mon-Chaio: And I think you mentioned in our earlier discussions . about causal chains and tree analysis, that sort of thing. Which we, we’ll probably get into a little bit later, but I think, you could then take those two systems and say can I combine them into a single system with a single measure? By figuring out what triggers what?

I do think that that’s people tend to like to do that. In fact, I tend to like to do that, too. It’s easier to think in terms of one system than in multiple disparate systems that may or may not relate to each other, right? That’s all that’s why in software, we do abstraction layers, so we can think in terms of one system without worrying about all the complexities of the underlying stuff.

One thing that I thought about when you mentioned this topic was why even talk about it? This idea that there are constraints of the system and you should work to remove those bottlenecks, seems uncontroversial. Certainly in the technical realm, it’s relatively uncontroversial, right?

If we say, this load balancer can only handle two requests per second, let’s slam 30 more services behind it. It seems uncontroversial to say, no, let’s not do that. But then, at what point is it controversial and worth discussion and worth exploration? What are some examples, maybe?

Andy: I think the useful thing, and we can do this by analogy, taking that load balancer and the number of, of services behind it. So that load balancer can handle two requests a second, and you’ve got a web server, this is a really bad web server, it can handle 0. 5 requests a second.

So we should be able to have four four servers behind that load balancer. And then if you added a fifth, well, you’d say, it’s kind of pointless. And this, this is now the idea of theory of constraints. You add that fifth, it doesn’t add anything to your system. In fact, it’s wasteful. You’ve got a fifth server running, you having to pay for that fifth server, maintain that fifth server.

Now I won’t get into redundancy, but you might do it for other reasons. But if, if your reason is to improve the throughput of your system, that fifth server is not doing anything. So. Theory of Constraints gives you, at its, at one part of it, it’s a, it’s a several different pieces, but its most famous part is these five steps for resolving constraints.

So the very first one is identify the constraint. So we would say, well, what’s the constraint on this? We want, we want more requests to be going through. So the constraint is the load balancer. Now, how you identify that constraint can be really complicated, and we’ll get into that a bit later. But let’s say you first identify the constraint.

Now, the idea is now you have three steps to go through. The first one is you decide how to get the most out of the constraint. So it can do two requests a second. So what does it mean to get the most out of it? Well, maybe it turns out that once a second you have Pingdom hitting your website and just doing a check. So you actually now, you only have actually one request a second from your customers that can actually go through. So the very first step says decide how to get the most out of your constraint. The subtext of that is take unnecessary load off of it. So, maybe we don’t need to know at second granularity, whether or not our website is up. So let’s turn that down to once every five minutes. That’s good enough for us. All right, cool. So we’ve, we’ve just freed up 50 percent capacity on that. Excellent. All right. So next step is you support the constraint. So you subordinate everything else to this decision that you cannot add more load

that’s not customer load onto that thing. And so we set in policies that the testers have limited time that they’re going to use it. We set up a second a second system, a second load balancer that we send our customer support people through. All of our decisions say you do not get to put anything more through that, that path.

Okay, cool. And all while we’re doing this is we try to figure out how do we need to elevate this constraint? So that’s the fourth step. You elevate the constraint. You invest resources. So this is where you would look at and you’d say, all right, how do we do this? Now, let’s assume that we’re in a world where it’s not as easy as you just say, Oh, it’s an AWS ALB.

And you just call up AWS and say, can you, can you lift that rate limit?

Mon-Chaio: Hmm. Maybe you don’t have any more money to give AWS.

Andy: Yeah, maybe it’s you would have to pay for that or something else. So you have to think of something else a little bit more complicated than just calling them up. Or maybe you don’t. Maybe that’s all you need to do. Say, say it’s you’re old school and you’ve got an Apache mod rewrite proxy that is doing your load balancing. All right, so now maybe you need to do some performance tuning in figuring out how long the Apache worker processes should be running, and tuning it that way, or memory profiles, number of child workers, those kinds of things. You’re going to tune it for a while. And after some tuning, you get it up to handling 40 requests a second. Cool. Now you get to repeat, and you get to identify the constraint. And now maybe we’ve just we, we’ve done this and our system is now running just fine. There’s no constraint at the load balancer. There’s no constraint at the application servers. There’s no constraint in the database. Our constraint is now outside of our system. Our constraint is our users requesting things from us. you get into the thing of, well, what is the constraint then? In that case, the constraint that is under our control is marketing and sales, probably.

Mon-Chaio: Mm hmm.

Andy: How do we drive more traffic? How do we drive more sales of our service? So now you get back kind of into that human system. And you can apply these exact same things. You identify the constraint, and you find out that it’s Joe in marketing. He’s stuck on his marketing tasks. He can only do one call a week to, to get a partner going.

Mon-Chaio: Mm hmm.

Andy: So then you decide, how do you get the most out of the constraint?

And you discover that the unnecessary work that he’s doing is, well, he actually also supports the sales team and their graphic design. And he does UX stuff for the development team. So you’d say, well, let’s offload all of that from him. Let’s shield him from that because those things are not our constraint anymore. So, get, get Joe in marketing doing these referral calls. Getting, getting in front of people, doing all of that. And then you support the constraint. So you, you start setting up those policies where you say, don’t, don’t go, go and call Joe. He is busy. No sales. You are not getting that new marketing material because you don’t need it.

That’s not what we need to be doing right now. And then you elevate the constraint. You say, well, actually let’s hire a marketing agency and Joe can then direct them rather than doing it all himself. And so you do the search and you find a marketing agency, and then you’ve changed your constraint again, because now do all the marketing you want.

And you’ve seen amazing uptick and you’ve got a whole bunch of new customers and, and the constraint moves again. So this, this is applying the theory of constraints.

Mon-Chaio: Seems great. And as I mentioned before, I think a lot of this tends to seem uncontroversial, but people don’t really do that, right? Or they less than, less than you would imagine. And I think for me, in my experience, it hasn’t really been that people identify a constraint, agree to what it is, and then have problems doing maybe steps two, three, or four.

They may not do them perfectly, and they may not have the vocabulary to do them, but I generally don’t find that it’s one of those things where, oh, well, now we’ve supported the constraint, but we can’t figure out how to elevate it, or we don’t elevate it, or whatever. I feel like by the time you get into that process, people are pretty good even without the vocabulary of being able to move through it.

I, I see you don’t perhaps think so.

Andy: What I see happen most often is you identify the constraint. But then the next three steps are about coming face to face with that trade off.

Mon-Chaio: Mm hmm.

Andy: Because what, what you have just done, if you truly, at that full system level, adopt Theory of Constraints approach. What you have done is you have given the organization an over, overriding goal and policy about what to do with that particular resource, person whatever.

Mon-Chaio: Mm hmm.

Andy: And that will come in conflict with people’s personal desires and goals. So, in, in the example I said where it moved to marketing. The sales team and the sales director might be saying, I have. I have an OKR, I have a goal for this quarter that gets me my bonus to update all of our sales materials. I need Joe to be doing new, new graphics for me.

Mon-Chaio: Mm hmm.

Andy: But the thing is, for the organization to actually do better, those marketing, those sales materials, they are not the constraint. They do not matter enough to override taking the load off of Joe. And that’s where I see this often fall apart, is people have their own personal goals that they, they optimize for above the actual global goal.

Mon-Chaio: I think that’s a problem that may even be sort of more solvable at the company level, right? If you update Joe, or not Joe, I can’t remember, the sales guy, marketing director, whatever. If you update his OKRs and say, sorry, these aren’t your OKRs, right, I think. And to your point, that would be one way of confronting the constraint head on.

Andy: Yes, absolutely.

Mon-Chaio: I think what I generally see is even a step before that, where people aren’t really willing to confront the constraint head on. So let me give you a, a non rare example I see over and over again. Often in product development, the engineering, the software engineering group tends to be the constraint.

Andy: I, I

Mon-Chaio: There’s a lot of reasons for this. They tend to be very expensive. They’re an expensive group. So the size of that group generally is constrained by dollars. How many times, Andy, in your career have you seen companies put more and more people, time and resourcing into upstream activities. Things such as customer requirements gathering, spec writing, that sort of a thing. Where projects, bugs, features, end up queuing up and you have this queue that spans two years, three years, four years, and you’re putting in a bunch of effort into that when the funnel of what actually can be done in your engineering system is much, much, much smaller.

Andy: Okay, yeah, let’s take that as an example, because I think we can all agree that that happens pretty often. In fact, at the CITCON conference that I was at this past weekend, there was a discussion about, well, how do you manage your backlogs? And after people went on for a while, I eventually said, the easiest way to manage your backlog is to delete it.

Mon-Chaio: yep,

Andy: We’ll get into that some other time, but, but this is a big issue of how do you manage these large backlogs of requests and bugs and everything else. Now, I would say, so when you said that the bottleneck is development, I’m not 100 percent certain. That looks like development. That looks like, because if you take like the, the lean approach of where does inventory pile up.

Mon-Chaio: mm

Andy: You can say, Oh, well, inventory is piling up at the start of development. That’s what, that’s what the backlog means. But there’s another way of looking at it, which is how much of that inventory pile is valuable work? Where if you did it, there is an absolute payoff that you’re guaranteed to get. And so I think, And this may, this may be two sides of the same coin. I think it’s not necessarily the development’s the bottleneck, but that the system is full of valueless work. And so it makes it hard for us to understand where the real bottleneck is.

Mon-Chaio: hmm. Interesting way of thinking about it. I think it may be two sides of the same coin. If we talk about measurement, right? We talked about that earlier in terms of being able to measure the output of a system. And so you say the measure of our production system is being able to deliver features to customers that are used.

Andy: hmm.

Mon-Chaio: Whether it’s an actual bottleneck of inventory piling up or a bunch of wasted work happening. think the bottleneck ends up being the same. Now, the solution to the bottleneck may be different, right? The solution to the bottleneck may be, well, actually, we can eliminate this bottleneck. To your point around taking away all unnecessary work that pinger, right?

Making it every five minutes instead of every second. We can say stop writing specs every day, right? one spec every 10 days. Write one spec every 20 days.

Andy: So theory of constraints comes along with these five steps. It also has what’s called the TOC thinking process. It’s also sometimes called the TP tools. I’m looking at the tocinstitute. org pages about this.

Mon-Chaio: Mm

Andy: And what they’re about is trying to answer the fundamental questions, which are “what to change”, “what to change to”, and “how to cause the change.”

Mon-Chaio: hmm.

Andy: So this is, this is kind of like those fundamental questions going through those five steps. Now, the, the way that you identify where the true constraint is, is you do something called a current reality tree. At a current reality tree, you, you first start from what they call undesirable effects, UDEs. It could be that those undesirable effects are this long backlog. Now, I would challenge someone who puts that down as an undesirable effect, because I would ask the, the famous, so what question.

Oh, we have such a long backlog. So what?

Mon-Chaio: Mm

Andy: Well, we spend all of our time looking through it to decide what to do. Ah, okay. Maybe, maybe that’s the undesirable effect that we’re looking for. So you take that and now you start going through the causes. Why are we spending so much time looking through this? And you might, you might start expanding that out.

And these are little diagrams and we’ll link to some of these and there’s a video that explains how you produce one and then how you read one. So you might start from We’re spending an inordinate amount of time organizing and finding things in our backlog. Okay, why? Because we have a meeting to go through every single item every week. Okay. And we have to update information on every single one every week. Or something like that.

Mon-Chaio: Mm hmm. Mm hmm.

Andy: Well, right there we have a pretty clear possible target for our, our constraint, which is that our system, our policies are telling us to waste time looking at things that have no value to us.

Mon-Chaio: Mm hmm.

Andy: this is, this is one of the things when we get out of the technical systems, a lot of what we’ll be finding is the, as the creators of our constraints are, what are our policies?

What are our procedures and our policies? So as you work your way through this current reality tree. You, you, you come up with, what are the things that have to happen to cause that effect? And what causes those causes? And, and you kind of go, go for a while until you find kind of this place where everything seems to come back together.

There will be a few points where you’re just like, yeah, we’re seeing, it all comes back to this thing. If you’ve ever done root cause analysis, it’s the same kind of idea. In fact, when I saw these, I hadn’t used these specifically, but I saw them and I was like, oh, oh, that’s what I did in my incident analysis.

We would go through what was the undesirable effect. I called it the problem. What was the problem we had? And then what caused that to happen? And we’d build up these trees, these graphs of causes, and then we’d go through it and we’d say, well, what is it we’re going to fix? And. We would sometimes fix something seemingly completely unrelated until you read through the whole causal chain and you’re like, Oh, it’s obvious that this is what led to that outage.

Mon-Chaio: Mm hmm.

Andy: And, and that’s, that’s what these tools are for is to, to find that obvious place to change, to elevate that constraint.

Mon-Chaio: Rarely does the conversation at least in my experience ever get to the point where we’re saying, okay well, that is a bottleneck.

So let’s focus on Reducing that bottleneck. Like what are the problems that we’re having? The undesirable effects of UDEs, right? And I think it’s because when you think about the problem larger, you have folks like the CEO coming in and saying, Well, what do you mean it’s wasted time to flip a flag on every feature in the backlog?

Andy: week.

Mon-Chaio: every week, that’s your job. So don’t tell me that’s wasted work. And so we don’t even get to the other later steps. Mm hmm. Mm

Andy: I think that if that’s the conversation. You don’t yet have the alignment of the understanding. Now, it, it could be that what you need to do there is have a conversation. You could be missing information. It could turn out that flipping that flag is a risk mitigation measure. That if that risk were to occur, would cost the company billions of dollars.

It could be, you don’t know, but you should find out. The CEO is saying that there’s a lot of value in that. It’s your job, that’s why we’re paying you to do this. But

Mon-Chaio: and I think you hit the nail on the head, at least in my view. I feel like the tactics, the immediately applicable tactics for many leaders and biased, in my opinion, is most leaders, is actually convincing peers, maybe your board, even, that these people constraints, or these system constraints, should be analyzed via a Theory of Constraints methodology.

Remember, like, we talked about that the technical systems, it’s almost no doubt. Like, people do that regularly. But for whatever reason, as soon as you get to this stuff like, oh, we’re putting a bunch of items in the backlog that engineering doesn’t have time to do and it’s just queuing up there, that same technical leader, or other board members, will say, Well, no, that’s not the way to look at it.

What can we do to get those people that are not quite on board, or they think they’re on board, at least in a limited way, more on board with thinking about problem sets and larger systems, especially people systems and company wide systems in this way.

Andy: In the Phoenix Project, they lay out the three principles of DevOps, which are systems thinking, feedback loops, and culture of continuous learning, to paraphrase them slightly. But what we’re looking for there explicitly is that culture of continuous learning. What we’ve talked about many times before, that organizational learning, where you somehow are getting everyone on board. that the analysis and following the analysis and learning from what’s going on is critical for the group to function properly.

And a thing that I’ve seen happen is if the people don’t appreciate analysis, theory of constraints won’t go anywhere. Because so much of it is analysis. To the point where that was actually kind of a section of the Phoenix Project. There’s a passage where there’s an outage going on, and the main character’s at home, taking care of his kids.

There’s people working on what’s going on. They don’t want to take any steps until they actually understand the problem, so they don’t make it worse. And the CEO calls him up, and says, you need to show more urgency on this. I need all hands on deck. You need to just get this working now.

And he explains, we are working on it. If we put more people on this, that’ll just make it worse. If we start making changes without understanding what it is and what the impacts of those changes will be, we will make it worse, especially given our past history. We know that that’s what’s made it worst in the past.

So no, I, I’m not going to do that. The CEO, who’s calling him up demands that he does it, and the guy resigns. That’s part of the story. And I think that’s, that is, that kind of like pressure being put on, just take action, just take action, don’t analyze, I think is something we’ve all felt. And if you, if you don’t have that buy in to analysis is an important and valuable part of the process of improving and resolving issues if it’s, if, if the entire culture is just take action, then Theory of Constraints won’t go very far because it’s not just take action.

Mon-Chaio: I’m starting to think that when we think about system, technical thinking, and the technical person’s mindset, and how technical you have to be, and we said you have to have technical thinking, that that’s really around systems thinking.

This concept of abstraction of the system into things like measures, goals, of the whole system. then imp right. And then improvement of that system. And I often think that perhaps when we have these conversations, we’re not able to have them. It’s because we’re talking to a person that doesn’t really believe in that sort of analysis. Would you agree?

Andy: I would say it’s quite possible. It’s either they don’t believe or they haven’t seen one that resonates with them.

Mon-Chaio: Hmm. Mm

Andy: Because I think, I think that’s one of the things that needs to come out of these, that you get this kind of visceral, like, Oh, I get it now.

Mon-Chaio: hmm.

Andy: I’ve seen that a lot when I do the incident analysis and we do the root cause analysis section. We start out and someone is like, it’s absolutely, this is the problem.

That’s all we need to do. I don’t understand why we’re spending time looking at this. And then we’ll go through the analysis and they’ll, they’ll come to a completely different conclusion once they kind of have gone through it and understand, oh, it was more complex than that. And there were some things hidden that I hadn’t noticed before.

And yeah, that’s really where this came from. The thing that I was concerned about was a symptom.

Mon-Chaio: hmm.

Andy: It was a symptom of what was happening. And if we changed it, it actually wouldn’t have changed anything about what occurred in this outage. A lot of this comes down to, does the person do they believe the analysis?

Do they believe the system? And a lot of that takes actually just getting them to think through it. I think, I think very few people are going to be so unreasonable that you can’t walk through an understanding of something and get them to say, eventually, okay, I get it.

Mon-Chaio: Hmm.

Andy: They’d have to be very, it would have to be very irrational thinking.

Mon-Chaio: I don’t think about this as irrational thinking. I think for people that already have a technical mindset, I think it’s very easy to show them by technical example, or by systems thinking example, a way to think about a model, and a model that works in their mind.

And they say, oh, now I’ve seen it work, and I’ve seen it produce value, and I’m willing to move forward. But I think for folks with less technical thought patterns, and I’m not talking about rational, irrational, I’m not talking about evidence based versus non evidence based, I’m really thinking my current understanding of it is whether they believe in this larger systems level thinking of pieces are interconnected and the system as a whole has pieces that you can optimize globally instead of locally and that the fixing of a system isn’t around random emergent things of working hard in various sections.

Andy: Right.

Mon-Chaio: is a way to analyze an entire system, and think logically about it, and make trade offs. Instead of just saying, without making trade offs, and simply setting high level goals. I can use emergent properties of leaders, or hard workers, or marketing, you know, ra za za, or something, and my system will run the way it should.

Andy: There’s nothing understandable that connects all of this together.

And so your best bet is to

push everywhere you can at once. With the, with the belief that one of them will make it through.

Mon-Chaio: It’s that software experimentation, but at the human scale.

Andy: yeah, yeah. Maybe that’s the way of thinking about it. It’s kind of like a very I was going to say Darwinian, but not really Darwinian. But kind of social Darwinism type way of thinking about it, but that’s a system.

Mon-Chaio: Yeah,

Andy: But it’s a, it’s a, it’s a system that’s not manipulable.

And what we’re saying is that if you analyze the system, you can manipulate it.

Mon-Chaio: And maybe it’s one of those, to your point, I like how you delved into science because maybe it’s one of those things where you’re saying, look, we now know the theory of general relativity because of Einstein, right? So, it’s a system, and now because we can quantify that system.

We can think about a change here will affect a change there in a specific way. Whereas maybe before general relativity, or even way beyond that, before calculus perhaps, people didn’t have a way to understand it and so they just thought, well, no system exists. There’s just random threads of things that happen.

And so, since I can’t describe the system, it must be that no system exists. And why would you spend a bunch of time trying to prove that a system exists? I have something to ship.

Andy: Yeah, the, the, the system is that you do this work.

Mon-Chaio: Right. Right. Look, like, I’m trying to lift a big piece of rock from here to there. I don’t want you to say, I’m, well, I’m thinking about how gravity works, and whether there’s levers, and, you know, what the right length of lever is, and describing it. I just know I gotta get it up there. I don’t think there’s really any system, so like, let’s just push as hard as we can.

Andy: Yeah, and you know what’s funny? Very early on in a project, I would advocate for something similar.

Mon-Chaio: Sure.

Andy: We don’t know what the system is. We just need to get something moving. But as our organizations and our software grows more complex, there is absolutely a system in there somewhere. We may not understand what it is, but it’s there somewhere.

Mon-Chaio: Yeah, going back to the Explore, Expand, Extract.

Andy: Yep.

Mon-Chaio: All right.

Andy: All

right. Yep. Let, let’s,

let’s let’s try wrapping this up. I would say there is always a constraint somewhere in your system.

Mon-Chaio: Mm

Andy: And actually from our, from our just immediate conversation, there is a system there. You are working within a

Mon-Chaio: Almost always.

Andy: is always a constraint in your system. To improve your system as a whole. You need to identify the constraint, get the most out of that constraint by taking unnecessary load off of it.

Support the constraint, which is subordinate everything else to the above decision.

Mon-Chaio: Mm

Andy: Elevate the constraint, and then your constraint will move and you repeat. To find your constraint, you can use the current reality trees and other techniques like that to identify where is the constraint really in your system. And I’m gonna, I’m gonna leave people with a quote from the Phoenix Project, which is actually hearkening back to Seven Habits for Highly Effective People, which is “improving daily work is even more important than doing daily work.” And I’ll expand on it a little bit, which is that improving your daily work is a form of doing your daily work. I think something that we didn’t touch on, which is that the analysis is something you’re kind of doing a lot, all the time. It’s not a one time event, and then you move on and never think of it again.

The analysis is constantly happening. Just like in a software project, you don’t want to overanalyze. You want to do some analysis, get a good idea. Do a safe probe and change and see what happens. This isn’t like do an analysis for 10 months while you figure out the is.

This is come up with a very quick idea of what the constraint is, and then act on it. So Mon Chaio, what do you take away from this? What are your tactics?

Mon-Chaio: I don’t know that I have any specifically to add to that. I think you did a really good job of summarizing the concept of theory of constraints and the tactics around it and how you do it. I think that two points that I really like that you made is the first one right off the bat that there is a system and systems have constraints.

I think if you can’t agree to that then obviously, why would you be using the Theory of Constraints, right? But

Andy: why go any further?

Mon-Chaio: But I do think that sometimes people tend to forget about that in the heat of the moment or whatever, and I think that is an important thing to realize. That most often, almost in all cases, there is a system, and where there’s a system, there’s constraints. And then, I really like the last thing that you said, which was improving daily work is more important than daily work. I, I don’t like that quote exactly. I don’t think that that’s, I think that that taken out of context can be pretty troublesome. But you did clarify it by saying that improvement is work. Analysis is work. And drawing back to some of the other stuff that we’ve talked about, practice is work.

Learning is work. It’s all about the balance of that, right? You can’t just be learning eight hours a day, 40 hours a week, right? But you also can’t say that it’s something done in the, in some other time. So, getting back to this though, improvement is work. Spend time on it. Find time for it and elevate it to be as important as the other things you consider work.

Andy: If you liked this episode, if you have thoughts on this episode, please let us know. We’re hosts at thettlpodcast. com. And if you’re interested in bringing these kinds of things to your organization Theory of Constraints or Better communication or leadership approaches, both Mon Chaio and I coach people in this so you can just reach out and contact us. Until next time, be kind and stay curious.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *