Case Study 2 — The Bad-News Email Nobody Wants to Send

A note on the example. The emails below are a composite—fictional but realistic, built from common workplace situations. No real person, company, or incident is depicted. We're illustrating how structure carries hard news, not reporting a real event.

The situation

Tomas runs a small data platform team. On a Wednesday, he discovers a problem with real teeth: a data pipeline his team owns has been silently dropping a fraction of records for about three weeks, which means a set of dashboards several other teams rely on — including the numbers the finance team used in a board update last week — have been wrong. The data can be backfilled and the pipeline fixed, but it will take a few days, and in the meantime he has to tell people whose work was built on bad numbers. This is the email nobody wants to write: it carries bad news, it implicates his own team's monitoring, and it goes to readers who will not be happy.

This is the chapter's hard-email case. It turns on structure (§19.7): the news has to surface early, the ownership has to be clean, and the plan has to lead — because bad news plus a credible plan is a manageable situation, while bad news alone is a fire drill.

The "before": how this email usually goes wrong

Most people, dreading this, write one of two bad versions. The first buries the news and drowns it in defensiveness:

❌ Before, version 1 (buried, defensive, no clear plan):

Subject: data pipeline issue

Hi all,

I wanted to flag something that's come up with one of our pipelines. As you may know, the events pipeline is a pretty complex piece of infrastructure with a lot of moving parts, and it processes an enormous volume of data every day. We recently became aware — through some routine checking — that under certain edge-case conditions, when upstream latency spikes in a particular way, the pipeline can occasionally fail to capture a small subset of records. This is a known class of problem in distributed systems and is genuinely difficult to detect because the failures are intermittent and don't throw errors. We're still investigating the full extent of it but it looks like it may have affected some of the data going back a few weeks. We take data quality extremely seriously and we're looking into how to prevent this kind of thing going forward. We'll keep you updated as we learn more. Apologies for any inconvenience.

Read that as the finance lead, who put these numbers in front of the board last week. What do they learn? That something happened, to some data, going back a few weeks, extent unknown, fix unknown — and they have to infer that their board numbers might have been wrong, because the email never says so. The defensiveness ("complex infrastructure," "known class of problem," "genuinely difficult to detect") reads as Tomas building a case for why it isn't his fault — the opposite of reassuring. No plan, no date, no scope of impact, and no answer to the one thing the finance lead most needs: were my board numbers affected, and what do I do now? The email will trigger a flurry of anxious replies asking exactly the questions it should have answered.

The over-corrected version is no better: panic-and-grovel — a wall of apology and alarm ("major incident," "I feel terrible"), still no scope and no plan, spreading fear without giving anyone anything to do. Both fail the same way: they leave the reader sitting in uncertainty.

The "after": the bad-news structure, executed

Before writing, Tomas did the work that makes a good bad-news email possible: he scoped the impact (which dashboards, which date range, who relied on them), confirmed the fix and a realistic timeline, and identified what each affected team needed to do. Then he wrote this — and, because the finance impact was serious, he called the finance lead first and sent this as the written record and the broader notice.

✅ After (news early, owned, plan-and-impact leads, a path forward):

Subject: Action needed: events dashboards were undercounting May 12–June 4 — fix + backfill plan inside

Hi all,

Bad news, and I want you to have it straight: our events pipeline was dropping roughly 4–6% of records between May 12 and June 4, so any dashboard built on it has been undercounting for that window. That includes the Engagement, Funnel, and Revenue-Attribution dashboards. If you used those numbers for anything that matters — finance, I'm thinking of last week's board update specifically — please treat the May 12–June 4 figures as low until we've backfilled. I'm sorry; this is on us, and our monitoring should have caught it sooner.

What was and wasn't affected: - Affected: the three dashboards above, May 12 – June 4 only. Undercount of ~4–6%; direction is always low, never high. - Not affected: all data before May 12 and after June 4; the raw warehouse tables (we can fully reconstruct from these); any dashboard not fed by events.

The plan: 1. Fix shipped this morning — the pipeline is capturing correctly as of today (verified against the raw source). 2. Backfill the missing May 12–June 4 records — running now, corrected dashboards by Friday EOD. 3. New monitoring — a daily record-count reconciliation against the source, so a gap like this alerts within hours, not weeks. In place by next Wednesday. 4. I'll send a confirmation Friday once the backfill is verified, with before/after numbers so you can see the corrected figures.

What I need from you: if you reported any May 12–June 4 figures externally (to a customer, a board, a partner), reply or ping me and I'll get you the corrected numbers first, today if you need them. Finance — I'll call you straight after this to walk through the board figures.

Happy to jump on a call with any team that wants to talk through impact. This one's on us to make right, and we will.

— Tomas

Why it works, against the four moves (§19.7):

1. The news is early and unmissable — subject line plus first sentence, stated plainly ("dropping roughly 4–6% of records… undercounting"). He even names the high-stakes case (the board update) so the most-affected reader knows at once this is about them.
2. The context is owned in one clean sentence — "this is on us, and our monitoring should have caught it sooner." No paragraph of distributed-systems excuses. Owning it plainly reads as more trustworthy than defending it — and it's shorter.
3. The plan leads, concrete and dated — fix shipped, backfill by Friday EOD, new monitoring by next Wednesday, a verification checkpoint Friday. This converts panic ("how bad is this, is it still happening?") into confidence ("it's stopped, bounded, on a schedule"). The "what was and wasn't affected" section pulls its weight too: bounding the blast radius ("never high," "before May 12 is fine," "raw data is intact") shrinks the fear.
4. It says exactly what each reader must do — anyone who reported figures externally gets a clear action and a priority offer; finance gets a personal call. No one is left to invent their own next step.

Note the channel judgment: for the sensitive piece (finance's board numbers), Tomas called first and used the email as record and broader notice. Some news shouldn't be broken in text — he told the most-affected person directly, then wrote to confirm and inform everyone else. Talk to deliver the hardest part; write to record and to scale.

The "no" variation

The same discipline rescues the email's harder cousin — the "no." A day later, a product manager asks Tomas's (now visibly stretched) team to take on a new urgent request this week. Tomas can't; saying so badly would either over-promise and slip again, or go silent and leave the PM hanging. The clean no:

✅ The "no" (acknowledge → clear no → reason → door open):

"Thanks for flagging this, and I get why it's urgent. I can't take it on this week, though — my whole team is heads-down on the pipeline backfill through Friday and I won't add anything that risks that landing on time. Two options: I can pick this up first thing Monday and have it to you by Wednesday, or if it genuinely can't wait, Priya's team has the same data access and capacity this week — happy to make the intro. Which works better for you?"

It acknowledges the ask, says the no plainly and early, gives one honest reason (and the reason — protecting the backfill — actually builds trust given the week's events), and leaves two real doors open. The PM gets a clear answer and a path forward, in four sentences, with no guilt and no silence.

The lesson

Hard emails — bad news, the no — feel like they're about finding the right words to soften the blow. They're not. They're about structure that serves the reader's real need, which under bad news is always the same: what does this mean for me, and what happens now? Surface the news early, own your part in a sentence, lead with a credible dated plan, and tell each reader what to do — and the identical bad facts land as "competent people are on it" rather than "we have a disaster." The words matter least; the order matters most. And when the news is serious enough, the bravest and kindest move is to leave email entirely and pick up the phone — then write to record what you said.

Related: Chapter 19 §19.7–§19.8 · Case Study 1 · Exercises