The Goal: Part II

This post is a follow-up to an earlier blog post on Eliyahu Goldratt’s book, The Goal.

Some of this is a restatement. Some is an amplification. All of this was in inventory. Inventory is a liability. Now it’s out.

I didn’t know my job

Before I read The Goal I thought I was a pretty good manager. So did other people else. I was wrong. They were too.

I thought my job was to set goals and then help and to push people (including me) to reach them. I did that. I was wrong.

I thought my job was to help remove roadblocks and to increase productivity and efficiency. I did that. I was wrong.

I thought that if I made things better every day that I had done a good job. I did that. I was wrong.

A lot of what I thought was wrong.

I learned that (and why) most of the “improvements” I made were worthless. I learned many of them made things worse(!)

Only some of the things that I did made things better.

So I stopped doing the things that were worthless and worsening. I paid attention to finding the few things that made things better and tried to work on them and nothing else.

Bad habits die hard. I never was as good as I could have been. But I was a lot better than I had been.

Thinking different

The Goal made me think differently about management.

I had everyone around me read it so that they’d understand my thinking and be able to think that way, too.

What you learn from The Goal seems counterintuitive—wrong, even. Then The Goal changes the way you see the world. It improves your intuition. What was counterintuitive becomes obvious—but only to people who understand it.

Once we all understood this different way of thinking, we came to decisions faster.

We made the right decisions quickly because they were obvious.

We spent no time debating. We spent less time deciding.

Throughput went up.

Throughput? What’s that?

Read on.

TL;DR The Goal

The world view of The Goal depends on two fundamental ideas: throughput and bottlenecks.

Throughput means “the value of completed production.” Progress does not count; only completed production. Defining value and completed production are different for each organization. Defining them correctly is critical.

Production is the result of a network of activities. The bottleck is the one node in the network that is running at full capacity. Only one node is the bottleck at a given time.

Only improving the bottleneck's capacity increases throughput. The capacity of the bottleneck limits the system’s entire capacity.

Your job as a manager is to define value and completed production correctly; then to identify the bottleck; then work to increase its productive capacity.

A simple manufacturing example

Suppose you are in charge of manufacturing for a company that makes just one product.

The number of units of that product that you produce determines your throughput.

The number of units you deliver to customers determines the company’s productivity. Manufacturing fewer than you can deliver is a mistake. Manufacturing more than you can deliver is also a mistake.

Suppose that the process for making a unit is to put it through steps A, B, C, D, and E.

Suppose A can handle 50 units per day, B can handle 40, C can handle 30, D can handle 70, and E can handle 100.

If sales can’t sell and deliver 30 units a day, then sales is the bottleck. If it can, then the bottleneck is in manufacturing, and it’s at step C.

It’s one or the other because there’s always only one bottleck.

Assuming you want to produce more than 30 units, anything you do to improve D or E has no effect. Throughput remains the same: 30 units. You are wasting your time.

Anything you do to improve A or B makes things worse. Things are already jammed up at C. Nothing more gets out. No increase in throughput. More time handling the jam.

The only thing that you can do to increase throughput is to improve C. Let’s say you improve it so it can handle 60 units. Now the bottlenck moves. It’s now B. The only thing that will increase throughput is improving B. Then it moves again.

A more complex manufacturing example

We’ll get to software. I promise.

Now suppose you’re manufacturing many products. Each kind of product goes through the same process, but not every type of product goes through the same steps.

The process network is more complicated, but there’s still only one bottleneck. And it’s a bit harder to find.

First, you need to know how much of each thing you produce is demanded by the outside world. Then you need to have a value assigned for each unit of production.

Your intuition will likely break down and gives you the wrong answers when you assign value. Let’s suppose you use a machine to make component—a fancy screw, say—that’s used in several finished products. Say it takes 6 minutes to make each screw.

What value should you assign to the screw?

Intuition says: figure the cost of running the machine per hour, including overhead, and divide by 10. That’s the value.

Intuition is wrong.

That’s the cost but not the value. The value depends on what product uses a particular screw.

Let’s suppose that the company produces just a product that needs only one of those screws. Suppose the value of the product—what customers pay—is $100. Then the value of the screw is $100.

Suppose the company also produces a product that uses one of those screws, and that product’s value is $1,000. Then the value of a screw is $1,000 until they’ve made all of that type of product that can be sold and delivered. Then the value drops to $100 until they’ve made all that second type of product that they can sell and deliver. Then the value drops to zero.

I hope you see why this is the right answer. If the company can’t sell a $1,000 part because it lacks a screw, then the company’s throughput drops by $1,000. The value of each screw is the value of the larger assembly. As long as you can sell more of those $1,000 parts, you make more of those screws. The machine’s throughput is $6,000 per hour.

When there’s no demand for screws for the $1,000 product, the value drops to $100 per screw, and the machine’s throughput drops to $600 per hour. When there’s no more demand for screws for the $100 product, then you use the machine to make the $10.00 product.

Inventory is a liability

Traditional cost accounting counts inventory as an asset. The Goal says it’s a liability.

In a manufacturing operation, your inventory makes you no money. Only throughput—products delivered to customers makes you money. To the contrary: inventory costs you money. You need a place to store it. You need to move it into that place and take it out. You need to keep track of it. And while it’s sitting in inventory, it will deteriorate. Or become obsolete.

In a software operation, features that are complete but not in production make you no money. Only throughput—valuable features in production—make you money. Bit rot is a real thing. While features are sitting in inventory interfaces may change so that the features don’t work anymore. And market needs can change, and features become obsolete.

Summary

• You have one goal

• Your goal is throughput, not progress.

• Throughput is work that is done.

• Done means passed on to another part of the organization.

• Done also means: unlikely to come back for rework.

• There is no credit for progress. Only for throughput.

• For most organizations done means: making profit

• Inventory is a liability

The mistakes that software contributors make

Working on more than one project at a time reduces throughput. Better to work on one, complete it, and then the next. Half done work is of no use to anyone.

Coding up multiple features at a time gives you a false sense of progress. Better to work on one, complete it, work on the next, complete it. And so on.

Remember: nothing is done until it’s in production.

For managers

• You need to assign a value to completing each project or product. Completing. Not making progressing. Completing.

• You need to make your assignments public, so your team, and your management, and your internal customers know what you are doing.

• You will often find that your internal customers won’t agree.

• Your team’s throughput over any period is the value of what your team has completed over that period.

• You don’t have competing priorities. You have one priority: maximizing throughput

​