When tool-wait exceeds 15% of workflow time in a frequent process, the tool is a constraint candidate — measure and consider replacement

Why This Is a Rule

Tool-wait time (loading, saving, rendering, searching, syncing) is the most common form of invisible constraint in knowledge work. You don't notice the 3-second save delay — but across 200 saves per day, that's 10 minutes. The 8-second app launch doesn't feel significant — but if you launch it 20 times daily, that's nearly 3 minutes. Individually trivial; collectively, these waits can consume 15-30% of workflow time without ever triggering the "this is slow" awareness that motivates a tool change.

The 15% threshold provides the detection trigger: when tool-wait time crosses 15% of total workflow time in a frequently repeated process, the tool has become a binding constraint. Below 15%, the tool's wait time is noise — annoying but not throughput-limiting. Above 15%, every 10% reduction in tool-wait produces a measurable throughput gain.

The "frequently repeated" qualifier prevents over-reacting to slow tools used rarely. A once-per-month report that takes 5 minutes to render is not a constraint regardless of the wait percentage. A daily workflow where the tool is slow 50 times per day is a genuine constraint even if each individual wait is brief.

When This Fires

• After Before upgrading any tool, measure whether it's the actual constraint — time active work vs. tool-wait in your most important workflow's active-work vs. tool-wait measurement identifies high tool-wait percentages
• When a workflow feels sluggish but each individual step seems fast enough
• When deciding whether a tool upgrade is justified
• The final atom in the RL series: complements Before upgrading any tool, measure whether it's the actual constraint — time active work vs. tool-wait in your most important workflow (measure before upgrading) with the specific threshold that justifies action

Common Failure Mode

Tolerance of accumulated micro-waits: "It only takes a second to load" — but it loads 100 times per day. The individual wait is below the attention threshold; the aggregate wait is a significant constraint.

The Protocol

(1) For your most frequently repeated workflows, measure tool-wait time as a percentage of total elapsed time (Before upgrading any tool, measure whether it's the actual constraint — time active work vs. tool-wait in your most important workflow). (2) If tool-wait < 15% → the tool is not the constraint. Optimize elsewhere. (3) If tool-wait 15-30% → the tool is a moderate constraint. Investigate: can the wait be reduced through configuration, caching, or upgrading? If a simple fix exists, implement it. (4) If tool-wait > 30% → the tool is a severe constraint. Evaluate replacement tools (Define the specific job the tool must do in one sentence before evaluating — "capture ideas on phone, retrieve on laptop" beats "note-taking app", Limit tool candidates to 2-3 before evaluating — more options increase decision time and decrease satisfaction regardless of objective quality, Pick a tool with 5 minimum requirements, select the first that meets them, commit for 90 days — satisfice, don't maximize) with specific attention to speed in your high-frequency operations. (5) After any tool change, re-measure (Re-measure 2 weeks after any constraint fix: if local metric improved but total throughput didn't, the constraint has shifted elsewhere) to verify the wait time reduction translated into throughput improvement.