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.
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:
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.
There's a simple way to model any business (sort of like the conservation of heat).
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.
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.
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.
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.
The last section of the book deviates from the parable entirely and instead just talks about real world examples.
Some surprising things I learned...
What this all boils down to is Constraint Theory. When looking at any process there's five key steps to follow...
The other methodology here is the "drum-buffer-rope" method of synchronizing a production line.
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.
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.