The Goal: Part I

The Goal by Eliyahu Goldratt is the best management book ever written. I’ve bought and given copies to everyone who reported to me, everyone who I reported to, everyone who worked with me as a peer, and to most of my customers. I’ve given out about a hundred over time.

It’s written as a novel. You live the main character’s life as he solves his management problems. You learn the management lessons as though you’d experienced them yourself.

Don’t read the rest of this post. Buy and read The Goal.

What I learned

OK, well, keep reading.

Until I read The Goal, I thought I was a good manager, but I wasn’t. I didn’t understand my job.

Until I read The Goal, I thought that making a little progress each day on many things was a good idea.

The more balls moved toward the goal line, the better.

This is completely wrong. It’s a terrible idea.

Partly done projects are a liability, not an asset.

A liability.

Bad Habits

Bad habits are hard to break.

Until I got to this part of an earlier draft of this post, I had forgotten the lessons that I’d learned.

In my sidebar, I have eleven more posts that I’ve been working on—making progress on each from time to time.

Wrong!

Work-in-process is bad.

Inventory is bad.

Big projects that take a long time are bad.

The Goal taught me that I wanted throughput, not progress. Throughput is stuff that’s done. Out the other end. Finished.

Progress that does not result in throughput is bad.

Progress is stuff written. Throughput is completed posts.

A million half-finished posts are progress. But it’s not throughput.

I learned better and then forgot.

So right now, I’ve made finishing this post my priority.

I want throughput.

Absolute priorities

Before I read The Goal, our team (and I) tried to make progress every day on the projects we’d taken on.

Before The Goal, we had a list of top priorities—like “must haves” and then a list of lower priorities like “nice to have.”

“Nice to have” was a euphemism for “never gonna happen.” We were just unwilling to admit it. After The Goal, we were more honest with ourselves and with our customers.

After I read The Goal, I set “absolute priorities.”

Absolute priorities meant there was only one number one priority. Only one number two. And so on.

Setting those priorities took some skill. And that’s the subject of another post (maybe.). But once we had our list of absolute priorities, the team became mainly self-managing.

Managing once you have priorities

We put as many people on the number one priority as we could without them getting in each other’s way. We preferred to put the people who were the most capable on the top priority project. Then we put people on priority number two. Then number three. Once we ran out of people, we stopped. We even stopped prioritizing. What’s the sense in deciding whether a project is priority number six or seven when you’ve only got resources to work on the top three?

Once we matched people with projects, everyone knew what to do. Get your project done!

If the team on a higher priority project needed help, people working on a lower priority project knew that they could (and should) jump in.

The goal is getting the highest priority project done, then the next, then the next.

Making priorities public

I made the priorities public. When an internal or external customer saw that their project or favorite feature had a lower priority than they wanted, they’d sometimes get mad.

I’d explain what we were doing and why we were doing it. I’d calm them down.

They were used to being told “we’re making progress” but never seeing anything finished. Now they understood that once they had their turn, no one was going to steal cycles from them. And they understood when they would get their turn.

They just had to wait for their turn.

Mote stuff started to get done—not just worked on.

External and internal customers were happier.

Morale went up.

No one likes to keep switching from project to project to keep up appearances.

No one likes disappointing customers.

Everyone likes crossing off items as DONE!

I will like crossing off this post as DONE!

Variations and complications

What do you do if the priority three project is blocked because the only person who can solve a problem is working on the priority one project? That’s covered by The Goal too, but it’s the subject of another post (maybe.)

There are other nuances, and we figured them out.

But the fundamental rule was: make absolute priorities. Don’t start something unless you are going to finish it.

Break work into pieces and finish each piece

When all that matters is getting things done, you change how you work.

You break big projects into smaller pieces and finish each piece.

Feature creep

This post started getting bigger and bigger.

It wasn’t getting finished.

So I broke it into pieces. I assigned this piece top priority.

And I’ve finished it.

After I’m done, I’ll choose a new number one priority, and then I’ll finish it.

Maybe it will be a follow-on post.

Maybe it won’t.

But it will get done.

(Eventually, I wrote Part II)

If you think this post might help someone else, you can share it.

​