When the bottleneck is waiting, not processing — reduce…
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.
When This Fires
- When workflow measurement (Measure actual elapsed time over 3-4 cycles before…) 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.