The Goal

The Goal was recommended to me by a number of friends, and I finally got around to reading it. It tells the story of a plant manager who is looking to optimize his manufacturing plant. While the plant has picked up all sorts of new automation and seems to be 'much more efficient', in reality its continuing to lose money.

I think it's a useful read, particularly for founders, but also for anyone looking to consider holistically how their business might work. It's just different enough from software that I was able to see more distanced parallels.

Big a-has

• The "market" can be a limiting factor. If you don't have enough sales, it's not really worth increasing capacity "ahead of" sales. Instead, you should be trying to. Sales can also be used strategically (e.g. instead of ordering parts 1-100 all in one go, the customer might prefer parts 1-20 today, then parts 20-40 next week, etc.) You can re-structure deals or negotiate to help your business.
• The goal of any business is to increase throughput (sales) while decreasing inventory + operating expense. You need to do all three of these things at once.
• It's okay if certain parts of your pipeline have excess capacity, so long as the bottleneck is always working. Any time lost at the bottleneck will always translate to lost hours downstream.
• For any hardware company, the ability to generate sales ahead of inventory is huge. When I look at Tesla and Elon Musk, he is a master of doing this. People will reserve orders months in advance, simply because they have great hardware differentiation! Same thing with Apple. This has a huge impact on cashflow.
• It's easy to lose sight of top-level goals and not see the "forest through the trees". I noticed this a little bit at Segment. It was easy for teams to focus more on things that were easily measured (SEVs, JIRA tickets, etc) vs high-level goals around revenue (which were sometimes more tenuous).

The three goals of every business

The protagonist starts off the book worrying endlessly about 'efficiency'. How can he improve productivity and efficiency?

A mentor makes the point that feeling progress comes from picking a goal, and making progress towards it. There are three goals that every business has:

1. Increase net profit
2. Improve ROI
3. Improve cashflow

Goal #1 is obvious, the business exists to make money. Goal #2 is less obvious, but makes sense: if your business makes 10m, it matters whether it took 1b or 1m to get there. Goal #3 is the last constraint, if a business doesn't have adequate cashflow between bookings, it will fail.

There's an interesting question asked, which is: how do I tie every action to one of these three goals? At Segment, I don't think we had a solid case, aside from infrastructure cost reduction or sales. The speculative nature about R&D or new product development makes it difficult to know which projects will succeed.

You need to do all three of these goals at once to make a business great.

The Three Metrics

There's a simple way to model any business (sort of like the conservation of heat).

1. Throughput: how much are you bringing in to the business from customers?
2. Inventory: how much on-hand inventory do you have that you could re-sell?
3. Opex: how much do you spend? (the outflows of the business)

Machinery is both inventory (you could re-sell it), but also has some depreciation (opex). IP or patents are inventory because you could re-sell them

Example: dice game. There's a game using matchsticks which have to move from bowl to bowl (an assembly line). Each round, the player rolls a die, and can move that many matchsticks from their bowl to the next. The early players have no trouble making their quota, but the later players have no chance. The matches in bowls are the inventory, the die are standard fluctuations, the throughput is the amount of matches passing through the system.

Bottlenecks and non-bottlenecks

Whatever the bottleneck is in your system, that is the thing that will limit throughput.

If possible, you need to prioritize what feeds into a bottleneck. In a manufacturing plant, that means either adding more throughput to that specific part, prioritizing the inputs to it, or running QA so you can shed some of the load into it.

Smaller batch size

Perhaps counter-intuitively, it can make sense to run parts of your system with "smaller batch sizes". You might think this means that you get less capacity for each step, but the benefit is that you can move each batch to the next one more quickly. Any downstream dependencies which are waiting for earlier parts can begin working, even if they don't yet have the "full batch".

We saw this at Segment, shifting from annual planning to every 6w or so. There's some setup cost incurred, but if you do it in a lightweight manner, you can react much more quickly to new changes.

The Intrinsic Order of Things

When you come into a new organization, conventional wisdom says that you should start by collecting all the facts. Talk to different people, identify problems, generate a bunch of reports.

The trouble though is that's exactly what causes organizations to stagnate in the first place! They do all sorts of fact-finding, collect and categorize all sorts of problems, and leave it at that. There's no priority or clear mapping to a strategy to tackle specific problems first.

Instead, we should try and find the 'intrinsic order of things'. In the same way that Mendeleev discovered an intrinsic order in the periodic table by atomic mass, he revealed a lot of fundamental aspects of the universe. If we categorize our problems subjectively (as the Ancient Greeks did), we'll end up with the wrong elements and the wrong system.

Toyota Production System (TPS)

The last section of the book deviates from the parable entirely and instead just talks about real world examples.

Some surprising things I learned...

• In 1926, Henry Ford's production line could produce a 5,000 part automobile end-to-end from iron ore in 81 hours. What an absurd stat! Toyota borrowed these ideas as part of their lean production system.
• Toyota made this whole process very public and very well-documented. Competitors were free to visit their facilities and learn from them. Most weren't able to replicate the total devotion to "smooth flow" as a metric, and focused on other intermediate metrics.
• Toyota's leadership team focused on reducing inventory at every step, because they realized it was the only way to streamline their operations. It's hard to put such a maniacal focus.
• Toyota's model works because it is relatively static. You can't just copy this approach to software, or a field where releases happen more than annually. Mitsubishi tried for their tooling division and apparently it didn't work at all.

Theory of Constraints

What this all boils down to is Constraint Theory. When looking at any process there's five key steps to follow...

1. Identify the constraint (aka the bottleneck)
2. Exploit the constraint (make the most of what you have, re-order, get the bottleneck working 24/7)
3. Subordinate to the constraint (make sure everything that feeds into the constraint is optimized for it and other systems work around it)
4. Elevate (if the constraint still exists, try and unblock it via more capacity/investment/etc)
5. Go back to step 1 (continuous improvement etc etc)

The other methodology here is the "drum-buffer-rope" method of synchronizing a production line.

• drum: the 'beat' of the constraint (e.g. patients seeing a doctor)
• buffer: the constraint only has as much runway as the buffer ahead of it, make sure it is adequate (e.g. receptionist scheduling appointments / waiting room)
• rope: the release mechanism for new inventory (e.g. the nurse calling in a patient)

Parallels to Segment

Reading the book provided an interesting analogue not only to Segment the company, but to Segment the product.

At Segment, we would collect data coming in, keep some of it in queues, and then do our best to deliver the data to destinations where it would need to go.

The times the system would behave most poorly were when a particular destination could not accept the throughput we'd need. Our queues would back up, workers would spin on failed network requests, and generally our cost curves would increase as we tried to send the data.

It made me think of a scheme I wish we'd developed which would effectively sort messages by 'delivery time'. In this idea, you have one 'fast-path' queue which tries to deliver everything right now. Then you have a 1-minute delay queue, a 2-minute delay queue, etc. Any consumers of these queues (we used Kafka topics) can simply lag behind until the delivery needs to be met. In that way, they are 'always working' but not doing pointless work.

Musings

Differentiated Hardware

If you sell a hardware product, having it be differentiated enough where it can sell before the product is built is huge. Then you are effectively never bottlenecked by demand for the product and can ramp up supply as much as you'd like. Apple and Tesla dominate here.

Decision fatigue vs local optimization

One thing the book had me muse on about is 'where to decide on priority'. In an engineering team, this generally falls on the PM. The idea is that the PM can prioritize once and then individual engineers don't need to make decisions about what should come first, but instead, how to solve it.

How do you attribute productivity?

There's one section of the book where the protagonist is walking by a few people on his plant staff. They're reading a set of newspapers, and obviously not working. He asks them to start working, and they begin moving some parts from one part of the floor to the other.

Even though these workers are now doing something... is what they are doing actually productive?

I've found that in most organizations, this is actually quite hard to answer (even with tools like OKRs). Being able to tie the effect of an individual bug or feature improvement up to revenue or margin can be quite difficult. But if you can make those ties, it breeds a ton of good ideas and productivity.