The Goal

I picked up The Goal expecting a book about manufacturing. A plant, machines, inventory, a lot of numbers. That is the setting, but it reads more like a book about how to think. I’m still reading it, and I already wrote one post about it: The Goal changed how I look at problems. These are my running notes.

The story follows Alex Rogo, a plant manager whose factory is losing money. Orders are late, inventory is piling up everywhere, and head office has given him three months before they shut it down. Everyone in the plant is working hard. The machines are running. And nothing is getting better.

That combination is what hooked me. A place where everyone is busy and the business is still failing.

What does “the goal” even mean?

Early on, Alex runs into Jonah, an old teacher of his, who keeps asking him annoying questions. The first big one is basically: what is the goal of your plant?

Alex gives the obvious answers. Quality. Efficiency. Keeping the machines busy. Jonah keeps pushing until Alex lands on something much simpler. The goal of a business is to make money, now and in the future. Everything else is a means to that.

It sounds too obvious to write down. But I think a lot of companies quietly forget it. A department starts measuring how busy it is. A team starts measuring how many tasks it closed. Those numbers go up, everyone feels good, and the business doesn’t move.

The book then gives three measures that I keep coming back to:

• Throughput: the rate at which the system makes money through sales.
• Inventory: the money tied up in things the system intends to sell.
• Operating expense: the money spent turning inventory into throughput.

What I like is how small that list is. If an action doesn’t raise throughput, lower inventory or lower operating expense, it’s hard to argue it helped. A lot of “productive” work fails that test.

The scout hike

My favourite part so far is a scene that has nothing to do with the factory. Alex takes his son’s scout troop on a hike. The line of boys keeps stretching out. Gaps open up. The kids at the back have to run to catch up.

The reason is one slow kid called Herbie. The whole troop can only go as fast as Herbie. Making the fast kids walk faster does nothing. They just get further ahead and the line gets longer.

So Alex puts Herbie at the front and takes the heavy things out of his backpack, spreading them across the others. The whole troop speeds up.

It’s a children’s-story version of the whole book, and it made the idea click for me more than any diagram would. You find your Herbie. You put him where he sets the pace. You take weight off him.

Busy is not the same as productive

This is the idea I think about most. A machine running all day looks productive. A person working eight hours looks productive. But if that output just piles up in front of a slower step, all you’ve made is a bigger pile.

In the book, the plant has been measuring efficiency per machine. Every machine is supposed to be busy all the time. So the fast machines keep producing parts nobody can use yet, inventory grows, cash gets tied up, and the late orders stay late.

I’ve seen softer versions of this in service businesses. When I look at how work moves through a company, the question I now ask first is where the work is waiting. That’s usually where the real problem is.

Find the constraint

The core idea is the constraint. Every system has one thing limiting its overall output. It might be a machine. It might be one person everyone depends on. It might be a client approval, or a decision that sits with the founder.

If you improve anything other than the constraint, the system doesn’t get faster. You just get better at producing things that wait.

That changed the question I ask. Instead of “how do I make this process better?”, I try to ask “what is stopping the whole system from moving faster right now?” Those lead to very different places. The first gives you a long list of improvements. The second gives you one thing to work on.

The five steps

The book’s framework for dealing with a constraint is simple enough to remember:

1. Identify the constraint.
2. Exploit it. Make sure it’s never idle and never working on the wrong thing.
3. Subordinate everything else to it. The rest of the system works at the constraint’s pace.
4. Elevate it. If it’s still the limit, add capacity there.
5. Repeat. Once it moves, find the new one.

Step two surprised me. Before spending any money, you make sure the bottleneck is fully used. In the plant, a key machine was sitting idle during lunch breaks and processing parts that weren’t urgent. Fixing that cost almost nothing.

Step three is the uncomfortable one. It means other parts of the system should sometimes slow down, or even stop, so they don’t flood the bottleneck. That goes against every instinct to keep people busy.

Why this feels familiar

I’ve always looked at repetitive work and asked “why are we doing this manually?” I used to think of that as being lazy. Reading The Goal, I think part of it is that I’m looking for the place where effort gets stuck.

With Knox, a lot of what I did was take myself out of the middle of the work, because I had become the step everything waited on. I didn’t have the word “constraint” for it then. I just knew things were slower when they needed me.

Questions I’m taking from it so far

• What is the actual goal here?
• Where is work waiting?
• Is that the constraint, or just the loudest problem?
• Are we improving the constraint, or something easier next to it?
• Once this is fixed, what becomes the next limit?

I’ll add to this when I finish it.