Calibrate your personal do-it-now threshold: set it where management overhead equals execution cost, not at an arbitrary 2 minutes

Why This Is a Rule

David Allen's "two-minute rule" uses 2 minutes as a heuristic for when immediate execution costs less than task management. But 2 minutes is an approximation — the actual breakeven point depends on your personal management overhead. If your task management system is lightweight (a simple list, minimal review), the overhead is low and the threshold should be lower (tasks under ~1 minute are worth doing now; above that, capture is cheaper). If your system has high overhead (complex project management tools, multiple review passes), the threshold should be higher (tasks under ~5 minutes are cheaper to do now than to manage).

The calibration method is empirical: take 10 recent small tasks and measure two things for each: execution time (how long the task actually took to do) and management overhead (processing, organizing into a list, reviewing later, re-engaging context, actually executing). The crossover point — where management overhead equals execution time — is your personal threshold. Below the crossover, do it now (execution is cheaper than management). Above it, capture for later (management is cheaper than immediate execution).

This personalization matters because the wrong threshold in either direction wastes time. Too low: you capture and manage tasks that would have been faster to just do. Too high: you interrupt deep work (Never apply the two-minute rule during maker time — a 2-minute interruption costs 25+ minutes in context recovery during deep work) for tasks that would have been cheaper to batch for later.

When This Fires

• When implementing GTD or any capture-and-process system and choosing your dispatch threshold
• When the default 2-minute rule feels either too generous or too strict
• When you want to optimize the boundary between "do now" and "capture for later"
• Complements Never apply the two-minute rule during maker time — a 2-minute interruption costs 25+ minutes in context recovery during deep work (never during maker time) with the calibration for when the rule does apply

Common Failure Mode

Accepting 2 minutes as universal truth. For someone with a streamlined capture system (30 seconds to log a task, 2 minutes to review and execute later), the actual threshold might be 90 seconds. For someone with a complex project management workflow (5 minutes to properly log, tag, and schedule a task), the threshold might be 5 minutes. Using the wrong number either creates unnecessary management overhead or unnecessary interruptions.

The Protocol

(1) Select 10 recent small tasks (1-5 minutes each). (2) For each, estimate or measure: Execution time (how long it took to actually do). Management overhead (time to capture + time to review + time to re-engage context + time to execute during processing). (3) Plot or compare: at what execution time does management overhead roughly equal execution time? This is your personal threshold. (4) Apply: tasks below your threshold → do immediately (during processing time, not maker time). Tasks above → capture for later batching. (5) Recalibrate when you change task management systems, since different systems have different overhead profiles.