Inbox Zero for Founders Who Hate Email

Inbox zero, as usually taught, is a filing system: process each message, archive it, reach zero, feel calm. It works well for people whose email is mostly notifications.

It fails for founders, because a founder's inbox is not notifications. It is decisions other people are waiting on. Filing them faster does not help. The work is in the replying, and no amount of folder discipline touches that.

Here is a version that survives a real week.

Why the standard advice breaks#

The one piece of classic advice worth keeping is the batching. The rest assumes the hard part is organising, when the hard part is responding.

Sort by who is blocked#

Open your inbox and put every message in one of four buckets:

1. Someone is blocked on me. A customer waiting on pricing, a candidate waiting on a yes or no, a contractor who cannot proceed. These are the only genuinely urgent messages, and there are usually fewer than five.
2. I am blocked on someone. Nothing to do but track it.
3. Neither, but it needs a human reply. Intro requests, questions, thanks.
4. Nothing. Newsletters, receipts, noise.

Bucket 1 gets answered today. Bucket 3 gets a block twice a week. Bucket 2 goes onto a follow-up list — that is a different problem with a different fix. Bucket 4 should not have reached you at all.

Most replies are repeats#

Look at your sent folder for a week. You will find you write the same six or seven emails constantly: the intro accept, the intro decline, the "here's pricing", the "not right now, let's revisit in Q3", the scheduling ping.

You are hand-writing something you have already written forty times. That is the clearest possible case for handing the mechanical part to software: the correct output is one you would recognise instantly, which is exactly the boundary between what to hand off and what to keep.

The workflow that actually holds up:

1. Triage happens without you (bucket the queue).
2. The obvious replies arrive pre-drafted, unsent.
3. You read, adjust the two that need judgment, and send.

The critical detail is unsent. An assistant that sends on your behalf is a liability the first time it misreads a tone. Draft freely, send deliberately.

Two blocks, not continuous#

The cost of email is not the minutes spent replying. It is the interruption: you leave whatever required a running start, and pay again to return. Gloria Mark's UC Irvine work put recovery from a digital interruption at roughly 23 minutes, with about two intervening tasks before people got back to the original.

There is also a direct test of the batching advice. Kushlev and Dunn randomly assigned 124 adults to check email three times a day for one week and without limit for another. Stress was significantly lower during the limited week (Computers in Human Behavior, 2015). Their own caveat is worth repeating: most participants found the limit hard to keep, which is exactly why this needs to be a system rather than a resolution.

Two blocks a day — one late morning, one late afternoon — is enough for almost every founder. Anything genuinely urgent arrives by phone, because that is what people do when something is on fire.

The objection is always "but customers expect a fast reply". They expect a fast reply to urgent things. Nobody has ever churned over a four-hour response to a scheduling question.

Where an assistant helps#

The three mechanical pieces — bucketing, drafting the repeats, remembering who is still waiting — are what Jarvis is built for. It reads your mail locally on your Mac, drafts inside your actual mail client rather than a chat window you have to copy out of, and remembers the people and projects involved so "reply to Sarah about the deck" resolves without explanation.

It is free and open source, Mac-only, and 2.0 is in beta.

The two-week version#

• Week 1: just batch. Two blocks a day, notifications off. Change nothing else. Most of the benefit is here.
• Week 2: add bucketing, and pre-draft your five most repeated replies.

If after two weeks the inbox is still winning, the problem is upstream: too many decisions route through you. No amount of email tooling fixes an org design issue, even when the org is one person.