What does it mean that after fixing one bottleneck another emerges?

The constraint shifts — return to step one and find the new bottleneck.

Example: You spent three weeks fixing your decision-making bottleneck. You built a decision journal, pre-committed to weekly priorities every Sunday night, and reduced your average decision latency from 3.2 days to 0.8 days. Throughput surged — for about ten days. Then it plateaued. You are deciding faster than ever, but now your task list is full of decided, ready-to-execute items that you cannot get through fast enough. Work-in-progress balloons. Deadlines stack. You feel the same frustration you felt before, but in a different location. The constraint has moved. Decision-making is no longer the bottleneck — execution capacity is. You need fewer concurrent projects, deeper focus blocks, or delegation, none of which your decision-speed optimization addresses. The old solution is irrelevant to the new problem.

Try this: Return to the bottleneck you have been working on throughout this phase. Assume, hypothetically, that you have fully resolved it — that the constraint is gone, throughput at that stage is unlimited. Now ask: where does the queue build up next? What stage of your personal system would become the new slowest point? Write a one-paragraph description of this predicted next bottleneck. Then look at your current system honestly: is there any evidence the constraint has already begun to shift? Are you seeing improvement at the old bottleneck but stagnation in overall output? If so, you may already be optimizing a former constraint while the new one goes unaddressed. Name the new constraint explicitly and prepare to run the full measurement protocol from L-0945 on it.