Tasks left undone, observations left unrecorded, replies yet to be written—these swirl about our minds, as if we’re rehearsing them over and over again to make sure they’re not forgotten. To get rid of this nagging and create a “mind like water” (to use the term in Allen, 2015), build systems to reliably close these open loops.
For instance: for operational to-dos, this means (Allen, 2015):
Taken together, these properties ensure that when you record a task, you can stop thinking about it. Ubiquitous capture isn’t enough, as most to-do systems demonstrate. If you don’t regularly review your task list and decide to delete or re-strategize lingering tasks, you won’t be able to trust that you’ll follow up on tasks you record.
See also A reading inbox to capture possibly-useful references.
Allen, D. (2015). Getting Things Done: The Art of Stress-Free Productivity.
Reliable inboxes are powerful because they let us Close open loops and focus on the work itself, rather than on meta-work.
But this story seems to recur constantly:
Inboxes only let us Close open loops if they’re reliable—that is, if you can add something to it with total confidence that it’ll get “handled” in some reasonable timeframe. “Handled” is fuzzy: you just need to feel that the fate of those items roughly reflects your true preferences. You’ll trust an inbox system which ends up dropping 90% of items if the other 10% were the only ones you really cared about. You won’t trust an inbox system in which 90% of tasks get done, but the 10% which don’t get done are the ones you really cared about.
In efficient inboxes, it may be easy to maintain this kind of confidence: the departure naturally rate exceeds the arrival rate. But most knowledge worker inboxes don’t look like this. The rates are highly variable, which creates bottlenecks. Not every item actually needs to get handled, but people are over-optimistic, so items accrue in a backlog.
Sometimes we can decrease the arrival rate; see e.g. Beware automatic import into the reading inbox. Usually we must also increase the departure rate, which is hard; see e.g. Triage strategies for maintaining inboxes (e.g. Inbox Zero) are often too brittle.
Matuschak, A. (2019, December). Taking knowledge work seriously. Presented at the Stripe Convergence, San Francisco.
Inboxes only work if you trust how they’re drained, and Inbox Zero is one approach to ensure that they do. It lowers items’ wait times (theoretically to one day) by aggressively increasing the departure rate.
In Getting Things Done, David Allen suggests that you can increase your queue's departure rate by strategically deferring, delegating, or dropping tasks. “Inbox Zero” is an elaboration by Merlin Mann. It ensures that you're increasing the departure rate enough by processing your entire inbox down to zero items each day. This is a blunt approach, but it does ensure that the departure rate always exceeds the arrival rate.
You have to make a decision about every item in your inbox. This is a significant cost, and it’ll only make sense to pay when inboxes are relatively small.
Explicitly deferring a task imposes an emotional cost, possibly unnecessarily: “inbox zero” is only necessary if the arrival rate always exceeds the departure rate. If the arrival rate is variable and sometimes sits below the departure rate, you can still handle everything in a reasonable timeframe.
Explicitly dropping a task is hard because Software interfaces often harmfully frame destructive operations as final decisions, not contingent preferences.
More practically speaking, Inbox Zero usually leads to deferral numbness: it’s too easy to punt a task over and over again. Allen suggests that one should periodically perform a reflective review to reconsider tasks which are repeatedly deferred, but these reviews require yet more decisions. Adherence seems to be low.
When processing the inbox in this way, there’s also a lot of pressure to simply do more of these tasks, which may not be what you actually want.
A more ideal mechanism would ensure that wait times remain tolerable, but the cycle time doesn’t necessarily have to be one day. We must also consider the number of decisions to be made. I’d rather make fewer decisions but tolerate a longer average wait time.
One possible instantiation: Spaced repetition can lower the stakes around destructive inbox-maintenance operations.
Allen, D. (2015). Getting Things Done: The Art of Stress-Free Productivity.
43 Folders Series: Inbox Zero | 43 Folders
Matuschak, A. (2019, December). Taking knowledge work seriously. Presented at the Stripe Convergence, San Francisco.
Inboxes only work if you trust how they’re drained, and usually that requires aggressively dropping lower-priority items. Some examples:
Those actions all feel weighty because they’re destructive. Sure, if you close the tab, you could always re-open it later, but you’re often afraid that if you close it, you’ll never see it again.
Such destructive actions often don’t correspond to what we actually mean. We often mean something like: if I have a light day in the next week (i.e. if the arrival rate is low), or if I have time in the next few evenings (i.e. if I temporarily increase the departure rate), I’ll check this out… but otherwise I won’t. The other tabs I have open are much more important right now.
Similarly, if you’re revising an essay, you might struggle with an interesting paragraph which doesn’t really belong. It feels destructive to delete the paragraph, and if you move it to a “graveyard” section, you don’t trust that you’ll ever see it again.
Typical software systems are over-formal. They insist on finality, though their users usually think in terms of relative preferences, contingent on context. On the other hand, systems which explicitly reify “priority” and “context” are typically over-fiddly and unusable. A better “core verb” is needed. One example of a possible solution: Spaced repetition can lower the stakes around destructive inbox-maintenance operations.
Matuschak, A. (2019, December). Taking knowledge work seriously. Presented at the Stripe Convergence, San Francisco.