Case Study 2 — The Talk With No Backup (A Contrasting Scenario)
A worked contrast to Case Study 1. Same kind of failure, opposite preparation, opposite outcome. This is a composite, fictional-but-realistic account assembled from the failure patterns this chapter warns about — not a portrait of any real person.
The setup
Mara is a strong engineer giving her first conference talk: a twenty-minute slot on a real-time analytics service her team built. The work is genuinely impressive. Her preparation, though, follows the path of good intentions and bad habits.
She built the slides — and the slides are the talk, in her mind. Several are dense: a wall-of-text architecture overview, a slide with twelve config parameters, a results slide with three small charts and a paragraph of caption. She practiced by reading through the slides silently the night before; it "felt like about twenty minutes." She did not rehearse out loud, did not time it on her feet, and did not mark cut points. She planned to open with a title slide and "Hi, I'm Mara, today I'll cover the architecture, the implementation, the results, and some future work."
The centerpiece is a live demo of the dashboard updating in real time as events stream in. It depends on a websocket connection to a backend running in her company's cloud — reachable only over the internet. She ran it successfully on her laptop "a hundred times." She did not record a backup. She did not consider the venue network. She arrived five minutes before her slot and plugged in for the first time as the previous speaker was wrapping up.
The cascade
It goes wrong in layers, each failure compounding the last — the inverse of Raj's case, where each precaution bought back a margin.
The opening leaks confidence. The title-slide-and-agenda opening earns no attention; a few laptops open in the first thirty seconds. Then, rattled by the cool room, Mara adds an apology she'd half-planned: "Sorry, I threw a lot of these slides together kind of last-minute, so bear with me." The audience's estimate of the talk drops before they've judged it.
The timing was never real. The silent read-through badly underestimated her spoken length — she's really at twenty-six minutes, not twenty. Eight minutes in, she's only two slides past the intro and can feel she's behind. With no planned cut points, she does the instinctive, wrong thing: she speeds up. Her most important sentences slur past; the audience, already at the edge of keeping up, falls off.
The dense slides force the worst delivery. Facing the wall-of-text architecture slide, she has two bad options and picks reading it aloud, word for word, with her back half-turned to the screen. The room finishes reading it in eight seconds and waits, bored, while she narrates the same words more slowly. The twelve-parameter slide is unreadable from row five; she says "you can't really see this, but trust me, it's all configurable."
The demo dies — and there's no net. Fourteen minutes in, she launches the demo. The websocket can't connect: the conference network blocks it. A spinner spins. Mara stares at it. She re-clicks. She refreshes the browser. "It's, um, it usually connects right away… let me just…" She tries a different browser tab. Ninety seconds pass — ninety seconds of a spinning loader and a visibly unraveling speaker. With no recording and no screenshots, she has nothing to fall back on. Finally: "Okay, well, it's not cooperating, so you'll just have to imagine it — it updates in real time, it's really cool." The single most convincing part of her talk has become its most memorable failure, and she has nothing to show in its place.
The conclusion never arrives. The lost demo time plus the slow start means the chair holds up a 2 minutes card while Mara is still three slides from the end. She rushes, drops her actual conclusion, and ends — out of time, mid-thought — on "...so, yeah, that's basically the gist of it. Any questions?" Her most-remembered moment is a content-free stumble.
Q&A finishes the job. A questioner asks, with mild skepticism, how the system behaves under network partition. Mara, frazzled and defensive, bluffs: "Oh, it handles that fine, it's all designed for that." It is not, fully, and the questioner — who works on distributed systems — can tell. One detectable bluff casts doubt back over everything she'd said that was true.
The autopsy
Every failure traces to a decision made (or skipped) before she stood up. Line them up against Raj's choices in Case Study 1:
| Failure on stage | Root cause (in preparation) | What Raj did instead |
|---|---|---|
| Lost the room in the first 30 seconds | Title-slide opening, no hook | Rehearsed hook that opened a loop |
| Pre-apologized, leaked low confidence | The "throw it together" habit + nerves | Presented without apology |
| Ran over, got cut off, lost the conclusion | Silent read-through; no out-loud timing; no cut points | Rehearsed aloud to ~87%; planned cuts |
| Read dense slides verbatim, back to room | Slides built as documents, not cues | Assertion–evidence cue slides |
| Demo died with no recovery | No backup recording, no screenshots; depended on venue network; tested only "on my machine" | Recorded backup; one-line recovery; early projector test |
| Bluffed a Q&A answer and got caught | No Q&A prep; bluff instinct under pressure | Bridge: limit → what's known → next step |
None of these required more talent than Mara has. They required the unglamorous preparation this chapter keeps insisting on: rehearse out loud against a clock, design slides as cues, record a demo backup, plan your cuts, and rehearse honest answers to the hard questions. Mara's content deserved a better talk than her preparation gave it.
The lesson in one sentence: Delivery failures are rarely failures of talent or even of the moment — they are failures of preparation that show up in the moment, and every one of them had a cheap, boring fix available the week before.
The encouraging corollary: because the fixes are preparation, not personality, Mara's next talk can be Raj's. She doesn't need to become more charismatic. She needs to rehearse out loud, build cue slides, and record a backup. That's learnable in an afternoon.
Questions for reflection
- Pick any three of Mara's on-stage failures and trace each to the specific section of Chapter 31 that would have prevented it.
- Mara sped up when she fell behind. Walk through what should have happened from the moment she realized she was behind, using 31.2 (timing, cut points, protect the conclusion).
- The bluffed Q&A answer "cast doubt back over everything she'd said that was true." Explain, in terms of the chapter's integrity argument, why one detectable bluff is so much more costly than simply saying "I don't know, but here's how I'd find out."
- Mara's content was genuinely good. Write two sentences you'd say to her — in the constructive, critique-the-work-not-the-person spirit of Chapter 34 — to help her see that the fixes are preparation, not personality, and that her next talk can be excellent.
Back to: Chapter 31 · Case Study 1 · Exercises · Key Takeaways