Speed As Default

Thesis: Quick-to-respond is a generally dominant strategy. Ben Kuhn, "Impatient": faster replies get more feedback, more opportunities, and pleasantly surprise people — which compounds. Slow replies lose deals, lose momentum, and signal low priority. Default to fast. Slow is a deliberate exception, not a passive accumulation.

The principle is pleasantly-surprising response time, not panicked reactivity. Pleasant surprise is the signal that you're outpacing the field. If people stop being surprised, raise the bar.

The Project Lens — 5 questions for any work

Run through these at the start of every project session and before shipping anything:

1. Ship lens — What's the smallest version of this I could put in front of a human in the next hour? Ship that; iterate from reactions.
2. Response lens — Who is waiting on me right now? What reply unblocks them in ≤2 minutes? Send it before doing anything else.
3. Decide lens — Is this decision reversible within a day? If yes, decide in 60 seconds. Stop deliberating on cheap-to-undo things.
4. Ask lens — Is there a question whose answer I need? Send it now, work on something else while I wait. Do not batch questions into a single polished email — lose the parallelism.
5. Compression lens — Where am I adding days of delay that add no value? (Weekly reviews, "I'll do it tomorrow," scheduled-for-later messages I could send now.) Cut it.

Response-time targets (default ladder)

Targets are defaults, not rules. The point is that delay costs real things (opportunities, feedback loops, relationships) and must be paid for, not drifted into.

Integration with batching & deep work

Speed does not conflict with batching. It applies within each batch:

• Batching keeps the inbox from owning the day (deep work survives).
• Speed keeps the batch window from dribbling into low-throughput checking.
• During a batch: clear every item. No "I'll reply later" — reply now, or archive/decline now. No reply left for the next batch unless it genuinely needs thinking time.

Same for deep work: speed applies to the artifact, not the interruption. During a block, ship the smallest useful version. Between blocks, clear the inbox fast.

When NOT to rush — deliberate carveouts

Speed is the default. These are the only legitimate reasons to slow down:

• Relational/emotional messages where tone matters more than latency (conflict, condolences, apologies). Sleep on it when the stakes are the relationship, not the outcome.
• Writing that will live >1 year (public essays, reference docs, contracts). The reader-hours saved by better prose exceed the hours spent polishing.
• Irreversible high-stakes decisions (firing, quitting, moving, expensive commitments). Slow is cheap insurance.
• Fatigue tax — when tired enough that a mistake would cost more than the delay. Sleep, then reply.

If a message doesn't fit one of these buckets, it belongs in the fast path.

Implementation intentions

• IF I open my inbox → THEN every item gets a reply, archive, or decline before I close it. No "come back to this."
• IF I notice I'm about to say "I'll send it tomorrow" → THEN send a v0 now, plus a line saying "more to follow if needed."
• IF I notice I need information from someone → THEN ask within 60 seconds, then do other work while waiting.
• IF I'm weighing a decision for >60 seconds → THEN ask "is this reversible within a day?" — if yes, decide now and move.
• IF I start a project session → THEN first question is "what's the smallest version I can ship today?" — answer before opening anything else.
• IF a response has been sitting >24h → THEN reply now with whatever I have, even if incomplete.

Failure modes to watch

• Speed as anxiety, not default. If fast replies come from dread of an unread inbox, the system is being used wrong — you're trading distraction discipline for responsiveness theatre. Batching + fast-within-batch is the guardrail.
• Quality collapse. Fast v0s are fine; careless v0s to the wrong audience burn trust. Use the carveout list.
• Becoming available 24/7. Pleasant surprise requires asymmetry. Speed inside work hours; invisible outside them.
• Shipping noise. "Ship v0" means the smallest useful version, not the smallest version. If it teaches nothing, it's not v0 — it's busywork.

Metrics to glance at weekly

• Median email response time (Gmail can show this; or eyeball oldest thread in inbox).
• Count of items sitting in inbox >24h at week's end — target 0.
• Count of "I finally shipped the thing" moments — target ≥3/week.
• Friction diary: one line on any moment this week where speed hurt, so the carveout list can grow from evidence.