Book review: The Goal

I am a sucker for novels as allegory for technologists. When my friend Bex recommended Eliyahu M. Goldratt’s The Goal, I knew I had to give it a try. Surprisingly, the wait for the audiobook was measured in months, so I had plenty of time to wait. But the wait was worth it.

The Goal is set in a Rust Belt town where the local factory is struggling to remain productive (and therefore profitable). Our narrator is the plant manager, who is pouring all of himself into trying to save the plant. This, as you might expect, puts a serious strain on his home life. By chance, the narrator runs into his college physics professor. The professor works in a few moments here and there to help his former student improve the plant’s flow — often in counterintuitive ways — by asking questions that lead the team to a successful outcome.

You might ask what early-1980s industrial manufacturing has to do with the modern software industry, and you’re right to ask it. The setting is not immediately applicable, and a lot of the references (and attitudes in a few places) are very dated. But just like in my review of Tom DeMarco’s The Deadline, I did not find myself thinking “boy, I’m sure glad that problem is solved now.”

What’s the goal?

We still face (as do people in many other industries) being judged on local performance, whether or not that helps — or even hurts — the broader organizational goals. A person whose performance is graded based on the number of tasks they complete will complete as many tasks as they can, regardless of whether or not it creates a bottleneck downstream or is “wasted’ work. As Jonah, the professor character, says “a system of local optimums is not an optimum system at all. It is a very inefficient system.”

This, perhaps, is the one lesson that we’ve retained. System administrators know, even if managers and executives sometimes forget, that fully-utilized systems are brittle. If you want a resilient system, you need to have excess capacity in order to handle bursts. Stable systems are inefficient, and efficiency for efficiency’s sake is a bad goal.

The overall message of The Goal, and the first question that Jonah asks, is “what is the goal of the organization?” For businesses, the goal is to make money. It’s not to manufacture widgets, ship software, sell services, or whatever. Those are ways the business achieves the goal of making money. Market fit, quality, price, etc are factors in how successful the product is, but aren’t the goal in themselves. The rest of the book describes how to analyze flow through the process to optimize overall throughput in service of that goal.

Other lessons along the way

I’m not sure how much Goldratt intended for me to take these additional lessons from his novel, but I picked up a few other things along the way. First, is that if you’re too busy to update your documentation, you will get busier due to out-of-date documentation. At one point, the plant’s leadership team is operating under assumptions based on outdated documentation, which causes them to make the wrong decision. Bad documentation leads to rework, which is both demoralizing to the worker and counter to optimizing throughput.

Another lesson is that priorities that aren’t clearly communicated and understood aren’t priorities in fact. People have to understand what they’re supposed to be working on and why. If that changes and they don’t know about it, they’ll keep following the old priorities. Understanding the “why?”, especially when something seems counterintuitive, is important to get people to buy in and follow the plan.

Lastly, the Socratic method only works if both people are willing to use it. At one point, having seen how well the Socratic method worked to lead him to improvements at the plant, the plant manager tries it on his estranged wife. Because she sees his questions as having seemingly-obvious answers, he comes across as an asshole. Asking questions to understand the layers of an answer can be a very helpful approach, but everyone involved has to be in the right space for it.

My verdict

Overall, I thought The Goal was a solid book. The lessons are well-communicated, valuable, and not overly-preachy. The audiobook version is surprisingly well-produced, which made it fun as well as informative. If I ever become a college professor (unlikely!), I’d love to teach a course of allegorical novels, and The Goal will fit in well with The Deadline and The Phoenix Project.

Goldilocks process

I was once asked in a job interview: “how do you know if you have too much or too little process.” I didn’t have a good answer at the time (which is probably part of the reason I didn’t get the job), but I’ve since come up with my preferred way of finding the Goldilocks point in the amount of process. Too much process causes pain for your developers. Too little process causes pain for your customers.

This doesn’t seem like a very novel idea, but I think it makes sense. The appropriate amount of process varies from situation to situation. Designing systems for manned spaceflight is much different than designing a Facebook game. Therefore, it makes sense to look at where the pain exists to see where you are on the spectrum.

With too much process, your developers are unhappy because they’re spending too much time doing meta work and not enough time writing code (even though meta work can be critically important, you should always do exactly the right amount). With too little process (particularly around testing and UX), your customers get a buggy, hard-to-use product that they’re constantly having to update.

One important note is that customers can experience pain from too much process, too, particularly if they have to wait three months for a bug fix. By the same token, developers can experience pain from too little process when every commit sets off a flurry of merge conflicts. Arguably, these scenarios are not from the wrong amount of process, but the wrong implementation of process. Go read The Phoenix Project for a much better explanation than I could give.