One Bottleneck at a Time
The core insight is simple: every system, whether it’s a factory or a software team, has exactly one constraint that limits its overall throughput at any given time. Improving anything other than that constraint doesn’t improve the system. It just creates inventory, and inventory is bad because it creates blockages.
Systems are fractal - at a large company, you look at the whole company and identify the bottleneck holding things back. But from the perspective of one group within that company, the bottleneck is something different. From a team in that group, it's different again.
Furthermore, there are meta-bottlenecks: is your software development process the bottleneck on fixing bottlenecks? Could it be that the process for changing the software development process is the bottleneck on software development changes that would remove the bottleneck on removing bottlenecks?
I find it unconvincing that the factory floor metaphor generally holds, but what I find compelling is the idea of picking an important thing and working it doggedly until it's fixed.
It's usually impossible to do more than make an educated guess that that thing is the actual bottleneck on some sub-graph of the whole fractal problem, but focusing on doing that thing will clarify the system around it and ensure that you can actually accomplish something at least.
(side note: oftentimes trying to answer the question, is this thing the bottleneck, yields extremely valuable insights and/or tooling)
(side note: sometimes, flattening a process so that it more resembles a factory floor than a branching graph can yield surprising simplicities and reveal wins. Other times the reverse. Life is complicated)