Beeminding a Backlog

Collaborating with Braden Shepherdson.

The most important example, for most of us, is your email inbox. Unless you use the Inbox River method, in which case your inbox doesn’t count.

Assumptions:

1. You consider every email that arrives in your inbox
2. You don’t akratically snooze things, i.e., schedule things to return to your inbox later out of pure procrastination

Constraints:

1. The system must not incentivize you to keep things in a separate queue (including your brain) to avoid backlog growth
2. No starvation — an aging task has to eventually become the most urgent thing (or be deliberately abandoned)
3. Tolerate burstiness — lots of new tasks/emails coming in at once shouldn’t derail you

Idea:

A task’s value is its age in days, squared. So 0 for tasks arriving today, 1 for yesterday, 4 for 2 days ago, etc. Beemind a hard limit of 100 for the sum of the task values in the backlog.

Proposal for GmailZero by dsernst

Instead of measuring the total number of inbox messages, measure how many days old the messages are.

The way I personally use Inbox Zero is as a to-do list / triage system. So old messages in my inbox are things that I have been putting off for a long time.

I would be interested in a system to encourage me to keep my inbox fresh. “No messages older than x days old allowed,” with x decreasing.

Mark Forster on Backlogs

Here’s the super short version of Mark Forster’s advice on backlogs: Isolate the backlog and [bee]mind it separately.

Rationale: If you mix backlog processing with inbox processing then (1) it’s just kinda demoralizing to feel like the red queen and (2) you’re driving blind, with no feedback loop on whether your inbox processing is sustainable. You need to hit inbox zero every day, even if you do it by letting things fall on the floor, because you need to be in control of what falls on the floor.

The Inbox River Method

Some people can get away with the river approach (thanks to John Langford for the metaphor), where they can trust themselves to pull out anything sufficiently important as the emails flow past. I cannot be trusted with that approach, since I persist in watching important emails flow past into the vast sea that is my inbox and delusionally insisting that I’ll totally get to that later.

Conclusion

If you’re like me — super akratic about your inbox — then you have to somehow be an inbox zeroer. If you’ve slipped and have a backlog then you’re suddenly the red queen on a slippery slope. Hence: isolate the backlog, keep inbox zeroing, beemind the backlog separately.

Related Reading

1. Mark Forster sagely points out that this applies to any kind of backlog (personal debt, for example)
2. Sacha Chua and Emacs’s Org Mode
3. Brent Yorgey’s Beeminding For Fun And Profit. Summary: “The basic idea is that I have a filter set up to show me the five least recently edited tickets (I do this with FogBugz but there are lots of ways you could do something similar), and a Beeminder goal to spend a certain amount of time per week working on one of them. Once I make progress on a ticket I add a comment saying what I did, so it automatically drops off the list (and eventually cycles back around). This is all loosely based on http://markforster.squarespace.com/autofocus-system/ which is where I got the idea. In theory I could still let some tickets languish in that top five and always choose to work on other ones; in practice I do tend to eventually get around to working on even the most odious (either because four even more odious things come along, or because I eventually feel bad enough about letting it sit there).”
4. Daily beemail: “email heuristics”
5. Mark Wilson on Outsmarting My Inbox
6. Chipmanaged’s Star System