Theory of Constraints

Check out Beyond The Goal and Beyond The Phoenix Project for a deeper dive in this area.<p>I work in cyber security and use many of the concepts often. The root cause of many poor outcomes are poor assumptions, prioritizing ideology over customer value, and misaligned shared mental models.<p>I use a simple doc format to address. It&#x27;s based on evaporating clouds.<p>1. What&#x27;s the shared (understanding of current state with a focus on objectivity? 2. What are the problems with current state? Subjectivity is OK here. 3. What&#x27;s desired state? 4. What are the experiments we can run ASAP to learn if our understanding of desired state is correct and learn how we can get closer.<p>Simple concept. Works great.

Somewhat related is _Flying Logic_, which was ostensibly made to to enable ToC-type thinking processes at Northop Grumman.<p><a href="https:&#x2F;&#x2F;flyinglogic.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flyinglogic.com&#x2F;</a><p>For a period in my life I was very taken by the promise of a node-based graph visualisation of projects, enabling you to quickly track dependencies, constraints, next steps, redundancies and so on.

Reading &quot;The Goal&quot; and contemplating how to apply the Theory of Constrains to complex software systems a couple of decades ago became part of the secret sauce of my career as a software engineer. Especially helpful was the insigth that one may make good progress tuning one part of a system only to discover that a larger constraint prevails as the true bottleneck.<p>Here&#x27;s a practical example. For those who may still wrangle fleets of actual cloud instances (instead of going the managed cluster or serverless route), a common mistake is to imagine that all that is needed is a group of the smallest compute units available. But with AWS, for example, this can bite you when the smallest instances also have dinky allowances for network and&#x2F;or disk I&#x2F;O compared to medium or larger instances. People end up wondering why their queues aren&#x27;t draining quickly or their DB writes or log pipelines are backing up, etc.

Everything in this book applies not only to management, but also optimizing distributed systems.<p>E.g.<p>- optimizing parts of the system for their own metrics often leads to degradation of the whole system performance; any optimization must be done w.r.t. the context of the system as a whole<p>- focus on optimizing the bottlenecks<p>- approach to identifying bottleneck<p>- minimize amount of stuff waiting in the queues<p>I love this book. It laid out in an approachable way my observations w.r.t how humans fail to organize efficiently by just not being good at thinking in terms of a larger system.

Highly recommend reading or listening to The Goal. The audiobook feels like a cheesy training video, but sort of in a good way, and the concepts are extremely useful. Plus, you learn the language it is more likely your business counterparts know, as opposed to talking about backpressure or queuing theory, which they may not connect with.<p>I use the concepts from this book all the time at work to justify a prioritized backlog and defend against a lot of work in process.

&quot;The Goal&quot; has a programming offshot called &quot;The Phoenix Project&quot;. It may make your blood boil because a lot of the situations are tooootally realistic.

Lots of good ideas, very thought-provoking when comparing with how mgmt at most companies operate.<p>Be aware however if trying to apply in real life that most managers will fight you since it seems counter-intuitive.

I&#x27;m surprised that there is no mention of Operations Research in this article.<p>I&#x27;m actually curious if any business use Operations Research for real, vs. managers just guessing. I mean do something like Linear Programming to optimize profits based on various constraints.

A kind of radical belief that I hold is that basically everyone would benefit from working as a planner for a year or two, especially if you can spend a good amount of time away from your desk and out on the floor. The lessons you can learn by trying to coordinate a production floor are simultaneously very general, very practical, and oddly difficult to learn elsewhere.

Reminded me of this in Smalltalk-76 <a href="https:&#x2F;&#x2F;github.com&#x2F;cdglabs&#x2F;thinglab">https:&#x2F;&#x2F;github.com&#x2F;cdglabs&#x2F;thinglab</a>

<i>The Goal</i> was a fun listen&#x2F;read. <i>Wait, if the water fills up at 5 liters an hour but the pipe can only support a throughput of 2 liters an hour… then we have a whatchamacallit!</i>

Very interesting read!