Measure actual elapsed time over 3-4 cycles before optimizing — felt difficulty systematically misidentifies bottlenecks

Why This Is a Rule

The software engineering maxim "profile before you optimize" exists because developers' intuition about performance bottlenecks is reliably wrong. The same applies to personal workflows: the step that feels slowest (usually the most cognitively demanding or emotionally aversive) is often not the step that takes the most clock time. You might spend 15 minutes dreading and starting a report (feels like the bottleneck) while unknowingly spending 45 minutes in email triage (feels like "just checking email").

Three to four measurement cycles are required for two reasons. First, single measurements are noisy — one execution might be interrupted, unusually fast, or contextually atypical. Three to four cycles reveal the stable pattern. Second, averaging across cycles catches the setup and transition overhead that single measurements miss: the 5 minutes of context-switching before each step, the 3 minutes of re-finding where you left off, the post-step decompression time.

The measurement must capture elapsed time (wall-clock start to finish), not effort time (time actively working). A step that takes 10 minutes of active work but 2 hours of elapsed time (because you procrastinate, get interrupted, or wait for inputs) is a 2-hour step for throughput purposes. Measuring effort alone would hide the real bottleneck.

When This Fires

• Before any attempt to optimize a personal or team workflow
• When you "know" which step is the bottleneck but haven't actually measured
• When workflow optimization efforts haven't produced the expected time savings
• Complements Optimize only the single slowest step — improvements to non-bottleneck steps are wasted effort regardless of their magnitude (optimize only the bottleneck) by ensuring you identify the actual bottleneck first

Common Failure Mode

Optimizing the most annoying step instead of the slowest step. The emotionally aversive step draws attention because it produces the most subjective suffering, but it may account for only 10% of elapsed time. Meanwhile, the genuine bottleneck (often something mundane like waiting for approvals, context-switching between tools, or manual data transfer) sits unoptimized because it doesn't feel like a problem.

The Protocol

(1) List all steps in your workflow. (2) For 3-4 execution cycles, record the start time and end time (wall clock) of each step. Include setup, transitions, and idle time within the step. (3) Calculate average elapsed time per step across cycles. (4) Rank steps by elapsed time. The longest step is your bottleneck — regardless of which step feels hardest. (5) Direct all optimization effort at the top-ranked step (Optimize only the single slowest step — improvements to non-bottleneck steps are wasted effort regardless of their magnitude). Do not optimize other steps until the bottleneck shifts. Re-measure after each optimization to verify the bottleneck has actually moved.