Situation walkthrough: a feature, end to end
The rest of the book taught moves; the last three chapters show whole games. This one follows a single piece of work (splitting a shared queue into per-tenant queues) from first thought to launch announcement, in transcripts, with annotations explaining what each sentence is doing and which chapter it comes from.
The cast: Alex, the engineer driving the change. Sam, the senior engineer who owns the queue. Dana, the engineering manager. Ines, an engineer on the consuming team. Priya, the product manager.
Scene 1: socializing the idea (Tuesday, DM)
Alex: Hi Sam, half-formed idea I want to sanity-check before I write
anything up. The retry storms all funnel through the shared
queue; what if we split it per tenant? You know this system
best: what's the first thing that breaks?
Sam: Ordering. Two tenants share the export pipeline, and today the
single queue gives us global order for free.
Alex: That's exactly the kind of landmine I was fishing for, thanks.
If I can solve ordering for that pipeline specifically, worth a
one-pager?
Sam: Worth it. Loop in Ines early; her team eats whatever we decide.
Annotations:
- "Half-formed idea" and "sanity-check" set the register: this is socializing, not proposing. Sam is invited to shoot at a balloon, not a battleship.
- "What's the first thing that breaks?" asks for the objection as a favor. Sam hands over the strongest counterargument in one word, four days before a review would have found it, and becomes a co-author of the fix instead of its opponent.
- "You know this system best" is true, cheap, and load-bearing (Chapter 2's specificity rule applied to respect instead of thanks).
- Sam's "loop in Ines early" is the senior reflex of Chapter 20: find the affected audience before the decision, not after.
Scene 2: the RFC thread (Thursday)
Alex posts the one-pager (structure per Chapter 4: problem, non-goals, two options, recommendation). Extracts from the comment thread:
Ines: For my own understanding: why per-tenant queues rather than a
priority lane for the noisy tenants? Not objecting, mapping the
option space.
Alex: Fair question. Priority lanes fix fairness but not blast
radius: a poison message still stalls everyone. Splitting gives
us both. Added a paragraph to the doc; the comparison was
genuinely missing, thanks.
Sam: blocking: the export-pipeline ordering issue. The doc's shim
covers new events but not the in-flight window during cutover.
I can't approve until that window has a story.
Alex: Confirmed, that's a real gap. Two candidate fixes, drafted in
section 5; can you pick holes by Monday? If neither survives,
the cutover design changes shape.
Priya: For visibility: no strong product opinion on internals, but the
BFCM freeze starts Nov 1. If cutover can't finish before then,
it waits until December. Not a comment on the design.
Annotations:
- Ines opens with a purpose tag. "For my own understanding" plus "not objecting, mapping the option space" declares the question's genre, so Alex answers with reasoning instead of defense.
- Alex's reply concedes value ("the comparison was genuinely missing"), improves the artifact, and thanks the critic: the receiving-critique posture, in miniature.
- Sam uses the review label grammar ("blocking:") in a design thread, states the exit condition ("until that window has a story"), and stays on the artifact. This is rung 5 of the disagreement ladder with zero adjectives; compare "the cutover plan is hand-wavy", which contains less information and more insult.
- Priya's comment shows the tag system carrying a constraint across the aisle without pretending to be an engineering opinion.
Scene 3: the design review (the following Wednesday)
Dana facilitates, because Alex is the author (Chapter 9's role split). Extracts:
Dana: Goal: a go/no-go on the split by :50, and if go, the cutover
date. Doc's been out a week. Blocking concerns first,
preferences after. Sam, yours is the open one.
Sam: Status update on my blocker: option B for the in-flight window
holds up. I tried to break it Friday and couldn't. I'm
withdrawing the objection.
Dana: So noted, and that's the review working as intended, for the
record. Remaining concerns?... Ines, you've gone quiet and
your team eats this. Genuinely fine, or being polite?
Ines: Mostly fine. One worry I can't quantify: our replay tooling
assumes one queue. It's our debt, not your design flaw, but
cutover day will hurt us.
Alex: Let me play that back: design is fine, but cutover lands on
your sprint as unplanned migration work. Right?
Ines: Exactly.
Dana: Then that's a sequencing decision, not a design one. Proposal:
go on the design today; Alex and Ines size the replay work
this week, and the cutover date comes from that sizing, before
the BFCM freeze or after it, honestly. Objections?... Going
once... Decided. Alex writes it up.
Annotations:
- Dana's opening is the chair's frame: goal, deadline, comment ordering, and the open blocker surfaced first, not saved for a dramatic finish.
- Sam withdrawing the objection out loud ("I tried to break it and couldn't") is what steelmanning looks like from the critic's side, and Dana marking it ("the review working as intended") pays the behavior in public credit so it happens again.
- "You've gone quiet and your team eats this" is the invitation move; note it targets the person with the stake, not just anyone quiet.
- Alex's "let me play that back" (Chapter 8) converts a vague worry into a nameable problem in one exchange, and Dana immediately re-files it as a sequencing decision: the what-from-how separation of Chapter 13.
- The close is decision, owners, date-for-the-date. Nothing evaporates.
Scene 4: the PR (two weeks later)
Sam: blocking: the tenant ID comes from the request header here, but
from the auth token in the enqueue path. If they ever disagree,
messages land in the wrong tenant's queue. That's a data
isolation bug, not a style point.
Alex: Good catch, and slightly horrifying. Fixed in 8c41d02: token is
now the only source, header is ignored. Added a test that
fails if anyone reintroduces the header path.
Sam: praise: the property test on ordering is excellent; stealing
the pattern. nit: two TODOs reference the old ticket number.
LGTM with nits, no re-review needed.
Alex: TODOs fixed. Thanks for the fast turnaround on a big diff;
merging on green.
Annotations:
- Sam's blocker names the failure scenario, not the adjective: the describe-don't-judge formula inside a review comment. "That's a data isolation bug, not a style point" explicitly justifies the label weight.
- "Good catch, and slightly horrifying" concedes fast with a human touch; the fix comes with a commit hash and a regression test, which is what "fixed" means between professionals (Chapter 6).
- "praise:", "nit:", "LGTM with nits": the whole severity grammar in three lines, plus "stealing the pattern", which is how engineers say I respect you.
Scene 5: the announcement (launch day)
Alex: Shipped: per-tenant queues are at 100% as of 14:00, two weeks
ahead of the freeze. What changes for you: a noisy tenant can
no longer slow anyone else's exports; p99 enqueue latency is
unchanged. Credit where due: Sam caught two design flaws that
would have been ugly incidents, and Ines's team absorbed the
replay migration on a full sprint. Runbook and dashboards:
go/tenant-queues. I'll watch the graphs through Friday.
Annotations: outcome first in audience terms, numbers where they matter, credit given by name with specifics in the visible channel, operational pointers, and an owner named for the watching period. Twelve chapters of technique, one paragraph.
👉 The feature is the fair-weather walkthrough. The next one is the storm: an incident channel from first alert to postmortem, where cadence, state words, and blameless grammar stop being style and start being the difference between a 40-minute outage and a 3-hour one. On to Chapter 22.