Case Study 2: One Email, Four Passes — Watching Revision Do the Work

A composite example built from the kind of workplace email everyone has written badly at least once. Follow the passes; the point is to see revision change the document, not just polish it.

This case study does something the chapter argues is the heart of writing: it takes one document and moves it through the stages, so you can watch each pass do its specific job. The document is an email from a software team lead, Dev, to a cross-functional group, announcing that a feature launch is being delayed. It's a hard email — nobody likes delivering this news — which is exactly why the first draft is a mess and why revision matters so much.

The starting point: a fast, complete first draft

Dev does the right thing and bashes out a fast draft without editing. Here it is, exactly as it came out:

Subject: Update on the search feature

Hi all, I wanted to give everyone an update on where things stand with
the new search feature that we've been working on for the last couple of
sprints. As you probably know we were targeting the 15th for the launch.
Unfortunately we've run into some issues. The main thing is that during
load testing we discovered that the new search index doesn't perform well
under high concurrency - basically when a lot of users search at the same
time the response times spike way up, like 3-4 seconds in some cases which
is obviously not acceptable for a search feature. We think this is fixable
but it's going to take some time to re-architect the indexing layer, our
current estimate is about 2 weeks. There were also some smaller issues
with the UI that QA flagged but those are minor and mostly done. So
basically we're looking at pushing the launch to the 29th instead of the
15th. I know this is disappointing especially for the marketing team who
I think had some campaign stuff lined up. Sorry for the inconvenience,
happy to discuss if anyone has questions or concerns. Let me know.

This is a perfectly fine first draft. It's complete — everything the reader needs is somewhere in there. But it would land badly if sent, because it makes the reader work to find the two things they actually need (Is it delayed? To when?), and it buries the news in a soft, apologetic ramble. Now Dev revises. Watch the passes.

Pass 1 — Revise: structure and content (the big moves)

Dev's first revision pass ignores grammar entirely and asks the §5.4 questions: Is the right content here, in the right order, for these readers? Three big problems surface:

1. The lede is buried. The two facts every reader needs — delayed, and to the 29th — don't appear until two-thirds of the way down. A busy reader skimming on a phone might miss them entirely.
2. No clear action. The email ends with "let me know," which asks for nothing. What does Dev actually need? The marketing team needs to know so they can reschedule their campaign — that's a real action that's currently invisible.
3. Wrong emphasis. The technical detail about index concurrency is interesting to engineers and irrelevant to marketing, but it gets the most words. The decision and its consequences should lead; the technical why can be brief.

Dev makes the big moves — leads with the news, surfaces the action, and demotes the technical detail to a single line:

Subject: Update on the search feature

Hi all, the search feature launch is moving from the 15th to the 29th,
a two-week delay. Here's why and what it means for you.

Load testing turned up a performance problem: under high concurrency,
search response times spike to 3-4 seconds, which isn't acceptable. The
fix requires re-architecting the indexing layer, which we estimate at two
weeks. (The minor UI issues QA flagged are nearly done and aren't driving
the delay.)

What this means: Marketing, this affects the campaign timing you had lined
up around the 15th - can we sync this week to reschedule? Everyone else,
no action needed; I'll confirm the new date holds by the 22nd.

Happy to discuss. Thanks for the patience.

That's a different email. The structure now serves the reader: news first, brief why, then a clearly addressed action. This pass did 80% of the total improvement — and notice it touched almost no individual sentences for style. It moved, cut, and reframed. That's revision.

Pass 2 — Edit: sentences and words

Now, with the structure settled, Dev edits at the sentence level (the Chapter 3 toolkit). The subject line is vague — "Update on the search feature" tells the reader nothing actionable. A few sentences carry small bloat. Dev tightens:

• Subject line: Update on the search feature → Search launch moving to Mar 29 (was Mar 15) — now the email's core fact is visible before it's even opened.
• "isn't acceptable" → kept (it's already tight), but "which we estimate at two weeks" → "about two weeks" (cut the throat-clearing).
• "Happy to discuss" → kept (warm, brief, fine).

Subject: Search launch moving to Mar 29 (was Mar 15)

Hi all, the search feature is moving from March 15 to March 29 - a
two-week delay. Here's why, and what it means for you.

Load testing found a performance problem: under high concurrency, search
response times spike to 3-4 seconds, which isn't acceptable. Fixing it
means re-architecting the indexing layer - about two weeks. (The minor UI
issues QA flagged are nearly done and aren't driving the delay.)

What this means for you: Marketing, this hits the campaign timing around
the 15th - can we sync this week to reschedule? Everyone else: no action
needed, and I'll confirm the new date holds by the 22nd.

Happy to discuss. Thanks for the patience.

The edits are small and the email was already good after revision — which is exactly the point. Editing refines; revision transforms.

Pass 3 — Proofread: the final surface check

Dev reads it aloud (the §5.4 technique) and checks every surface detail like a paranoid stranger:

• Dates: "March 15," "March 29," "the 15th," "the 22nd" — consistent and correct. ✓
• The subject says "Mar 29" and the body says "March 29" — harmless, but Dev makes them consistent: both spelled out. ✓
• Names of the addressed group ("Marketing") capitalized consistently. ✓
• No typos; the dashes are intentional. ✓
• One catch: "Thanks for the patience" reads slightly oddly — Dev changes it to "Thanks for your patience." A tiny fix the ear caught that the eye had skated over.

Before and after, side by side

The lesson

Three things stand out. First, the first draft was necessary — Dev couldn't have revised toward a good email without a complete bad one to react to. Second, the revision pass (Pass 1) did the overwhelming majority of the work: it moved the lede up, surfaced the action, and fixed the emphasis. The editing and proofreading passes mattered, but they were refinements on a document revision had already made good. Third — and this is the trap to avoid — if Dev had skipped Pass 1 and gone straight from the first draft to editing, he'd have produced a grammatically clean, beautifully proofread email that still buried the news and asked for nothing. Polished, and useless.

That's the whole chapter in one document: draft fast, then revise hard, and don't mistake editing for revision. The passes aren't busywork. Each does a job the others can't.

The takeaway in one line: The same content, reordered and reframed in a single revision pass, became a different email — proof that revision (not polish) is where writing becomes good.