Writing: Email & Business CommsWriting for People Who Won't Read

The inbox is a scanning surface, not a reading surface. A subject line isn't a "title" — it's a routing label + priority label. It answers two questions for the recipient before they open anything: does this concern me, and do I deal with it now?

Krug was writing about web pages — but the inbox is worse: readers never even open the body. They scan the subject line and decide.

With 60 unread, the reader's action isn't "reading" — it's triage: half a second each to decide delete / archive / reply now / to-do. The subject line is the only information in that half-second. A good one does two things: ① front-loads the action — labels like [Decision needed][FYI, no reply] declare its nature; ② is specific enough to be searchable — three months later when you grep your inbox, "Update" and "Meeting" are noise; "Q3 launch date" is signal. A counterintuitive trick: write the subject line last — only once the body is settled do you know what you're actually asking for.

The revised lines tell the reader without opening the body: what it is, what they must do, by when, and your lean. Opening it is only to confirm details.

• ✓ Any email expecting action · broadcasts · decision emails you'll search for later
• ✗ Personal thanks, pure pleasantries — forcing a label feels robotic
• Mistake 1: writing "vagueness" — "about that thing"; they must open it to learn it's not for them
• Mistake 2: three unrelated topics in one thread — no one can search by subject later
• Mistake 3: [Urgent] as a habit — cry wolf, and no one believes the real one

Steve Krug Don't Make Me Think (2000) — scanning, not reading · David Shipley & Will Schwalbe Send (2007) — chapter on subject lines · Todd Rogers & Jessica Lasky-Fink Writing for Busy Readers (2023) — subject lines and response rates

Open the body with the conclusion, request, or decision, then give context and detail. One sentence in, the reader knows "what's in it for me, and what I must do" — whether they read on is up to them. This is the standard opening of military correspondence.

This is Day 2's Pyramid Principle applied to email. Novices default to "story order" — chronological: background → process → conclusion, with the ask buried in paragraph four. But the reader is in triage mode and leaves by paragraph two if "what do I do" hasn't surfaced. Moving the conclusion to sentence one hands the reader the choice of whether to keep reading — instead of forcing them to finish before they learn they could have skipped it.

• ✓ Approval requests · status reports · decision emails · almost all internal email
• ✗ Caution: highly sensitive / bad news — a blunt conclusion can read cold; lead with one buffer line (see Card 3)
• Mistake 1: writing a "topic summary" as the "conclusion" — "re: launch timing" isn't a conclusion; "I recommend 8/12" is
• Mistake 2: gave the conclusion but not "what they must do" — the reader still has to guess the action item
• Mistake 3: repeating the same line again at the end — trust the reader, don't pad

Kabir Sehgal "How to Write Email with Military Precision," HBR 2016 · U.S. Army AR 25-50, Preparing and Managing Correspondence — official source of BLUF · Barbara Minto The Minto Pyramid Principle — the parent of answer-first (Day 2)

Bad news, refusals, negative feedback — don't blur the message to "spare feelings." Be direct about the issue (state the problem clearly), caring about the person (mind the relationship). Vague kindness hurts more than a clear hard truth, because the other person never learns what to change.

Facing negative feedback, most people slide into two failure modes: Ruinous Empathy (caring but afraid to say it — hedging, hinting, mush; the signal never lands) or Obnoxious Aggression (direct but uncaring — labeling, attacking the person not the issue). To be "direct on the issue" without "attacking the person," use SBI: don't say "you have an attitude problem" (personal, vague, unchangeable); describe three facts — Situation–Behavior–Impact. Facts are hard to dispute; labels guarantee defensiveness.

• ✓ Performance feedback · declining a request · stopping a project · flagging issues in review
• ✗ Caution in writing: emotionally loaded, easily-misread feedback → do it in person / by call first; email only for the record
• Mistake 1: the "feedback sandwich" (praise–critique–praise) buries the core — they remember only the praise at both ends
• Mistake 2: when saying "no," piling on explanation and apology but never saying the "no" — they think there's still a chance
• Mistake 3: attacking the person, not the issue — "you're careless" is a label; "this missed 3 cases" is a fact

Kim Scott Radical Candor (2017) — the care × challenge framework · Center for Creative Leadership SBI Feedback Model — Situation-Behavior-Impact · Douglas Stone & Sheila Heen Thanks for the Feedback (2014) — the receiving side

The golden rule of async communication (email, Slack, docs): say the whole thing in one message — context, the question, your lean, and the response time you expect. Don't fire off "you there?" and wait. Every "wait for them to be online" is a two-way interruption.

Real-time communication requires everyone present at once — that's a luxury, not the default.

"You there?" is a way of offloading the thinking cost onto the other person: it spares you the effort of composing, but forces them to stop, ask back, and wait for you to type. The core of async writing is being self-contained — the reader, opening it at any moment, can act without follow-up. It is therefore inherently searchable and durable: a decision written in a doc is still there in six months; a consensus reached over live voice evaporates by the next day. To judge sync vs. async, ask one thing: does it need an immediate back-and-forth, or just one clear pass?

• ✓ Remote / cross-time-zone teams · deep-work roles · any collaboration the "interruption tax" can grind down
• ✗ Don't async: live crises, conversations that need emotional warmth, complex topics that take repeated clarification to align
• Mistake 1: opening with "you there?" — forces a round of zero-information back-and-forth
• Mistake 2: treating async as instant — sending then staring at it waiting, more anxious than sync
• Mistake 3: five topics in one message — they answer three and forget two; searchability goes to zero

Jason Fried & DHH It Doesn't Have to Be Crazy at Work (2018) · GitLab Handbook — Asynchronous Communication — a public template for remote work · Cal Newport A World Without Email (2021) — the harm of the "hyperactive hive mind"

• David Shipley & Will Schwalbe Send (2007) — the classic on email etiquette and structure; the subject-line chapter rewards rereading
• Todd Rogers & Jessica Lasky-Fink Writing for Busy Readers (2023) — behavioral-science experiments proving "shorter gets answered," with hard data on response rates
• Kabir Sehgal "How to Write Email with Military Precision," HBR 2016 — the best popular intro to BLUF, three minutes to read
• Kim Scott Radical Candor (2017) — the care × challenge framework, the modern bible of negative feedback
• Cal Newport A World Without Email (2021) — dissects the "hyperactive hive mind," the case for async and deep work as allies
• GitLab Handbook — Asynchronous Communication — the public playbook of the largest all-remote company