When the bottleneck is waiting, not processing — reduce work-in-progress first, because cycle time = WIP / throughput
When a workflow bottleneck is a waiting step rather than a processing step, reduce work-in-progress before attempting to speed up any active processing, because Little's Law dictates that cycle time equals WIP divided by throughput.
Why This Is a Rule
Not all bottlenecks are processing bottlenecks. Many workflows are slow not because any step takes too long to execute but because work waits between steps: waiting for approval, waiting for a collaborator's input, waiting for a tool to become available, waiting for your own attention to return to the task. When the bottleneck is waiting rather than processing, speeding up the processing steps has zero effect — you're optimizing the wrong thing.
Little's Law (L = λW, or equivalently, cycle time = WIP / throughput) provides the mathematical foundation. If you have 10 tasks in progress and your throughput is 2 tasks per day, your average cycle time is 5 days — regardless of how fast each individual step is. The waiting time is a function of queue depth, not processing speed. To reduce cycle time when waiting dominates, you must reduce the number of items competing for attention (WIP), not speed up the processing of any individual item.
Applied to personal workflows: if you have 12 half-finished projects, each "waiting" for your attention, the average time to complete any one of them is enormous not because they're hard but because 11 others are in the queue ahead of it. Reducing active projects from 12 to 3 would dramatically reduce completion time per project even if you don't work any faster on each one.
When This Fires
- When workflow measurement (Measure actual elapsed time over 3-4 cycles before optimizing — felt difficulty systematically misidentifies bottlenecks) reveals that most elapsed time is idle/waiting time rather than active processing
- When multiple projects or tasks are in parallel and none seem to finish
- When optimizing processing speed hasn't reduced overall cycle time
- When work feels "stuck" despite each individual step being reasonably fast
Common Failure Mode
Trying to "work faster" when the problem is "working on too much simultaneously." Processing speed optimization is the default intervention because it feels productive and visible. But when 80% of cycle time is waiting in queues, doubling your processing speed only addresses the 20% — a maximum 10% improvement. Halving your WIP addresses the 80% directly.
The Protocol
(1) Measure your workflow and classify each time segment as "actively processing" or "waiting/idle." (2) If waiting time > processing time → the bottleneck is WIP, not speed. (3) Reduce WIP: limit active projects to 2-3, finish before starting, use explicit WIP limits (kanban-style). (4) For external waits (approvals, collaborator input): batch the requests, make the wait explicit and visible, and work on other steps while waiting — but don't start new projects to fill the wait. (5) Re-measure after WIP reduction. Cycle time should decrease proportionally to the WIP reduction, confirming the diagnosis was correct.