What does it mean that bottleneck cascades?

Sometimes fixing one bottleneck reveals that a downstream constraint was hidden.

Example: You finally fix your writing bottleneck. For months, drafting was the constraint — you could only produce two essays per week. You implement a voice-dictation workflow, and suddenly you can draft five per week. But your output does not jump to five published pieces. It jumps to three, then stalls. You look downstream and discover that your editing step can only handle three drafts per week. You push through that with a structured revision protocol, and output rises to three point five — then stalls again. Now the bottleneck is your publication pipeline: formatting, scheduling, metadata, distribution. Each of these steps was always slower than you needed, but you never saw them because drafting was so slow that nothing ever reached them at volume. You had not one bottleneck. You had a cascade — three constraints stacked in series, each one hidden in the reservoir of the one before it.

Try this: Take the system you have been analyzing throughout this phase. Map every step from input to output. For each step, estimate its maximum throughput — the most units it could process per time period if nothing upstream were constraining it. Now mentally remove the current bottleneck. Which step has the next-lowest maximum throughput? And the one after that? Rank all steps from lowest to highest capacity. If the top three lowest-capacity steps are adjacent or in sequence, you have a probable cascade. Write out the cascade chain: 'If I fix [Step A], the next constraint will be [Step B] because its capacity is [X], and after that [Step C] because its capacity is [Y].' You now have a cascade map — a pre-mortem for your bottleneck intervention.