The Goal changed how I look at problems
I expected a book about manufacturing. It turned out to be a book about thinking — about constraints, and the problem quietly limiting everything else.
I recently finished The Goal by Eliyahu M. Goldratt. I expected a book about manufacturing. It turned out to be a book about thinking.
The story follows Alex Rogo, a plant manager whose factory is slowly falling apart. Orders are late, costs are high, machines are sitting idle, people are frustrated, and everyone seems busy.
And yet the factory isn’t actually getting better. That was the part that stuck with me.
Being busy doesn’t mean you’re productive
One of the simplest ideas in the book is also one of the easiest to forget: a system can be full of activity and still be failing.
A machine running all day sounds productive. So does a developer working for eight hours, a team having five meetings, a sales pipeline full of leads. But none of it matters if it doesn’t help the system move towards its actual goal.
It made me think about how often we measure activity instead of outcomes. Hours worked. Tasks completed. Tickets closed. Messages sent. Meetings attended.
We love numbers because they make us feel like we’re measuring progress. Sometimes we’re just measuring movement.
Find the bottleneck
The biggest idea I took from The Goal is the constraint. Every system has something limiting its overall output.
It might be a machine in a factory. It might be one person everyone depends on. It might be approval from a client, or a slow process. It might even be a decision that nobody wants to make.
The interesting part is that improving everything equally isn’t necessarily useful. If one part of the system is the bottleneck, making another part 20% faster might accomplish almost nothing.
Imagine a restaurant where the kitchen can prepare 100 meals an hour, but the billing counter can only handle 20 customers.
Making the kitchen faster doesn’t solve the problem. You just create a bigger pile of unfinished meals.
That sounds obvious when you put it that way. But businesses do this all the time. We optimise the parts that are easy to optimise instead of finding the part that actually limits the whole system.
The bottleneck controls the system
This changed the way I think about operations. Instead of asking “How can I make this process better?”, I think the better question is “What is currently preventing the whole system from moving faster?”
That is a very different question. And sometimes the answer isn’t where you expect it.
A company might think its problem is sales. But maybe sales is bringing in more work than delivery can handle.
- Sales
- Deliverythe constraint
- Happy customer
A team might think it needs more people. But maybe the real problem is unclear requirements. A founder might think the team is slow. But maybe every decision has to come back to the founder.
The visible problem isn’t always the actual constraint.
Local optimisation can hurt the whole system
Another idea I liked: improving individual parts of a system can sometimes make the whole system worse. This is something I’ve seen in real work.
Suppose a developer finishes tasks extremely quickly. Sounds great. But if those tasks aren’t the highest priority, they’re just creating more completed work while the important work stays stuck.
Or imagine a team trying to keep every person 100% busy. It sounds efficient. But if everyone is busy, there is no spare capacity when the bottleneck needs help.
The goal isn’t to make every person or department maximally busy. The goal is to make the system effective. That’s a subtle difference.
The five focusing steps
The book gives a simple framework for dealing with constraints:
- Identify the constraint
- Exploit the constraint
- Subordinate everything else to it
- Elevate the constraint
- Repeat — find the next one
I like this because it turns problem-solving into a loop. You don’t “fix the business”. You find what is limiting the business right now, and you work on it. Once that constraint moves, another one appears. Then you repeat.
It’s almost like debugging software. You fix the biggest issue, run the system again, see what breaks next, and keep going.
The strange connection to my own work
This is probably why I enjoyed The Goal more than I expected.
I’ve always had a tendency to look at repetitive work and think: “Why are we doing this manually?” If something happens every day, I want to automate it. If someone has to answer the same question again and again, I want a system for it. If a process depends on one person remembering something, I want it written down.
I’ve sometimes thought of this as being lazy. The Goal gave me a better way to look at it. Maybe the instinct isn’t laziness. Maybe it’s systems thinking.
The point isn’t to work less. The point is to remove unnecessary work so that human attention goes where it actually matters.
The goal is not the machine
One of the deeper lessons in the book is that individual parts don’t exist for themselves. A machine isn’t there to stay busy. A department isn’t there to maximise its own output. A team isn’t there to complete the maximum number of tasks. Everything is part of a larger system.
That sounds obvious. But once you start looking at companies this way, you notice how often teams optimise for their own local goals.
Marketing wants more leads. Sales wants more deals. Development wants clean implementation. Operations wants fewer issues. Finance wants lower costs.
Each of those is reasonable on its own. But the company has one larger objective, and the challenge is getting the pieces to work towards it instead of competing with each other.
What I actually took from the book
I didn’t finish The Goal thinking I had learned how to run a factory. I finished it thinking I had learned a better way to look at problems.
When something isn’t working, I now want to ask:
- What is the actual goal?
- What is preventing us from reaching it?
- Where is the constraint?
- Are we improving the constraint, or just making ourselves feel productive?
- What happens to the rest of the system if we optimise this part?
And probably the most important one: if we solve this problem, what will become the next problem?
Because systems don’t stay fixed. You solve one constraint and another takes its place. That’s not failure. That’s the process.
Maybe that’s what I liked most about The Goal. It doesn’t really teach you how to make a machine faster. It teaches you how to see the machine differently.
And once you start seeing businesses, teams and even your own life as systems, you notice something: the hardest problem is often not the one making the most noise. It’s the one quietly limiting everything else.