Declare information bankruptcy when backlog exceeds daily…
When information backlog in any queue exceeds your daily processing rate by more than 10%, declare that queue a bankruptcy candidate requiring immediate archive-and-reset rather than incremental catch-up.
When This Fires
- When any information queue (email inbox, reading list, notes inbox, task list) is growing faster than you can process it
- When the inbox count has been increasing for 2+ weeks despite regular processing
- After vacations, illness, or other periods that created processing gaps
- Complements Process inboxes sequentially top-to-bottom, never… (sequential processing) by resetting the queue when sequential processing can't keep up
Common Failure Mode
Guilt-driven incremental attempts: spending entire weekends trying to process a 500-item backlog, getting through 200, feeling exhausted, and returning Monday to find 50 new items. By Friday, the backlog is back to 350. The incremental attempt consumed a weekend and produced zero net reduction. Bankruptcy would have taken 5 minutes and produced a clean slate.
The Protocol
(1) Measure your queue: how many items are in the backlog? How many new items arrive daily? How many can you process daily? (2) If daily inflow > daily processing capacity → bankruptcy is needed. The deficit will only grow. (3) Select all items in the backlog. Archive them in a dated folder: "Email Bankruptcy 2026-03-30." Do not review individual items (During triage, scan surface indicators only — opening… — scanning during reset defeats the purpose). (4) Start fresh with an empty queue. From this moment, process new items as they arrive at the daily rate. (5) If something from the archived backlog was genuinely important, it will resurface: someone will follow up, a deadline will trigger a reminder, or you'll remember and search the archive. The 95% that doesn't resurface was safely ignorable.