Never apply the two-minute rule during maker time — a 2-minute interruption costs 25+ minutes in context recovery during deep work

Why This Is a Rule

David Allen's two-minute rule ("if it takes less than two minutes, do it now") is excellent advice during processing time — clearing small tasks prevents them from clogging your system. But during maker time (deep work, creative sessions, focused coding, writing), the same rule is catastrophically destructive. The task takes 2 minutes; the context recovery takes 23-25 minutes (per Gloria Mark's interruption research at UC Irvine). The cost-benefit ratio inverts completely.

During deep work, your brain maintains a complex mental model: the architecture of the code you're writing, the argument structure of the essay, the relationship between design elements. This model exists entirely in working memory and takes 15-25 minutes to fully reconstruct after interruption. A "quick" two-minute email reply during a coding session doesn't cost 2 minutes — it costs 2 minutes of typing plus 23 minutes of reconstructing where you were in the code, what you were trying to do, and what you'd decided about the next three steps. The true cost is 12x the apparent cost.

The solution is temporal separation: the two-minute rule applies during designated processing time (email batches, admin blocks, transition periods). During maker time, small tasks are captured (jotted on a notepad, added to an inbox) for later processing, never executed immediately. This preserves the maker session's cognitive context while ensuring small tasks still get done — just not now.

When This Fires

• When a small task pops up during deep work and you're tempted to "just quickly do it"
• When designing time-block structures and deciding where the two-minute rule applies
• When maker-time blocks consistently produce less output than expected (hidden interruptions)
• When calculating maker-time efficiency and finding high interruption counts

Common Failure Mode

The "just one quick thing" cascade: during a coding session, you check email "for one second," see a message requiring a 2-minute reply, reply, see another message, reply to that, notice a Slack notification, respond... 45 minutes later, you're still "quickly" handling small tasks and your coding session is destroyed.

The Protocol

(1) During maker time: when a small task appears (email, message, remembered errand), write it down in a capture tool (notepad, inbox, quick-capture app) and immediately return to deep work. Do not evaluate, do not execute, just capture and return. (2) During processing time (admin blocks, transitions between activities): process the captured items using the two-minute rule. Items under 2 minutes → do now. Items over 2 minutes → schedule or delegate. (3) Treat your maker-time blocks as interruption-free zones: notifications off, email closed, phone in another room. The two-minute rule's temptation requires the small tasks to be visible; removing visibility removes temptation. (4) If your role requires responsiveness, create explicit "available" windows between maker blocks rather than being always-available. (5) Track: count interruptions during maker time. Each one represents 23+ minutes of lost context. Multiply interruption count by 25 minutes to see the true cost.