Introduction

Software engineering runs on English. Not literary English: a narrow, practical dialect made of chat messages, pull request comments, design docs, standup updates, and meeting phrases. You can be an excellent engineer and still lose influence every day because your messages read as abrupt, your proposals get ignored, or your criticism lands as an insult when you meant it as help.

This book is a phrase-level playbook for that dialect. It is written for engineers who work in English-speaking or English-by-default teams, and it assumes nothing: not native fluency, not years of corporate exposure, not knowledge of what "PTAL" or "for awareness" means. Every situation comes with concrete wording you can copy, adapt, and reuse.

What "professional" means here

Professional does not mean stiff. On most engineering teams, "Hey, quick question about the deploy script" is perfectly professional, and "Dear Sir, I hope this message finds you well" is not; it signals that you have never worked in this environment. Professional means three things:

1. Right register. Register is the level of formality of your language. Chat with a teammate, an email to a customer, and a design review with a VP each call for a different register. Using the wrong one in either direction (too stiff with peers, too casual with executives or external partners) is the most common non-native mistake, and this book flags the right register for every phrase it teaches.
2. Respect under pressure. Anyone can be polite when agreeing. The professional skill is disagreeing with a design, reporting a slipped deadline, or escalating a blocked dependency without damaging a relationship. That is where most of this book lives.
3. Clarity as a courtesy. Vague messages tax the reader. Saying exactly what you need, by when, and what happens if you get no answer is not pushy; it is considerate, and it is how senior people write.

Don't be confused: polite and indirect are not the same thing. Professional English softens the person-facing part of a message ("I may be missing context, but...") while keeping the substance sharp and specific ("this adds a synchronous cross-region call on the hot path"). Beginners often do the opposite: they blur the substance ("maybe this is somehow not so good?") while accidentally attacking the person ("you did not think about errors"). The whole book keeps returning to this rule: soften the person, sharpen the substance.

The three channels

Almost everything you say at work travels over one of three channels, and each has its own norms:

A recurring mistake is porting the norms of one channel into another: writing emails like chat messages (no context, no subject discipline) or chat messages like emails ("Dear team, I hope you are doing well. I am writing to ask..."). Each chapter states which channel it is about.

How the book is organized

Everyday professional English covers the small interactions that set your reputation before any design discussion happens: greetings and pings, thanking people, and asking questions well, including the little purpose tags ("for awareness", "just in case", "for my own understanding") that senior people use constantly and nobody ever explains.

Design discussions is the heart of the book: how to propose a design, how to criticize one without saying "this is abhorrent", and the specialized language of code review.

Ceremonies and status covers the recurring rituals: standups and sprint status, meetings, hosting and moderating (chairing design reviews, driving sprint planning, running tech talks and brown bags), and the hardest genre of all, escalations and bad news.

The lexicon closes with reference material: describing technical situations (latency, error rates, data leaks, security compromises, code smells, with numbers instead of adjectives), the abbreviation decoder (FYI, TIA, LGTM, PTAL, EOD, and fifty more), the senior lexicon of high-level wording that principal engineers use (tradeoff, non-goal, blast radius, one-way door), the word list (succinct versus terse, legitimate, hallucination, and the chat glyphs like o/ and /s), phrasal verbs (spin up, dig into, pile up, "you're breaking up"), and the mistakes chapter: the specific errors that make competent engineers sound less senior than they are, and the structures (answer first, then explain) that make you sound articulate.

The written record covers the artifacts that outlive chat: bug reports, tickets, PR descriptions, commit messages, release notes, runbooks, and postmortems, each with a fixed anatomy that is faster to fill than to improvise.

People and audiences turns to the human genres: 1:1s, feedback, and career conversations (including promotion and pay), the social layer (joining a team, farewells, condolences, sick days, small talk), and talking across the aisle to product, design, support, and customers.

The situation room closes the book with full annotated transcripts, because phrases make sense only in motion: a feature from first pitch to launch announcement, an incident minute by minute, and the five hardest conversations, each line annotated with what it is doing and which chapter it comes from.

How to read it

If you want a course, read front to back; the chapters build on each other and every chapter ends with a pointer to the next. If you want a phrasebook, jump to the situation you are facing right now; every chapter is self-contained and cross-linked. The reference chapters (the decoder, the senior lexicon, the word list, and the phrasal verbs) work as lookup tables you will probably revisit for months.

One warning before we start: none of these phrases work as incantations. "I may be missing context" fools nobody if you then dismiss the answer. The phrases in this book are the surface of an attitude (assume good intent, argue about the work, make things easy for the reader), and they only work when the attitude is real.

👉 We start where every workday starts: the first message. What do "hey", "hi", and "hello" actually signal, why is a message that says only "hello" mildly rude in chat, and how do you open a conversation with someone you have never met? On to Chapter 1.

Greetings, openers, and pings

First messages carry more weight than they deserve. Before anyone has seen your code, they have seen your "hi", and people form fast (and unfair) impressions from it. The good news: greetings are a solved problem. There is a small set of openers, each with a known register, and once you know the table you stop thinking about it.

The greeting ladder

From most casual to most formal:

Rules of thumb:

• When in doubt, "Hi" wins. It is never wrong internally, and rarely wrong externally. "Hey" is fine with peers but can read as overly familiar with executives or strangers; "Dear" inside a company chat reads as odd.
• Use the name. "Hi Sam," beats a bare "Hi," in almost every context. Get the spelling exactly right; misspelling someone's name is a small mistake with an outsized negative effect. Copy-paste it if you are unsure.
• Avoid "guys" for mixed groups. "Hi everyone", "Hi all", "Hi team", or "folks" do the same job without assuming anyone's gender.
• Drop the greeting in ongoing threads. Once a conversation is running, re-greeting every message ("Hello again Sam,") is noise. Just continue.

Don't be confused: "Hey" in professional English is a greeting, not a shout. Some languages use their equivalent of "hey" only to call attention or to complain, so non-native speakers sometimes read "Hey Maria" as aggressive. In an English-speaking workplace it is the friendliest common opener, one notch more casual than "Hi".

The no-hello rule

The single most useful chat rule, so widely shared it has its own site (nohello.net): never send a greeting as its own message and then wait.

Bad (two messages, forces the other person to wait for the point):

  09:14  you: Hi Sam
  09:14  you: (typing...)

Good (one message, greeting and substance together):

  09:14  you: Hi Sam, quick question about the deploy pipeline: is the
         staging freeze still on for today, or can I ship #4132?

Why it matters: chat is asynchronous. A bare "hi" interrupts someone, tells them nothing, and obligates them to respond before they even know the topic. Putting the question in the first message lets them answer once, at a moment that suits them. The same rule kills the standalone "Are you there?", "Can I ask you something?", and "Do you have a minute?" messages: fold the actual ask into the same message ("Do you have a minute today for a question about the retry logic? Async is fine too.").

Opening with a stranger

Messaging someone you have never talked to (another team, another org) has a four-part shape: who you are, why them, the ask, and an easy out.

Hi Priya, I'm Alex from the payments team. I'm told you own the fraud
scoring service. We're seeing 502s from its /score endpoint since about
10:00 UTC and I'd like to rule out a client-side cause. Could you point me
at the right dashboard, or at whoever is on call? No rush if you're heads
down; a pointer any time today helps.

Notes on each part:

• Who you are: one clause. Name and team, nothing more.
• Why them: "I'm told you own...", "Your name is on the ADR for...", "Rafael suggested I ask you." This shows the ping is targeted, not spam.
• The ask: specific and small. Asking a stranger to "help me understand the fraud system" is a big favor; asking for a dashboard link is a small one.
• The easy out: "No rush", "whenever you get a chance", "happy to take this to whoever is the right person." Skip the easy out when it is actually urgent; see Chapter 10 for urgent wording.

Email openers and sign-offs

Email keeps a light formal frame even inside a company. A serviceable internal email:

Subject: Approval needed by Thu: staging DB upgrade window

Hi Dana,

We'd like to upgrade the staging Postgres cluster to 16 this Saturday,
02:00-04:00 UTC. Impact: staging writes unavailable for up to 30 minutes.
Rollback: snapshot restore, tested last week.

Could you approve by Thursday EOD so we can book the window?

Thanks,
Alex

Conventions worth copying:

• The subject line carries the ask and the deadline. Many people triage by subject alone. "Question", "Update", or "Hi" as a subject is a wasted line.
• Sign-offs by register: "Thanks," (when you asked for something), "Best," (neutral default), "Regards," / "Kind regards," (formal, external), "Cheers," (casual, common in UK/Australia tech). Avoid "Yours sincerely" and "Yours faithfully" in tech contexts; they read as a century out of date.
• Skip "I hope this email finds you well." It became a template cliché and now signals boilerplate. If you want warmth, be specific: "Hope the launch week wasn't too brutal." Specific warmth reads as human; generic warmth reads as automated.

Time zones and availability

Distributed teams have their own greeting etiquette:

• Skip time-of-day greetings in chat, or hedge them: "Good morning your time" or just "Hi". "Good morning" sent at the recipient's 9 pm is harmless but sloppy.
• Sending late is fine; expecting a late reply is not. The professional convention: "Sending this now so I don't forget; no response needed until your morning." Many people schedule-send instead, which is even cleaner.
• When you ping someone marked away or focused: "I see you're heads down; whenever you surface:" followed by the ask. It acknowledges the status without waiting on ceremony.

Live and video-call openers

Small talk before a meeting starts is standard in most English-speaking work cultures, and it is shallow by design: weather, weekends, launches, coffee. Two or three exchanges, then work. Useful stock phrases:

• Joining: "Morning, everyone." / "Hi folks." / "Hey, can you hear me OK?"
• Waiting: "Let's give it two minutes for people to join."
• Starting: "Alright, let's get started. The goal for this meeting is..."
• Meeting someone new: "I don't think we've met; I'm Alex, I work on the ingestion side of the pipeline." Then let them introduce themselves.

Don't be confused: "How are you?" / "How's it going?" in passing is a greeting, not a question. The expected reply is short and positive ("Good, you?"), after which real conversation may or may not follow. Answering with an actual status report ("Not great, my build has been broken since...") is a classic register mistake, though with close teammates it can be fine.

Reconnecting after a long gap

• "Hi Sam, it's been a while! Hope things are good on the infra side. I'm reaching out because we're about to touch the quota service again and I remembered you led the last redesign."
• One sentence of warmth, then the reason. Resist apologizing for the gap ("sorry for disappearing"); nobody was keeping score.

A note on emoji and reactions

In chat, emoji do real protocol work: a 👍 or ✅ reaction means "acknowledged, no reply needed", and 👀 often means "I'm looking at it now". Using reactions instead of "ok thanks!" messages keeps channels quiet, and most teams prefer it. Match your team's density: an emoji-free message in an emoji-heavy team reads as cold, and vice versa. In email and docs, keep emoji rare.

👉 The first message opens the door; what you do when someone helps you determines whether they help you twice. Next: how to thank people in a way that actually registers, why "thanks in advance" annoys some readers, and how giving credit in public is one of the cheapest high-return moves available to you. On to Chapter 2.

Thanking people and giving credit

Thanking sounds too basic to need a chapter. It gets one because engineers systematically get it wrong in two directions: generic thanks that register as nothing ("thanks!" after someone spent three hours debugging your problem), and missing credit, which quietly poisons collaboration. Calibrated gratitude is a skill, and senior people are conspicuously good at it.

The gratitude ladder

Match the size of the thanks to the size of the favor:

The two levers are specificity and visibility. Escalate either or both as the favor grows.

Specific beats generic

Generic thanks is social lubricant; specific thanks is information. Compare:

Generic:  Thanks for the review!

Specific: Thanks for the review, and especially for catching the race in
          the retry path. That one would have been a painful on-call page.

The specific version does three things the generic one cannot: it proves you read and understood their work, it tells them which of their efforts had impact (people repeat what gets noticed), and it costs you one extra sentence. Useful specific-thanks patterns:

• "Thanks for digging into this; the bisect must have taken a while."
• "Thanks for the thoughtful writeup. The failure-mode table made the decision easy."
• "I appreciate you jumping on this at 6 pm. It made the difference for the release cut."
• "This is exactly what I needed, thank you."

"Thanks in advance" and other pre-thanks

TIA ("thanks in advance") and "Thanks in advance for your help" are common, and a noticeable minority of readers dislike them: pre-thanking can read as presuming the person will comply, closing the conversation before they have agreed. You do not need to purge it, but there are strictly better options:

• "Thanks for taking a look." (thanks them for attention, not compliance)
• "Thanks for considering it." (explicitly leaves room for no)
• Ask cleanly, then thank properly after they deliver, with specificity.

Don't be confused: "Thank you" and "Thanks" differ only in register: "Thanks" is neutral-casual, "Thank you" a notch warmer or more formal, and "Thank you so much" is for real favors (overusing it for trivia devalues it). "Many thanks" is slightly formal-British and fine in email. "Thx" and "ty" are chat-only, and even there read as low-effort; a full "Thanks!" costs three more letters.

Public credit

Praise in public is one of the cheapest high-return moves in a professional toolkit, and it is doubly effective coming from senior people. Mechanics:

• Name the person, name the work, name the effect. In the team channel: "Shout-out to Dana: the flaky-test quarantine she built cut our CI retry rate from 14% to 2% this week."
• Credit upward. When presenting work that others contributed to, credit them in the room where it counts: "Most of the storage design is Ken's; I mostly reviewed." This costs you nothing (everyone knows presentations are team efforts) and builds the kind of trust that gets you help next time.
• Make credit durable when it matters. A message the person's manager can see ("Wanted to flag that Maria unblocked us twice this sprint, both times outside her own roadmap") lands differently from a channel emoji, and peer feedback during review cycles is the durable form. Two sentences is enough.

The inverse rule is absolute: never absorb credit for others' work by silence. You do not need to lie to take credit; you only need to not correct the record. People notice, and the reputation cost is permanent.

Responding to thanks

Short, warm, done:

• "Happy to help." / "Any time." / "Glad it worked out."
• "No problem." (fine among peers; in formal or external contexts prefer "You're welcome" or "My pleasure.")
• If a thank-you overstates your role, deflect accurately: "Glad it helped, though the actual fix was Priya's."

Do not deflect warmth into self-deprecation ("oh, it was nothing, I barely did anything, sorry it took so long"). Accepting thanks gracefully is part of the professional register.

Thanking reviewers and critics

The counterintuitive one: thank people for finding problems in your work. A reviewer who catches your bug before production did you a favor exactly equal to the incident that did not happen.

• "Good catch, fixed."
• "Ouch, you're right. Thanks for catching that before it shipped."
• "Fair point. I've reworked that section; PTAL." (PTAL: "please take another look", see Chapter 12.)

Teams where finding a flaw earns thanks find flaws early. Teams where it earns defensiveness stop finding them until production does. Your response to criticism is a vote for one of those cultures; more on receiving critique in Chapter 5.

👉 Greetings open the door and thanks keeps it open. The next everyday skill is the one that most directly affects how fast you grow: asking questions in a way that gets good answers, respects busy people's time, and, with a few small purpose tags like "for my own understanding", lets you question anything (including your tech lead's design) without sounding like you are attacking it. On to Chapter 3.

Asking questions and asking for help

Engineers are judged partly by the questions they ask. That cuts both ways: a sharp question raises your standing, and a lazy one ("it doesn't work, any ideas?") lowers it. This chapter covers the mechanics of asking well, plus a small but mighty set of phrases (the purpose tags: "for awareness", "just in case", "for my own understanding") that senior people use to label their messages so readers instantly know what is expected of them.

The anatomy of a good question

A good technical question answers four things before anyone asks:

1. Goal: what you are actually trying to achieve.
2. Attempt: what you tried.
3. Observation: what happened, exactly (error text, not "it fails").
4. Ask: the specific question.

Weak:   The deploy is broken, does anyone know why?

Strong: I'm trying to deploy #4132 to staging (goal). "make deploy-staging"
        worked on Friday; today it fails during the image push with
        "403: token expired" (attempt + observation). I've re-run
        "aws sso login" with no change. Has something changed in the
        registry auth, or is this on my side? (ask)

The strong version is answerable in one pass, shows respect for the reader's time, and often answers itself while you write it. Rubber-duck debugging is real: a third of well-formed questions die in the draft box because forming them exposed the answer.

The XY problem

The classic asking failure: you want X, decide Y is the way to get it, get stuck on Y, and ask only about Y. Helpers then burn time on Y when X had a much better route. Vaccinate your questions by always stating the goal:

XY trap:  How do I parse the process table output from inside the container?

Cured:    Goal: detect whether the worker process is alive from the health
          check. I was going to parse "ps" output; is there a better way?
          (Answer: yes, check the PID file or use a liveness endpoint.)

If someone answers your question with "what are you actually trying to do?", they suspect an XY problem. That question is a favor, not an evasion.

When to ask: the timebox rule

Ask too fast and you outsource thinking; struggle too long and you burn a day on what a teammate knew instantly. The standard compromise is a timebox: 30 to 60 minutes of genuine effort, then ask, showing what you tried. Two situations override the timebox:

• Ask immediately when something looks broken for everyone (CI down, staging dead), when you might be about to cause damage, or during incidents.
• Struggle longer when the struggle is the point (learning a codebase you will own) and nothing is waiting on you.

The phrase that makes early asking respectable is evidence of effort: "I've read the runbook and the last incident doc; both assume the primary is reachable, which it isn't. Before I improvise: is there a procedure for this?"

Purpose tags: telling the reader what kind of message this is

Professional chat and email are full of small prefix phrases whose job is to set expectations: does this need action, an answer, or nothing at all? Using them precisely is a quiet mark of seniority. The core set:

Two of these deserve special attention:

"For my own understanding" (and its siblings "help me understand..." and "so I understand the reasoning...") is the standard device for questioning a decision without contesting it. "Why did we pick DynamoDB?" can sound like an attack on the decision; "For my own understanding, why DynamoDB over Postgres here?" declares that you are gathering the reasoning, not relitigating it. This one phrase lets junior engineers safely question senior designs, and senior engineers use it on each other constantly. The contract: if you use the learning frame, actually be open to the answer. Using it as a disguised attack burns the phrase and your credibility. When you genuinely want to challenge the decision, say so honestly; Chapter 5 covers that wording.

"Heads-up" buys forgiveness in advance. Surprises annoy people far beyond their actual cost; the identical event, announced an hour earlier as a heads-up, costs almost nothing.

Don't be confused: "FYI" and "heads-up" overlap but differ in tense. FYI marks information that already exists ("FYI, the freeze started Monday"); a heads-up warns about something coming, usually caused by you ("Heads-up, I'm about to restart the staging DB"). Forwarding an email chain with just "FYI" is standard and means "read if relevant to you; I expect nothing."

Making questions easy to answer

Busy and senior people triage. Questions engineered for cheap answers get answered first:

• Closed beats open. "Should retries be capped at 3 or 5?" is a ten-second answer. "Thoughts on retries?" is a meeting.
• Offer options with a lean. "Two options: (A) backfill in place, slower but no downtime; (B) shadow table swap, faster but needs a write freeze. I lean A. Preference?" You did the thinking; they do the choosing.
• Default-forward. The senior favorite: "Unless someone objects by Thursday, I'll proceed with A." Nobody has to reply at all for the work to advance. Use it for genuinely reversible decisions, not as a trick to sneak past review; irreversible calls deserve an explicit yes.
• Batch small questions. Five separate pings a day fragment the other person's attention; one message with a short numbered list respects it. Number the items so answers can reference them by number.

Following up without nagging

The unanswered question is a fact of distributed work. The etiquette:

• Wait a reasonable interval (a day for routine things, less when urgent).
• Bump in the same thread, gently, once: "Bumping this." / "Gentle bump." / "Circling back on this; still blocked on the answer."
• Add new information or a deadline if you have one: "Bumping; this now blocks the Thursday cut."
• After one or two bumps, change channels or people, and say so plainly: "I'll bring this to standup since it's getting urgent." That is normal routing, not tattling; see Chapter 10.

Avoid the passive-aggressive classics: "As per my previous email", "As already stated", "Per my last message". Native readers hear all of these as barely veiled hostility. If you need to repoint someone at earlier content, stay neutral: "Resurfacing the question from Tuesday:" or "Reattaching the doc for convenience."

Admitting ignorance well

The highest-signal phrase in this chapter costs the most to say early in a career and the least later: "I don't know." Senior engineers decorate it with a plan, which converts it from a confession into a commitment:

• "I don't know. I'll find out and post the answer here by tomorrow."
• "I don't know the numbers offhand; rather than guess, let me check."
• "That's outside what I've worked with; Ravi is the right person."

The anti-pattern is bluffing. In technical work, bluffs are eventually audited by reality, and one exposed bluff costs more trust than a hundred honest "I don't know"s. Related, when you only half-understood something, say which half: "I follow the write path; I lost you at the compaction step. Can you go over that part again?"

👉 With the everyday moves in hand (open well, thank well, ask well), we get to the discussions where engineering reputations are actually made. First: you have a design in your head and you want the team to adopt it. How do you propose it so that it gets engaged with rather than ignored, and how do you invite criticism on purpose? On to Chapter 4.

Proposing a design

"I want to propose a new design" is a fine sentence, and it is also the least important part of a proposal. Proposals live or die on framing: whether the reader can tell what problem you are solving, what you considered, what you recommend, and what you want from them. This chapter gives you the language for each stage, from the first trial balloon in chat to a design review with principals in the room.

Before proposing: socialize the idea

Dropping a finished 12-page design doc on a team that has never heard the idea is a known failure mode; people react to surprise with resistance, and public review becomes the first place objections appear. Senior engineers socialize first: they float the idea informally with the two or three people most affected, before writing anything long.

• "I've been thinking about the retry storm problem. Rough idea: move the queue to per-tenant shards. Can I get twenty minutes to sanity-check it with you before I write anything up?"
• "Early thought, not a proposal yet: what if the cache moved client-side? What would break first?"
• "You know this system best. If I proposed splitting the worker into two pools, what would your first objection be?"

That last phrasing is deliberately excellent: it asks for the objection as a favor, which gets you the strongest counterargument while the design is still cheap to change, and it recruits the objector as a co-author of the fix. Ideas that survive socialization arrive at review pre-supported.

The shape of a written proposal

Whether it is three paragraphs in a ticket or a formal RFC ("request for comments", the standard name for a design doc circulated for feedback), the skeleton is stable:

1. Context      What exists today, in two or three sentences.
2. Problem      What hurts, with numbers if you have them.
3. Goals        What a solution must achieve.
   Non-goals    What this proposal deliberately does not attempt.
4. Options      2-3 candidates, each with honest tradeoffs.
5. Recommendation   Which option and why, stated plainly.
6. Risks & open questions   What could go wrong; what you don't know yet.
7. The ask      What you need: approval, feedback on a section, a decision.

The two sections that mark a mature proposal:

Non-goals. Explicitly listing what you are not solving ("multi-region failover is out of scope; this only addresses single-region resilience") prevents the review from sprawling and shows you scoped deliberately. The phrase "out of scope" is neutral and standard; use it without apology.

Honest options. A proposal with one option is a demand; a proposal whose rejected options are strawmen is a manipulation, and reviewers smell both. Present the strongest version of each alternative, then say why you still prefer yours. "Option B is genuinely attractive if we expect 10x growth; I recommend A because we have no evidence of that growth and A is reversible."

Don't be confused: a strawman has two meanings in this world. In argumentation it is a fallacy: misrepresenting a position to knock it down. But in design discussions, "here's a strawman" means "here's a deliberately rough first draft, please attack it": offering your own idea as the thing to knock down. "Let me put up a strawman so we have something concrete to argue about" is an invitation, and a good one. The counterpart is the steelman: the strongest possible version of a position, usually someone else's ("let me steelman the monolith option before I argue against it").

Phrases for making the proposal

Calibrate the strength of your language to the strength of your conviction:

Say the recommendation in one plain sentence and put it early: "I recommend option A: per-tenant queues with a shared overflow pool." Burying the recommendation on page six, or hedging it into fog ("perhaps something like A could potentially be explored"), forces every reader to reverse-engineer your opinion. Calibrated confidence also means marking the uncertain parts out loud: "I'm confident about the queue split; I'm much less sure about the overflow sizing, and I'd especially like eyes on that."

Inviting criticism on purpose

A proposal that asks "any feedback?" gets either silence or randomness. Direct the fire:

• "Please poke holes in the failure-mode section; that's where I'm least sure."
• "What am I missing?" (short, disarming, effective)
• "Where does this break first?"
• "I'd especially like pushback on the decision to keep writes synchronous."
• Scope the open surface: "The API shape is settled with the client team, so that part is FYI; the storage choice is genuinely open."

Telling reviewers which decisions are open versus closed is a kindness in both directions: nobody wastes effort relitigating settled ground, and the open questions actually get attention.

Presenting a design live

The written doc and the meeting have different jobs: the doc carries detail; the meeting exists to surface disagreement and make a decision. Openings that work:

• "Everyone's seen the doc? Quick show of hands... OK, I'll skip the recap and go straight to the open questions."
• If they have not read it: "Let me give the two-minute version, then let's spend the time on the two open decisions." Then actually take two minutes.

The two-minute version is BLUF: bottom line up front. State problem, recommendation, and the decision you need; detail only on demand. Answering questions during a live review:

• Concede specifics gracefully: "Good catch; the doc is wrong there, I'll fix it."
• Defer rabbit holes: "That's real, and it deserves more than a drive-by answer. Can I take it offline and post the analysis in the thread?" ("Take it offline" means discuss outside this meeting; it is standard, not evasive, provided you actually follow up.)
• Absorb hostility without matching it: "Strong reaction, let me make sure I get the substance. Your concern is the migration cost, right?"

Driving to a decision

Proposals die of silence more often than rejection. The closing moves:

• Name the decision-maker if there is one: "Dana, this is ultimately your call; what do you need from us to make it?"
• Lazy consensus for reversible decisions: "If there are no objections by Friday, I'll take that as agreement and start on Monday." State it in the doc and the channel, give a real deadline, and honor objections that arrive late anyway if they are serious.
• Record the outcome where the next person will look: "Decision: option A, agreed in design review 2026-07-14. Rationale and rejected alternatives in the doc." Many teams formalize this as an ADR ("architecture decision record"). Six months later, the recorded why is worth more than the decision itself.

And when your proposal loses: lose gracefully and visibly. "I still lean A, but B carries the room and it's a reasonable call. I'm on board; let's document why we chose it." That sentence, said sincerely, buys you more long-term influence than winning the argument would have. It has a name, disagree and commit, and it appears again in the next chapter.

👉 Proposing your own design is the easy half; the hard half is what to say about a design you think is wrong. "I want to criticize this design, it's abhorrent" contains a real professional need (the criticism) wrapped in career damage (the adjective). The next chapter is about extracting the one from the other: the mechanics of disagreeing hard while keeping the person on your side. On to Chapter 5.

Disagreeing without damage

Take the raw thought this chapter exists for: "I want to criticize this design, it's abhorrent." The feeling is legitimate; engineers who never feel it are not paying attention. But said that way, it accomplishes the opposite of its goal. The author hears an attack, defends rather than thinks, allies rally to them, and the design you hated ships anyway, now with your name on the list of people it is satisfying to ignore.

The professional skill is not suppressing the criticism. It is delivering 100% of the substance with 0% of the insult.

Why "abhorrent" fails on its own terms

Set aside politeness. "This design is abhorrent" fails as engineering communication because it carries zero actionable information. Abhorrent how? Compared to what? Costing what? An adjective is a verdict without evidence, and verdicts invite counter-verdicts ("no it isn't") rather than analysis. Compare:

Verdict only:
  This design is terrible.

Substance:
  This design puts a synchronous cross-region call on the checkout hot
  path. At our p99 inter-region latency (140ms), that alone blows the
  300ms budget, before we add the actual work.

The second version is more devastating, not less. Nobody can argue with it by being offended; they have to engage with the latency number. This is the core rule from the introduction in action: soften the person, sharpen the substance. Strong criticism should get more specific, never more colorful.

The disagreement ladder

Not every objection deserves the same force. Calibrate, and spend the strong rungs rarely so they keep their value:

Two notes on the ladder. First, the question rung (2) is the workhorse: phrased genuinely, it lets the author find the flaw themselves, which is both kinder and more persuasive than announcing it. "What happens to in-flight requests during the swap?" beats "you forgot in-flight requests." Second, rung 6 must always include the exit condition ("what would change my mind"), because an objection with no exit condition is not an argument; it is a veto, and teams route around vetoes.

The shape of a strong objection

When you go to rungs 4 through 6, structure the message like this:

1. Steelman first. Prove you understood the design before attacking it: "If I follow, the goal is to keep writes strictly ordered, and the single queue is what buys that. Is that a fair summary?" Criticism after an accurate summary lands as analysis; criticism before it lands as reflex.
2. Name your concern, with its severity: "My concern is availability: that queue is now a single point of failure for all tenants."
3. Give the evidence: numbers, a failure scenario, a prior incident. "We had exactly this topology in the export service; incident 2024-091 was the result."
4. Offer a path, or explicitly say you have none: "One alternative: per-tenant queues with a sequencing shim. If that fails, I'd rather take the ordering risk than the availability risk." Even "I don't have a better idea yet, which I admit weakens my position" keeps you honest and the conversation open.

Softening phrases that do honest work at the front of an objection:

• "I may be missing context here, but..."
• "Help me understand the reasoning on..."
• "Playing devil's advocate for a moment:" (flags that you are testing the design, not opposing it; don't overuse it or you become the person who is always "just" playing devil's advocate)
• "This is a genuine question, not a rhetorical one:"

Don't be confused: softeners are legitimate when they state a true uncertainty ("I may be missing context" when you actually might be) and corrosive when they fake one. If you have full context and are certain, say so plainly: "I have context on this system and I think this is wrong; here's why." Overhedged certainty confuses readers about how strongly you actually object, and the disagreement ladder collapses when every rung sounds the same.

Person, place, and time

Three rules that outweigh any phrasing:

• Critique the artifact, never the author. "This design has an availability gap" not "you ignored availability." Grammar helps: make the design the subject of your sentences, not the person. Watch for the accusatory "you" and swap in the work: "the doc doesn't cover X" rather than "you didn't cover X."
• Big criticism goes private first. Public correction has a punishment flavor even when accurate. For a serious flaw in a peer's public proposal, a direct message first ("Before I comment in the thread: I think there's a significant problem with the failover story. Want to talk it through?") gives them the chance to fix it as their own revision. You lose the credit for the catch; you gain an ally instead of an adversary. Exception: when the flawed decision is about to be made in the meeting you are in, object in the room, politely and immediately.
• Criticize before the decision, support after it. The window for objections is before commitment; that is what reviews are for. Relitigating decided questions ("I still think we should have used Postgres", months later, at every incident) is one of the fastest credibility drains in engineering. If new evidence genuinely emerges, reopen the decision explicitly and formally, once: "The write volume came in 8x over the estimate that drove the DynamoDB choice. I think that invalidates the decision and I'd like to revisit it."

Disagree and commit

The phrase, popularized by Amazon's leadership principles and common across the industry: once a decision is made, you support it fully even if you argued against it, because a team that executes a decent plan wholeheartedly beats a team that executes a great plan while half of it sulks.

Saying it well:

• "I've made my case and the room disagrees. Disagreeing and committing: I'm in, and I'll take the migration workstream."
• "For the record I still lean A, but B is defensible and the decision is made. Let's document the reasoning and go."

The commitment must be real. The failure mode with its own smell is malicious compliance: committing verbally while quietly working to make the decision fail so you can say "told you so." One "told you so" costs more trust than ten lost arguments. If you truly cannot commit (rare; ethics, safety, or a conviction the decision is catastrophic), that is not a phrasing problem; escalate it honestly instead, per Chapter 10.

Receiving criticism

The other side of the table, briefly, because how you receive critique sets the price others pay to give it to you:

• Reach for curiosity before defense: "Say more?" / "What would you do instead?" / "Which part worries you most?"
• Concede fast and specifically when they are right: "You're right, the in-flight case is broken. Good catch; I'll rework it." A fast, cheerful concession is a seniority signal, not a defeat.
• When they are wrong, correct the substance without scoring points: "That case is actually handled; the shim serializes those. I clearly need to make that visible in the doc."
• When it stings, buy time honestly: "Strong point, I want to think about it rather than defend on reflex. I'll reply in the thread tomorrow."

A culture-note for readers from very direct or very indirect cultures: the calibration in this chapter is for default international-English workplaces. Some teams (and some countries) run notably blunter ("this breaks under load, fix it") and some notably softer; watch how respected senior people on your team disagree with each other, and tune toward that. Erin Meyer's The Culture Map (in References) is the standard field guide to these differences.

👉 The densest arena for everyday disagreement is code review, which has evolved its own compressed dialect for exactly this reason: "nit:", "blocking:", "LGTM with nits" are disagreement-calibration machinery. On to Chapter 6.

Code review language

Code review is where engineers criticize each other's work daily, in writing, in public, forever. Unsurprisingly, it grew a specialized dialect whose whole purpose is calibration: making it cheap to say "this is fine, one tiny thing" and unmistakable to say "this must not merge." Learn the dialect and reviews get faster and friendlier; ignore it and every comment carries unintended weight.

Severity labels: nit, blocking, optional

The core convention is prefixing comments with a severity label:

Some teams adopt this formally (the "Conventional Comments" standard adds labels like thought: and chore:); most use it informally. The value is the same: the author can triage twenty comments instantly, and reviewers can be picky about small things without those small things reading as demands. Unlabeled comments default to an ambiguous middle weight, which is exactly where misunderstandings breed. When in doubt, label.

Praise deserves its own sentence: reviews that only ever surface problems train authors to dread them. "praise: this test table is really readable" is one line and changes the whole temperature of a review.

Phrasing comments: requests, not commands

The mechanical rules that keep review comments from sounding like orders:

• Prefer questions and suggestions to imperatives. "What do you think about extracting this into a helper?" or "Consider extracting this" rather than "Extract this." The question form also leaves room for the author to know something you do not, which is often the case.
• Make the code the subject, not the person. "This function also handles retries; could we split the concerns?" rather than "You made this function do two things." The author and the code are different entities; review the code. (This is Chapter 5's artifact rule, applied line by line.)
• Give the why, compressed. "suggestion: use a set here; this list scan is O(n) per event and this path is hot" teaches; "use a set" merely instructs. One clause of rationale is usually enough.
• Anchor claims when you can. "This will NPE when config is absent; see the loader at startup.py:88" is a gift. Vague unease ("something feels off here") is allowed but say it as that: "thought: no concrete objection, but this coupling makes me nervous. Fine to merge if you've considered it."

The approval vocabulary

• LGTM: "looks good to me", the classic approval.
• LGTM with nits: approved; fix the trivia, no re-review needed.
• Approving to unblock; please address the two comments before merging. Trust-based approval, common between senior peers and across time zones.
• PTAL: "please take another look", said by the author after addressing feedback.
• Requesting changes (the formal review state): reserve it for genuine blockers, and say which comments are the blocking ones. A "request changes" over pure nits reads as disproportionate; a wall of 30 comments where none is marked blocking is unreadable.

Don't be confused: LGTM approves the change; +1 merely agrees with a statement or adds support ("+1 to Sam's concern" means "I share that concern", the opposite of approval). ACK means "acknowledged, received", and WIP on a PR title means "work in progress, don't review seriously yet" (many teams use draft PRs for the same signal). None of these are interchangeable, and using LGTM to mean "I skimmed it" devalues the token; only say it when you mean "I reviewed this and would defend merging it."

Responding to review, as the author

The author's half of the dialect matters just as much:

• Answer every comment, even trivially: "Done." / "Fixed in a3f9c21." / "Good catch, fixed." Silently resolving comments makes reviewers re-audit everything; the one-word replies are the receipt.
• Push back openly when you disagree, using the ladder from Chapter 5: "I'd prefer to keep it inline: the helper would have one caller and this function is already short. Happy to extract it if you feel strongly." Then let the severity label govern: if their comment was optional and you declined with a reason, resolve and move on.
• Escalate scope honestly. When a comment reveals a genuinely bigger problem: "You're right and it's structural; fixing it properly touches the whole module. I've filed #482 and would rather land this as-is behind the flag. OK?" Deferring with a tracked ticket is professional; deferring into the void is how debt becomes invisible.
• Thank the reviewer when the review was substantial. One line. See Chapter 2.

Asking for review

The request itself has etiquette:

• Size the ask: "Small one, ~60 lines, mostly mechanical: PTAL when convenient." versus "This is the big migration PR. It needs a careful read; 30 to 45 minutes. Could you book time this week?"
• State urgency honestly and rarely: "This blocks the release cut Thursday" when true; nothing is urgent every week.
• Route review well: one named reviewer beats a broadcast. "@Sam for the storage changes, @Ines for the API surface" beats hoping someone bites.
• If review is slow, bump per Chapter 3: gently, once, then re-route: "Sam's out; Ravi, could you take this one?"

Review disagreements that outgrow the PR

Some review threads stop being about the PR: a ten-comment argument about error-handling philosophy is no longer review, it is design discussion in the wrong venue. The standard move:

This thread is bigger than this PR. I've opened #491 to discuss our
error-handling convention properly; proposing we land this PR following
the existing pattern and apply whatever we decide there across the module.

That sentence structure (name the mismatch of venue, open the right venue, propose a default so nothing stalls) resolves ninety percent of stuck threads. For the other ten percent, get synchronous: "We're going in circles in text; fifteen minutes on a call?" Text escalates tone by accident; voice de-escalates it by default.

👉 Reviews happen when code is ready; standups and status updates happen on a clock, whether anything is ready or not. Next: the language of the sprint, namely how to report progress in standup without rambling, the exact difference between "on track", "at risk", and "blocked", and how to write an async status update people actually read. On to Chapter 7.

Standups and sprint status

Status is the genre engineers produce most and think about least. A standup update takes ninety seconds, happens daily, and is often the only sample of your work most of the team ever sees; it is worth doing deliberately. This chapter covers the spoken standup, the vocabulary of progress states, sprint review language, and the written async status update.

The standup update

The classic format is three parts: what happened, what is next, what is in the way. The skill is compression around outcomes:

Rambling (activity-based):
  So yesterday I was looking into the migration thing, there were some
  weird issues with the connection pool, I spent a lot of time reading the
  driver code, it's pretty complicated, anyway I'm still on that, and I
  also had some meetings...

Crisp (outcome-based):
  Yesterday: found the migration stall; it's connection pool exhaustion,
  fix is a one-liner, PR is up. Today: land it, then start the backfill.
  Blocked on: review from Sam on #4132.

The rules behind the crisp version:

• Report outcomes, not effort. "Finished X", "found Y", "decided Z", not "worked on", "looked into", "spent time on". If a day produced no outcome, say what you learned or what you ruled out: "Ruled out the driver; the stall is on our side." That is an outcome.
• Name blockers with a name attached. "Blocked on review from Sam" is actionable; "waiting on some reviews" evaporates. The standup is exactly the place where naming is not nagging; that is what the ritual is for.
• Take detail offline. "The pool fix has a subtle part; Ravi, I'll grab you after standup" keeps eight people from waiting through a two-person conversation. ("I'll grab you" is friendly-casual for "I'll come talk to you"; in more formal settings, "let's sync after this.")
• Sixty to ninety seconds. If you regularly need more, the update wants to be written, not spoken.

The status vocabulary

Progress states have precise conventional meanings; using them precisely is most of what "communicating status well" means:

Many orgs compress this to RAG status (red/amber/green). The professional rule about all these labels: status must move when reality moves, early. An "at risk" flagged two weeks out is a plan; the same news the night before the deadline is an incident. Chronic green-until-suddenly-red reporting is how engineers lose the trust of everyone who plans around them. The wording for the early flag is low-drama: "Flagging early: the backfill is running 4x slower than tested. Still possible we make Friday, but I'd call it at risk. I'll know by Wednesday."

Don't be confused: "at risk" and "blocked" are different claims. At risk means moving, with danger ("we may miss the date"); blocked means stopped ("no progress is possible until X"). Calling yourself blocked while you could be working the next task down invites unnecessary rescue; failing to say "blocked" when you are wastes days silently. Also: "slipping" describes the schedule, not the person. "The date is slipping" is a status; "I'm slipping" is a confession nobody asked for.

Estimates and forecasts

Status conversations constantly ask for dates, and the language of estimates is where credibility compounds or erodes:

• Give a number with its uncertainty: "My estimate is three days, and the risky part is the vendor API; if their sandbox behaves, three is real." An estimate with a named risk is information; a bare "soon" is noise, and a confident wrong date is worse than either.
• Distinguish estimate from commitment. "I estimate Thursday" is a forecast; "I'll have it Thursday" is a promise. Seniors are careful about which one they are uttering, and say so when pressed: "I can commit to Friday. Thursday is possible but I won't commit to it."
• Re-estimate out loud when inputs change: "The schema turned out to have two more consumers than I thought; Thursday becomes Monday. The extra work is regression-testing those consumers." Date, reason, next checkpoint. Nobody reasonable punishes that sentence; everybody punishes discovering it themselves on Thursday.

Sprint review and demo language

Sprint review (or sprint demo) is a narrative, and the strong shape is: goal, result, gap, demo.

This sprint the goal was to get tenant isolation into staging. We shipped
the per-tenant queues and the quota enforcement; both are in staging now,
and I'll demo the throttling in a second. The audit log piece slipped;
it collided with the incident on Tuesday, and it's first up next sprint.
Demo: here's what happens when one tenant floods the queue...

Notes: the slipped item is stated plainly with its cause and its new home, neither buried nor apologized to death. One "unfortunately" is plenty. For demos, narrate the user-visible behavior first and the implementation only if asked; the audience for reviews is usually wider than the team.

Retro language: blameless by construction

Retrospectives run on a linguistic trick that is also a genuine philosophy: causes are systems, not people. Compare:

• "The deploy broke because Alex skipped the canary step." (blame)
• "The deploy broke because the canary step is optional and skippable under deadline pressure. How do we make it not skippable?" (blameless)

Both sentences are factually compatible; the second produces a fix and a retro people will speak honestly in. Useful retro stems: "What made that the easy path?", "What would have caught this earlier?", "What should we stop doing / keep doing?", and for your own misses, plain first-person ownership: "I merged it without the flag; the process let me, but I also just rushed. Both are worth fixing." Owning your part cleanly, without theatrical self-flagellation, is a seniority marker; see also the incident language in Chapter 10.

The written async status update

Distributed teams increasingly replace or supplement live standup with written updates in a channel or ticket. The strong template:

Status: At risk (was: On track)
TL;DR: Backfill is 4x slower than tested; Friday is now 50/50.

Done since last update:
- Migration script merged and deployed to staging (#4132)
- First 20% of backfill complete, zero data diffs

Next:
- Parallelize the backfill workers (today)
- Go/no-go call on Friday date: Wednesday EOD

Risks / needs:
- Need a decision from @Dana on whether we can raise the DB IOPS cap
  for 48h; that alone would retire the schedule risk.

Why this shape works: the status word and TL;DR ("too long; didn't read": the one-line summary, always at the top) serve skimmers; the "was:" marker makes changes visible; bullets are outcomes; and the needs section converts the update from a diary into an instrument. Write it so that a director who reads only the first two lines still gets the truth.

👉 Standups are the easy ceremony: short, scripted, yours. Meetings are the contested one: interruptions, tangents, quiet people with the best point in the room, and decisions that evaporate the moment the call ends. Next: the language for running and surviving meetings. On to Chapter 8.

Meetings: speaking up, pushing back, closing

Meetings are live, unscripted, and social, which makes them the hardest channel for non-native speakers and introverts alike. The compensating good news: meeting English is highly formulaic. A few dozen stock moves cover interrupting, yielding, redirecting, clarifying, and closing, and using them smoothly is largely what "good in meetings" means.

Getting into the conversation

Interrupting politely is a legitimate skill, not a rudeness. The standard entries, from softest to firmest:

• "Can I add something here?"
• "Quick point on that:"
• "Sorry to jump in, but this affects the decision:"
• "Before we move on, one thing:"
• "I want to flag something before we lock this in."

On video calls, use the raise-hand feature or type "quick point when there's a gap" in the meeting chat; both are fully professional. If you get talked over (it happens, accidentally and otherwise): finish anyway, calmly: "Let me just finish the thought: ..." Once is assertive; done evenly, it reads as composure, not conflict. And the mirror-image skill, for when you notice you interrupted: "Sorry, you were first; go ahead."

Two moves worth deliberate practice because they build others up while getting you the floor:

• The return: "Going back to what Ana said a minute ago, I don't think we actually answered it." (Rescues lost points; the rescued person remembers.)
• The invitation: "Yuki, you ran the last migration; what's your read?" (Brings in the quiet expert. Facilitators love people who do this unprompted.)

Clarifying and playing back

Asking for clarification in a meeting feels costly ("everyone else seems to follow") and almost never is; half the room usually shares your confusion. The stock phrases:

• "When you say cache, do you mean the CDN or the application cache?"
• "Can you say that another way? I want to make sure I'm following."
• "Could we make that concrete? What would that mean for, say, the checkout flow?"

The power tool is the playback (also called mirroring): restating what you heard before responding to it. "Let me play that back: you're saying the migration is safe as long as writes are frozen, and the freeze needs two hours. Did I get that right?" Playbacks catch misunderstandings while they are still cheap, visibly honor the speaker, and buy you ten seconds to think. Negotiators, facilitators, and principal engineers all lean on this one constantly.

Don't be confused: "I don't follow" and "I don't agree" are different statements, and mixing them muddies meetings. "I don't follow the jump from X to Y" asks for the reasoning; "I follow the reasoning, and I disagree with the premise" is an objection (Chapter 5 applies). Saying "I don't understand" when you mean "I think that's wrong" is false modesty that confuses everyone; the reverse ("I disagree" when you actually just missed a step) starts fights about nothing.

Keeping a meeting on the rails

You do not have to be the organizer to steer; in fact, gentle steering from participants is a seniority signal. The moves:

• The parking lot: "That's a real issue and I don't want to lose it, but it's not today's decision. Can we park it and I'll make sure it gets a thread?" (The parking lot is the list of deferred topics; the credibility rule is that parked items must actually get followed up.)
• The scope check: "We're solving next year's problem; can we come back to the Q3 question?"
• The timebox: "We have ten minutes left and two decisions to make; can we spend five on each?"
• The rathole call: "We're three levels deep on a detail; I suggest we take it offline and get back to the main thread." ("Rathole" is the affectionate term for an unplanned deep tangent.)
• The decision forcing move: "I'm hearing broad agreement on A with concerns about the timeline. Can we decide A-in-principle and assign the timeline question to someone?"

Disagreeing live

Everything from Chapter 5 applies, compressed by real time. The live-specific additions:

• Acknowledge before countering: "I see the appeal, especially the cost side. Where I get stuck is the failure story: ..." The acknowledgment is not a concession; it is proof you listened, which is what earns you the room's attention for the counter.
• Disagree with the last speaker without making it personal: address the idea's content, not "what Marcus just said": "The shared-queue approach worries me because..." rather than "Marcus is wrong because..."
• When outnumbered and time is short, register and move: "I'm the minority view here; I want it noted that I think the retry budget is too low, and I'm fine proceeding if we add an alert on it." Registered dissent plus a concrete mitigation is the graceful minority position.
• When it gets heated: slow down, drop volume, get concrete. "Let's take the temperature down a notch; I think we actually agree on the goal. The disagreement is only about sequencing, right?" Naming the shared ground shrinks the fight to its real size.

Presenting to executives and skip-levels

A special register, because senior leaders optimize ruthlessly for time:

• Answer first. Executives ask "can we ship in March?"; the answer begins "Yes, if X" or "No, because Y", not with background. If they want the journey, they will ask. (This inverts the engineer's instinct to build up context before conclusions; fighting that instinct is the single highest-value habit in this section, and Chapter 16 drills it as a general structure.)
• Know your one number. Whatever the meeting is about, have its central quantity loaded: the cost, the latency, the date, the headcount. "I'll get back to you" on the central number of your own topic is a bad look; on peripheral numbers it is fine and honest.
• Flag uncertainty in ranges, not winces: "Between six and ten weeks; I'll have it to plus or minus a week after the spike" beats "umm, hard to say, it depends."

Closing: decisions, owners, dates

Meetings without written outcomes did not happen. The closing ritual, which anyone in the room can perform:

Before we drop: capturing what we decided.
1. We're going with per-tenant queues (option A). Dana signs off by Fri.
2. Ravi owns the sizing spike, results next Wednesday.
3. Parked: the multi-region question; I'll open a thread today.
Did I miss or mangle anything?

Then post exactly that to the channel or doc. The formula is decision, owner, date for every outcome; anything lacking one of the three is not yet an outcome. The person who reliably does this becomes, in the eyes of everyone senior, the person who makes meetings worth having.

Also part of closing well: declining meetings you should not be in ("I don't think I add much here; I'll read the notes, and ping me if the storage question comes up") and leaving ones that no longer need you ("I need to drop for another commitment; my input is in the doc, and I'm good with either option on the open question"). Both, said plainly, are marks of someone who treats time as shared property.

👉 Everything in this chapter assumed someone else was running the session. Sooner or later that someone is you: chairing the design review, driving sprint planning, hosting the brown bag, moderating the Q&A. The front-of-the-room phrasebook is next. On to Chapter 9.

Hosting and moderating: planning, tech talks, brown bags

Sooner or later you stop only attending sessions and start running them: a design review you chair, a sprint planning you drive, a tech talk you give, a brown bag you host. Running a session is a distinct skill from participating in one, with its own phrases, and it is disproportionately visible; the person at the front of the room is being evaluated by everyone in it. The good news, as with meetings: it is formulaic, and the formulas are below.

Don't be confused: four overlapping roles. The chair owns a formal meeting's agenda and decisions. A facilitator owns the process (time, turn-taking, parking lot) but deliberately not the content, and may have no stake in the outcome. A moderator runs a Q&A, panel, or discussion between other speakers. A host (or MC) opens and closes an event and introduces others. In practice one person often plays all four; the useful distinction is content versus process: the more you personally argue for an outcome, the less you can simultaneously play referee, and for contentious design reviews it is standard to split the roles ("I wrote the doc, so Priya will facilitate").

The facilitator's contract

Whatever the session, the person running it owes the room five things, each with its stock phrases:

1. Start and end on time. "It's two past; let's start. We'll protect the last five minutes for decisions."
2. A stated goal. "By the end of this hour we need a decision on the storage engine; everything else is input to that."
3. One conversation at a time. "Hang on, we've got two threads going; let's finish the quota question first."
4. Tangents parked, not killed. "Good topic, wrong meeting; parking it." (And then actually following up, per Chapter 8.)
5. Outcomes landed. The decision/owner/date close, every time.

Chairing a design review

The design review is the highest-stakes session most engineers ever run, because it mixes technical judgment with ego in a shared room. The chair's job is to keep the discussion about the design, in both directions: not letting critique become personal, and not letting politeness bury real objections.

Opening frame, worth saying almost verbatim:

Goal: a decision on the queue design by :50. The doc's been out since
Monday; I'll assume it's been read. Ground rules: concerns before
preferences, concrete over vibes, and comments on the design, not the
author. Ana, you flagged the biggest concern in the doc; start us off?

Moves specific to the chair role:

• Order the fire. Blocking concerns first, preferences later: "Let's hear anything that would stop this design entirely before we discuss flavor." This prevents an hour of bikeshedding followed by a fatal objection at :55.
• Translate heat into substance. When a comment arrives as a verdict ("this will never scale"), the chair converts it: "Let's make that concrete: at what load, and which component goes first?" You are doing Chapter 5's work on behalf of the room.
• Protect the author. "Hold on, three people are talking at the author. One at a time, and let them answer." An author who feels ganged up on stops absorbing feedback entirely.
• Name the silence. "The storage folks haven't said anything, and this lands on you; genuinely fine with it, or being polite?"
• Close honestly. Decision, or explicitly not: "We're not deciding today; the open item is the failover cost, Ravi owns the analysis, we reconvene Thursday." A non-decision stated crisply beats a fake consensus.

If you are both author and chair (common on small teams), say the quiet part: "I'm biased here, so push hard; someone volunteer to keep me honest on time and tangents."

Running sprint planning and refinement

Planning sessions have their own working vocabulary. Refinement (the older name "backlog grooming" is being phased out in many orgs; you will hear both) is where stories get clarified and sized before planning; planning is where the team commits to a sprint's worth. Phrases that do the work:

• Clarifying scope: "What does done mean for this story? Merged, deployed, or verified in prod?" (the definition-of-done question), "Is the spike included or is this build-only?" (a spike is a timeboxed investigation whose output is knowledge, not code).
• Sizing: "I'd call it a 3; the unknown is the vendor API." / "This feels like two stories wearing a coat; can we split the migration from the UI?" / "Last time something looked this easy it took a sprint; what are we not seeing?"
• Capacity honesty: "We're planning 80% capacity; Dana's on call and we have the audit deadline." / "That's a stretch goal, not a commitment; let's mark it as such." The commitment/stretch distinction is Chapter 7's estimate-versus-promise rule applied to the whole team.
• Pushing back on scope pressure, as the facilitator: "We can add it, but the sprint is full, so name what comes out." (The costed yes from Chapter 10, used preemptively.)

Hosting a tech talk or brown bag

A brown bag is an informal talk over lunch (named for the packed-lunch bag), lighter than a formal tech talk; a lightning talk is a five-to-ten minute version. Hosting any of them is a sandwich: intro, timekeeping, Q&A, thanks.

• The intro: one line of who, one of what, one of why-you-care: "This is Priya, who's been running our search infrastructure for three years. She's going to walk us through the reindexing incident and what it taught us about our schema. If you've ever been paged by search, this one's for you." Then get out of the way.
• Housekeeping: "Forty minutes of talk, ten of questions. Drop questions in the thread as you go, or save them; we'll take them at the end."
• Timekeeping: agree on signals beforehand; live, it sounds like "five-minute warning, Priya" or a chat message. Protecting the Q&A slot is the host's job, not the speaker's.
• The thanks: specific beats generic, as always (Chapter 2): "Let's thank Priya; the aliasing trick alone was worth the hour."

Moderating the Q&A is where hosts earn their keep:

• Seeding: have one question ready for the dead air after "any questions?" "I'll start while people think: what would you do differently today?"
• The comment-disguised-as-question: let it run a beat, then: "And is there a question in there for Priya?" (said lightly, it gets a laugh and works); or convert it: "So the question is whether this generalizes beyond search; Priya?"
• The rambler: "In the interest of time, let me compress that to: why not Elasticsearch? Priya?" Compressing someone's question is a service, not an insult, when done accurately.
• The hostile question: absorb and normalize: "Fair challenge; Priya, take it wherever you want." The moderator's calm is contagious in both directions.
• Closing: "Time for one more... and done. Thread stays open for the rest; recording goes up this afternoon."

Giving the talk yourself

The speaker's side, compressed to the phrases that matter:

• Signpost relentlessly. "Three parts: the problem, what we tried, what I'd do differently. Part one." Spoken audiences cannot scroll back; structure said out loud is the only table of contents they get. Between parts: "That's the problem; here's what we tried."
• Open with the audience's stake, not your agenda: "Show of hands: who has been paged by the search cluster?... Right. This talk is about why that keeps happening."
• The unknown answer: "I don't know offhand, and I'd rather not guess at the front of a room. Catch me after, or I'll post the answer in the thread." (Chapter 3's "I don't know" plus a delivery plan, performed publicly.)
• The demo failure: have the script ready because you will need it: "The demo gods have spoken; here's the screenshot version, and I'll post the recording of it working." Zero apologizing beyond one joke; the audience forgets a failed demo in minutes and remembers flustered recovery for years.
• Running long: cut content, never the ending: "I'm going to skip the benchmarking section (slides have it) and jump to the takeaways."

Panels and AMAs

Two formats worth a paragraph each. Moderating a panel: your job is distribution and friction. "Sam, thirty seconds on the same question" keeps answers moving; "You two seem to disagree; say more about that" is the moderator's best sentence, because polite panelists will otherwise sand off every interesting difference. An AMA ("ask me anything") runs on the moderator batching and sequencing questions: "Bundling three related ones: what's the roadmap for X, and does it survive the reorg?" Protect the guest from pile-ons the same way a chair protects a design author.

👉 Hosting is ceremony at its most pleasant: you control the agenda and the clock. The last ceremony chapter is the opposite: the messages that arrive off-schedule and unwelcome. Slipped deadlines, production incidents, blocked dependencies, and your own mistakes, delivered early and well. On to Chapter 10.

Escalations, incidents, and bad news

Everything before this chapter was fair-weather English. This one is for the messages nobody wants to send: the slipped date, the broken production system, the blocked dependency, the mistake that was yours. It is also the chapter where wording has the highest stakes, because bad news handled well builds more trust than good news ever does, and bad news handled late or vaguely destroys it fastest.

The prime directive: early, factual, forward

All bad-news genres share three rules:

1. Early. Bad news ages worse than any other message type. The moment you know the date will slip is the moment its value as information peaks; every day you sit on it converts information into betrayal. The standard opener exists precisely to lower the cost of speaking early: "Flagging early, while it's still cheap to react: ..."
2. Factual. What happened, what is affected, what is not affected, what you know versus suspect. Adjectives and adrenaline ("total disaster", "everything is broken") make readers manage your emotions instead of the problem.
3. Forward. Every bad-news message ends with what happens next: the action in flight, the decision needed, or the time of the next update. Bad news with a next step is a briefing; without one, it is an alarm.

The missed deadline

The template, in one breath: new date, cause, options, next checkpoint.

The migration will land Tuesday, not Friday. Cause: the backfill runs 4x
slower against production data than it did in staging (indexes, mostly;
detail in the thread). Options: (A) take Tuesday; (B) hold Friday by
skipping the audit-log table and backfilling it next week; both are safe.
I lean A. I'll confirm the choice at Wednesday standup.

What this template refuses to do is as important as what it does. No blame ("the staging environment lied to me"), no groveling (one "sorry about the late notice" is acceptable if notice is genuinely late; five apologies make the reader comfort you), no fog ("might be some delays"). And it arrives the day the 4x number appeared, not the night before the deadline: this is the "at risk" flag from Chapter 7 maturing into its follow-up, which is exactly how planned communication should work.

Escalating a blocker

Escalation has an undeserved bad reputation as aggression. Done properly, it is routing: moving a decision to the person who can actually make it. Two rules keep it clean:

• Escalate the risk, not the person. "The review dependency on team X is now my critical path; I need help re-prioritizing across teams" rather than "team X is slow." The first is a resourcing fact; the second is an accusation that will reach team X within the hour, with your name on it.
• No surprise escalations. Tell the person first: "I'm still blocked on the schema approval and it's now costing us the sprint goal; I'm going to raise it with Dana today so it gets prioritized properly. Wanted you to hear that from me." That sentence keeps the relationship; the identical escalation discovered secondhand ends it. In most cases, the warning alone unblocks you and no escalation happens.

The escalation message itself is a decision request, not a complaint:

Dana: I need a prioritization call. The tenant work is blocked eight days
on schema review from platform (thread linked). Their queue is legitimately
full; this isn't a performance complaint. Options as I see them: (A) they
bump us, at cost to their sprint; (B) we ship behind a flag without the
schema change and take a week of migration debt; (C) the date moves.
I can execute any of them; A is cheapest globally. Your call.

Incident communication

During a production incident, communication follows a special regime: regular, structured, and boring on purpose.

• Cadence over completeness. "Next update at 14:30" and then updating at 14:30 even if nothing changed ("no change; still testing the rollback in staging; next update 15:00") is the core discipline. Silence during an incident reads as chaos, whatever the reality.
• Structure every update the same way: impact, current status, action in flight, next update time. "Checkout errors ~8% of requests since 13:02. Cause isolated to the 13:00 deploy; rollback in progress, ETA 15 min. Next update 13:45."
• Precise state words. Investigating (cause unknown), identified (cause known, fix not applied), mitigated (bleeding stopped, cause still live, e.g. rolled back but not fixed), resolved (fixed and verified), monitoring (resolved, watching for recurrence). Declaring "resolved" while merely mitigated is the classic error; the second customer-visible dip after a premature all-clear costs double.

Don't be confused: in incident reviews, root cause and trigger are different things, and the phrase "root cause" itself is increasingly treated with care ("contributing factors" is the modern hedge, since real incidents are rarely monocausal). The deploy that set things off is the trigger; the reason the system was one deploy away from an outage is the interesting cause. Senior incident writeups spend a sentence on the trigger and pages on the conditions.

Owning a mistake

The highest-trust genre in engineering, and mechanically simple:

I broke checkout. My 13:00 deploy included the config change without the
corresponding schema flag; the canary would have caught it but I forced
past the canary to make the release window. Rolling back now, ETA 10 min.
I'll write up prevention items once we're stable; the obvious one is
making the canary non-skippable.

The components: plain first-person statement of the mistake, mechanism without excuses (note "I forced past the canary" is stated as fact, not flogged), fix in flight, prevention to follow. Two failure modes flank the good version. Under-owning ("the deploy had issues", passive voice doing getaway-driver work) is transparent and corrosive. Over-owning ("I'm so sorry, I'm an idiot, I feel terrible") makes colleagues spend the incident consoling you. The professional tone is calm, specific ownership; teams follow people who report their own mistakes the way they would report anyone's.

A closing word on the blameless frame from Chapter 7: blameless culture is what the organization owes individuals; plain first-person ownership is what individuals offer anyway. The pairing is not a contradiction; each side being generous is what makes the whole thing work.

Saying no, and delivering unwelcome answers

Not all bad news is failure; some is just an answer the asker did not want.

• No, with the price of yes: "We can add SSO this quarter; it displaces the audit work, which is committed to the compliance deadline. If SSO wins, someone above me needs to own moving that deadline." A naked "no" ends conversations; a costed "yes, if" moves them to the right owner. ("What would it displace?" is likewise the polite counter to someone else's mid-sprint request.)
• Scope guardrails: "That's out of scope for this milestone; I've added it to the backlog with a note" is complete and professional. You do not need to perform regret about it.
• The uncomfortable technical answer: delivered like any other fact, with its evidence: "The honest answer is that the prototype doesn't survive production load; it degrades at about 400 rps and the fix is architectural. I'd rather tell you now than after we've staffed the polish work."

👉 That closes the situational half of the book. What remains is vocabulary, and it starts where this chapter left off: incidents and reviews both run on description. How do you report a latency spike, an elevated error rate, a suspected data leak, or a code smell so the words carry numbers and severity instead of mood? On to Chapter 11.

Describing technical situations precisely

"The API is slow." "Errors are through the roof." "The code is a mess." Every one of these is a mood wearing the costume of a report. Professional technical description has a grammar of its own, and it is the same grammar whether you are describing latency, an error spike, a suspected data leak, or a smelly module: quantity, baseline, trend, scope, confidence. This chapter walks the common situations and gives you the standard wording for each.

The description formula

Every strong technical description answers five questions:

The compressed template: metric, number, versus baseline, since when, in what scope, per what source. "Checkout p99 is 340ms against a 120ms baseline, flat since the 14:00 deploy, eu-west only, per the edge dashboards." One sentence, five answers, zero adjectives. You will not always have all five; the professional move is saying which you are missing: "no baseline handy, but 340ms feels roughly triple normal."

Latency

The vocabulary that marks fluency:

• Percentiles, not averages. p50 (median), p95, p99, and tail latency (the slow end). "Average latency is fine" is a rookie tell, because averages hide the tail where users actually suffer: "p50 is untouched; the regression is all in the p99."
• Standard verbs and adjectives: latency is elevated (politely high), degraded (worse than baseline), spiky (intermittent peaks), regressed (worse since a change), or within budget. A latency budget is the allowance a path gets ("the 300ms checkout budget").
• Locating it: "the latency is in the database hop, not the app tier"; "it's a cold-start effect, first request only"; "round-trip time (RTT) to eu-west accounts for 140ms of it."

Weak:   The service got really slow this afternoon.

Strong: Search p99 went from ~200ms to 1.2s between 14:00 and 14:40,
        p50 unaffected, all regions. Recovered on its own; suspect the
        14:00 reindex, not confirmed.

Errors and availability

• Rates, not vibes. Errors are described as a percentage of requests with a window: "5xx rate is 4.2% over the last 15 minutes, baseline 0.1%." The conventional adjective is elevated ("elevated error rate"); spike means sharp and brief, sustained means ongoing.
• Classify before alarming. 4xx (client-side, often someone else's bug or an abusive caller) versus 5xx (our side); transient (retry fixes it) versus persistent; intermittent (comes and goes) versus reproducible (on demand, the debuggable kind). "It's a reproducible 500 on POST /orders with an empty cart" is halfway to fixed.
• Timeouts are their own species: "failing" and "timing out" are different claims; say which, and at what threshold: "not erroring, timing out at the 5s client limit."
• Availability language: "we burned a third of the monthly error budget in an hour" (the error budget being how much unreliability the SLO allows; see Chapter 12 for the SLA/SLO/SLI family), "the service was hard-down for 11 minutes" (completely unavailable) versus "degraded for two hours."

Throughput, load, and capacity

"It doesn't scale" is a verdict; capacity language makes it a description: requests per second (rps, or QPS), saturation (how close to the limit), headroom (slack remaining), and what you are bound by: "we're CPU-bound at about 900 rps; IO has headroom." Load descriptions carry shape too: steady-state versus burst, organic growth versus a thundering herd (Chapter 13 has the full stress bestiary). "The queue is backing up" plus a number ("depth 40k and climbing, drain rate half of arrival rate") is a complete capacity incident report in one line.

Data problems: leaks, leakage, and loss

Don't be confused: three phrases that sound alike and must never be mixed up. Data leakage is the machine-learning term for training contamination: information from the test set (or from the future) sneaking into training, inflating your metrics ("the model saw the label; classic leakage"). A data leak (or data exposure) is a security/privacy event: data visible to people who should not see it. Exfiltration is a leak with an active thief: an attacker deliberately extracting data. Saying "we have data leakage" in a security meeting, or "the model leaked" in an ML review, will produce ten minutes of cross-talk; pick the right term and, if in doubt, spell it out.

Describing a suspected leak or exposure, the four facts that matter, in order: category (what kind of data: PII, credentials, internal-only), scope (how many records/users), audience (exposed to whom: public internet, all employees, one wrong customer), duration (since when). "Customer email addresses (no passwords, no payment data) were readable by any authenticated user of any tenant, from the March 12 release until today's fix; roughly 40k accounts." Note the explicit negatives ("no passwords"): saying what was not exposed is half the value.

Data loss is yet another axis (the data is gone, not seen): describe it by recoverability: "lost but replayable from the event log" versus "unrecoverable."

Security language

Security wording is the one place in engineering where careless phrasing has legal weight; incident channels get read later by auditors, lawyers, and sometimes regulators. The professional conventions:

• The severity ladder of nouns: a vulnerability (a weakness) is not an exploit (working code that abuses it), which is not a compromise or breach (someone actually got in). "We have a critical vulnerability" and "we have been breached" are different emergencies; using the stronger word loosely causes real damage.
• Suspected versus confirmed, always marked: "we have a confirmed compromise of the CI runner" / "suspected credential stuffing, investigating." Upgrades from suspected to confirmed are announced explicitly.
• The evidence hedge, used honestly: "we have no evidence that customer data was accessed" is the standard formula, and it means exactly what it says: absence of evidence, from the logs we have. If the logs are inadequate, professionals say that too: "no evidence of access, with the caveat that object-level access logging was off."
• Neutral verbs in writing. During an active incident, write plainly and without speculation about actors or blame ("attacker" not "the hackers", "unauthorized access" not "we got owned"): facts now, color never. The channel is the record.

Code quality: smells and how to report them

A code smell is a surface symptom that suggests (not proves) a deeper problem; the term, from Kent Beck via Martin Fowler's Refactoring, is deliberately probabilistic, which makes it politer and more accurate than a verdict. Naming the specific smell beats adjectives, exactly as Chapter 5 predicts:

In a PR comment or design discussion the strong form is smell plus evidence plus consequence: "This class is heading toward god-object territory; the last four PRs all had to touch it, and reviewing it now requires holding all five workflows in your head." Compare "this code is a mess," which contains zero of those three. Adjectives like brittle (breaks under small changes), fragile, and hacky are usable shorthand between people who trust each other, but the named smell travels better; the full calibrated-criticism word list is in Chapter 14.

For tests and builds, the standard vocabulary: flaky (fails nondeterministically; the single most-used word in CI complaints), deterministic and hermetic (no outside dependencies) as the virtues, "the build is red/green", a regression (something that worked and now does not), and bisect (binary-search the history for the breaking commit): "flaky at about 3%, reproducible under --stress-runs 100, bisected to the pool change."

Marking confidence and scope, always

The habits that upgrade every description, whatever the domain:

• Mark measured versus felt: "per the dashboard" / "anecdotally" / "order of magnitude" / "back-of-the-envelope".
• Mark scope explicitly, including the happy part: "isolated to eu-west", "one tenant", "all writes", and the negative space: "reads unaffected."
• Timestamp claims in incidents ("as of 14:40") because they go stale while people read them.
• Round honestly: "roughly 40k" beats "41,237" (false precision) and "a lot" (no precision).

👉 With situations covered, the rest of the book is pure vocabulary. First the compressed layer everyone assumes you know: the abbreviations, from FYI and TIA to DRI and SLO, collected with tone warnings. On to Chapter 12.

The abbreviation decoder

Professional chat and email run on a compressed layer of abbreviations that nobody teaches and everybody assumes. This chapter is the reference: what each one means, where it belongs, and which ones carry hidden tone. Grouped by domain, with usage warnings where the abbreviation has teeth.

A general register rule before the tables: abbreviations belong to chat and informal email. In documents meant to last (design docs, postmortems, customer-facing anything), spell things out; a doc full of "IIRC" and "EOD" ages badly and excludes future readers. And when writing to someone who may not share the jargon (new joiners, non-engineers, external partners), an abbreviation you have to explain afterward costs more than it saved.

Everyday chat and email

Don't be confused: i.e. and e.g. are the highest-frequency abbreviation error in engineering writing. i.e. means "in other words" and must be followed by an equivalent restatement; e.g. means "for example" and must be followed by a non-exhaustive sample. "Databases, i.e. Postgres" claims Postgres is the only database; you almost always mean "e.g." If you cannot remember, write the English words; nobody was ever criticized for "for example".

Engineering process

Roles

Using the layer well

Three closing rules, which matter more than any single row above:

• Mirror your team. Every team speaks a subset. Two weeks of reading the channel tells you which of these are native locally; use those and drop the rest. Introducing exotic abbreviations to look fluent achieves the opposite.
• Expand on first use with newcomers present, exactly like a good doc: "PTAL (please take another look)". Costs four words, includes everyone.
• Never let an abbreviation carry the load-bearing part of a message. "Need this by EOD" where the deadline actually matters deserves "by 17:00 UTC today". The compressed layer is for convenience, and convenience is the first thing to sacrifice when precision matters.

👉 Abbreviations are the surface jargon. Below them sits the real vocabulary of senior engineering conversation: tradeoff, non-goal, blast radius, one-way door, the words that carry the actual concepts design discussions run on. That lexicon, plus the corporate phrases worth using and the ones worth avoiding, is next. On to Chapter 13.

The senior lexicon

Listen to a principal engineer in a design review and you hear a specific vocabulary: tradeoff, constraint, non-goal, blast radius, failure mode, one-way door. These are not decoration. Each word compresses a concept the discussion needs, and using them precisely is a large part of what "sounding senior" actually is, because the words force the thinking. This chapter is that vocabulary, organized by what the words do.

Words that frame decisions

• Tradeoff. The load-bearing word of all design conversation: what you give up to get what you want. Senior speech makes tradeoffs explicit and named: "We're trading write latency for read fan-out cost." A proposal described with no tradeoffs is either trivial or not yet understood.
• Constraint. A fact you must design around, as opposed to a preference. "The 300ms budget is a constraint; the ORM is a preference" is a sentence that reorganizes an entire argument.
• Non-goal. What this effort deliberately does not attempt (Chapter 4). Saying "multi-region is a non-goal for v1" converts a future accusation ("you ignored multi-region") into a recorded decision.
• Scope, and its pathologies: scope creep (the quiet accumulation of extra goals; "this is scope creep, let's park it") and descope (the deliberate removal of goals to protect a date; "we can hold Friday if we descope the audit table").
• One-way door vs. two-way door. Amazon-origin, now universal: irreversible versus reversible decisions. The operational rule attached to the words: two-way doors should be decided fast by the people closest to them; one-way doors deserve slow scrutiny. "Is this a one-way door?" is among the highest-value questions in any review.
• MVP-thinking phrases: "What's the smallest version of this that teaches us something?", "thin slice", "walking skeleton". All aim the conversation at sequencing rather than totality.
• "What would have to be true?" The consultant-origin reframe that converts "I don't believe your plan" into a checklist: "For B to win, what would have to be true about traffic growth?" It de-personalizes disagreement instantly, which is why Chapter 5's toolbox quietly relies on it.

Words that describe systems under stress

• Failure mode. How a thing fails, as a designed-for category: "the interesting failure mode is partial write." Asking "what are the failure modes?" is the senior version of "will it work?"
• Blast radius. How much is affected when it fails: "a bad config here has company-wide blast radius." Often paired with containment: "can we shrink the blast radius with per-tenant rollout?"
• Single point of failure (SPOF). The component whose death takes everything with it.
• Critical path. Borrowed from project scheduling into both meanings: the latency path requests actually traverse, and the dependency chain that determines the ship date. "Review from platform is now on the critical path" is precise escalation language (Chapter 10).
• Degradation and graceful degradation. Losing capability partially and on purpose, versus outright failure: "under load we degrade to cached recommendations rather than erroring."
• Backpressure. The system's ability to push back on producers instead of drowning: "there's no backpressure between ingestion and the workers; that's the outage."
• Headroom / capacity / bottleneck / hot path. The performance family: slack remaining, total limit, the narrowest constraint, the code that runs most often. "We have 2x headroom on CPU but the bottleneck is IOPS" is a complete capacity story in one sentence.
• Idempotent. Safe to apply twice. Beloved in retry discussions: "make the handler idempotent and the retry policy stops mattering."
• Race condition / deadlock / thundering herd. The concurrency bestiary; "thundering herd" (everyone retrying at once) earns its keep in any caching or outage conversation.
• Drift. Slow divergence from intended state: config drift, schema drift, "staging has drifted from prod, which is why the test lied."

Words that describe change over time

• Tech debt. Deliberate or accidental shortcuts whose interest you pay on every change. Senior usage is specific, not moral: "this module's debt is that config and code deploy together" beats "this code is bad."
• Migration path. How you get from here to there without stopping the world: "the design is fine; it's missing a migration path."
• Backward compatible / breaking change. Whether existing consumers survive your change unmodified. "Is this breaking?" is often the entire review.
• Deprecate, then sunset. Mark as discouraged-but-working, then remove. "Deprecated in Q3, sunset in Q1" is a complete lifecycle plan.
• Feature flag / rollout / rollback / canary. The safe-change toolkit: toggle without deploy, percentage release, undo, and the small early slice (named for the coal-mine bird) that detects trouble first.
• North star. The long-term direction that near-term steps should point toward: "the north star is one queue per tenant; this PR is a step, not the destination."
• Forcing function. An external constraint that compels action by a date: "the cert expiry is a useful forcing function for the migration."
• Second-order effects. The consequences of the consequences: "first-order, caching cuts DB load; second-order, staleness bugs and cold-start storms." Reaching for second-order effects unprompted is a strong seniority tell.
• Local optimum. Best-in-the-neighborhood but not best overall; usually deployed to argue for a bolder move: "tuning the pool is a local optimum; the global fix is killing the N+1 pattern."

Discussion-steering phrases

The verbal moves that organize conversations, with honest tone notes, because several live on the border of corporate cliché:

The pattern in the tone notes: phrases earn wear. Each was vivid once, became a default, and now signals fluency at best and filler at worst. Use the worn ones sparingly and the precise ones (timebox, steelman, non-goal) freely, and when a plain verb exists, notice that "dig into" outperforms "double-click on" with every audience that matters.

Don't be confused: "leverage", "utilize", and "use" mean the same thing in almost every engineering sentence, and "use" wins. "Utilize" adds syllables, not meaning; "leverage" as a verb is business-dialect that many strong writers deliberately avoid. The same de-inflation applies to "learnings" (prefer "lessons" or "what we learned") and "actionable insights" (prefer saying the action). Senior writing is conspicuously plain; inflated vocabulary reads as junior precisely because it tries to read as senior.

Calibration words

The quiet machinery of senior speech is uncertainty grading. A principal engineer almost never says a bare "yes" or "no" to a hard question; they attach a confidence level, cheaply:

• "Almost certainly" / "very likely" / "likely" / "50-50" / "unlikely" / "I'd be surprised."
• "I'm confident about the design; the estimate is soft."
• "High confidence, weakly held data: one benchmark run."
• "I'd put maybe 70% on the migration finishing clean."

And its partner, the explicit knowledge boundary: "I know the write path well; the replication side I'm guessing about, so weight accordingly." Speech with calibration marks is what allows others to build on your statements safely, which is the actual point of sounding senior: not impressiveness, but load-bearing reliability. The fastest way to acquire the habit is to notice every time you are about to state a guess in the grammar of a fact, and add the one word that marks it: "probably", "I think", "unverified".

👉 The concepts are in place; what remains is raw vocabulary. Next, the word list: the precise adjectives for praising and criticizing work (succinct, rigorous, brittle, egregious), the discussion words (orthogonal, moot, canonical), the AI-era additions (hallucination, grounding), and the chat glyphs (o/, /s, s/x/y/) that carry meaning nobody explains. On to Chapter 14.

The word list: precise words, loaded words, and chat glyphs

This chapter is a dictionary of the words engineers reach for (or should): the precision vocabulary for praising and criticizing work, the discussion words that structure arguments, the AI-era additions, and the chat glyphs (o/, /s, s/x/y/) that carry meaning nobody ever explains. Every entry has an example; the tone column flags the ones that bite.

Words for praising work

Don't be confused: concise, succinct, and terse all mean "short", and only two are compliments. Concise and succinct praise efficiency with completeness. Terse is short to the point of coldness: "his terse 'fine' ended the thread." Laconic is terse with style; curt is terse and rude. Calling someone's email "terse" is a criticism dressed as a measurement, so pick deliberately.

Words for criticizing work, calibrated

Ordered roughly by force. The right column is the check before using it.

The pattern from Chapter 5 and Chapter 11 governs this whole table: any of these words plus evidence is a critique; alone, each is just a mood. "Brittle: the last three refactors each broke it in a new place" earns its adjective.

Discussion and logic words

The AI-era additions

Words that moved from research papers into standup within the last few years:

• hallucination: an AI model stating fabricated facts fluently: "the model hallucinated a batchDelete endpoint that doesn't exist." The standard verb is hallucinate; "confidently wrong" is the colloquial cousin.
• grounding: tying model output to real sources: "ground the answers in the docs index and cite the passage."
• context window: how much the model can consider at once: "the diff doesn't fit in the context window; chunk it."
• prompt injection: malicious instructions smuggled into model input: "treat scraped pages as untrusted; classic prompt-injection surface."
• human-in-the-loop: a person gates the consequential step: "drafts are automated, sends are human-in-the-loop."
• eval: a measured test suite for model behavior: "no prompt changes without an eval run."
• agentic: systems where the model takes multi-step actions: "the agentic flow retries with a different tool on failure."
• slop: (informal, derogatory) low-effort AI-generated content: "close the PR; it's unreviewed slop."

Chat glyphs and micro-conventions

The wordless layer of engineering chat. Most of these come from IRC and early internet culture and are still everywhere:

Growing your own list

Three closing habits. First, harvest locally: every team has twenty more of these, and two weeks of reading your own channels with a notes file beats any book chapter. Second, before adopting a word, check which column it lives in here (or ask; "is 'janky' too casual for the RFC?" is a perfectly good question). Third, remember Chapter 13's de-inflation rule: the plain word wins whenever it does the same work. This list is for precision, not ornament.

👉 Single words are half the vocabulary; the other half is two-word verbs. English at work runs on phrasal verbs (spin up, roll back, dig into, pile up) and call-idioms ("you're breaking up"), and they are the hardest part of the language for non-native speakers because the meanings refuse to be guessed from the parts. On to Chapter 15.

Phrasal verbs: the two-word engine of work English

Spoken professional English barely uses the verbs textbooks teach. Nobody "commences" a service or "investigates" a failure in standup; they spin it up and dig into it. These two-word verbs (a verb plus a particle like up, out, into, whose combined meaning often cannot be guessed from the parts) are called phrasal verbs, and they are simultaneously the most natural-sounding and the hardest-to-learn layer of the language. This chapter collects the ones engineering actually runs on, grouped by situation, each with a real example.

One register note up front: phrasal verbs are the informal-to-neutral register. In a formal doc, "roll back the deployment" is fine (many are technical terms now), but "we'll figure it out" might become "we will determine the approach." In speech and chat, the phrasal verb is almost always the right choice; Latinate substitutes sound stiff out loud.

Making things run

Investigating and fixing

Workload and progress

Meetings and speaking

On calls: the audio-trouble phrasebook

Video calls have their own tiny dialect, used identically everywhere:

• "You're breaking up." (audio arriving in fragments)
• "You cut out for a second; say the last part again?"
• "We lost you" / "you froze" (video or audio stopped)
• "Your audio is choppy / garbled / robotic."
• "You're on mute." (the most-said sentence of the decade; the polite self-recovery is "sorry, I was on mute: ...")
• "There's an echo; someone may have two clients open."
• "The lag is bad; let's turn cameras off and see if it helps."
• "I'll drop and rejoin; give me thirty seconds."
• "Can you hear me now?" / "Loud and clear."
• "You go ahead" (yielding after you both spoke at once), "after you", and if it loops: "go ahead, then me."
• "Bear with me while the screen share loads." ("bear", not "bare")
• "Hop on / jump on a call?" (propose moving from chat to voice), "dial in" (join, from telephone days), "drop off" (leave early: "I need to drop off at :45").

Responsibility idioms

Not strictly phrasal verbs, but the same spoken register, and the cluster you asked about "on the hook" belongs to:

• on the hook (for): accountable, with consequences if it fails: "I'm on the hook for the audit deadline." Off the hook: released from it.
• drop the ball: fail at something you owned: "I dropped the ball on the renewal; it's back on track now." (A clean self-ownership phrase, pairs with Chapter 10.)
• pick up the slack: absorb work someone else is not doing.
• pull your weight: contribute your fair share.
• throw someone under the bus: sacrifice a colleague to save yourself; the phrase exists so you can name (and refuse) the behavior: "I'm not throwing the vendor under the bus; our retry logic amplified it."
• pass the buck: push accountability elsewhere; "the buck stops here" claims final accountability.
• on / off my plate: in / out of my workload: "Q3 planning just landed on my plate." Related: "I don't have the bandwidth" (no spare capacity; slightly corporate but standard).
• in the loop / out of the loop: informed / not: "keep me in the loop on the vendor thread."
• up to speed: fully informed and able to contribute: "bring the new folks up to speed before the review."
• heads down: focusing, do not disturb. Swamped / snowed under / underwater: overloaded.
• in the weeds: two senses, context decides: lost in excessive detail ("we're in the weeds; zoom out") or, borrowed from restaurant slang, overwhelmed by work ("the on-call is in the weeds; who can assist?").
• down the rabbit hole: pulled into a deep, absorbing tangent: "I went down a rabbit hole on the allocator; fascinating, irrelevant."

Don't be confused: "off of" ("get off of the call", "based off of the prototype") is common in spoken American English and redundant in writing; edit it to "off" or the right preposition. In particular, "based off of" should be "based on" in anything formal. Similarly, spoken fillers like "out of pocket" have drifted: it traditionally means paying personally ("out-of-pocket costs") but is now widely used for "unavailable"; with a mixed audience, prefer "unavailable" and keep "out of pocket" for money.

Learning them for real

Phrasal verbs resist memorization because the particle logic is only half-consistent (up often means completion: wrap up, finish up; out often means resolution: iron out, sort out; but look up, look into, and look out share nothing). Three practical tactics: collect them from your own team's chat (the local dialect is maybe eighty verbs deep, not eight hundred); when you meet one, note what it replaces ("dig into" = investigate) so your passive vocabulary converts to active; and use the one-in-one-out rule in your own messages: each stiff Latinate verb you catch ("utilize", "commence", "endeavor") is a slot where a natural two-word verb belongs.

👉 The vocabulary is now complete: abbreviations, concepts, precise words, and the two-word engine. The book closes with quality control: the specific mistakes (dialect slips, register errors, hedging pathologies, structural failures) that undo good vocabulary, and the checklist that catches them before you press send. On to Chapter 16.

Mistakes to avoid, and how to sound articulate

This closing chapter is the negative space of everything before it: the specific, recurring errors that make competent engineers sound less senior than they are, followed by the small set of structures that produce articulate speech and writing on demand. The mistakes are listed bluntly, because that is the fastest way to fix them; every one of them is common, none is shameful, and all are cheap to repair once seen.

Vocabulary slips (mostly non-native, all fixable)

These are standard patterns in Indian, European, and East Asian workplace English that read as errors to North American and British ears. Whether that is fair is a separate question; this is a field guide, and knowing the mapping is power:

Grammar-adjacent habits worth the same attention:

• Standup tense. "Yesterday I am working on the migration" → "Yesterday I worked on / was working on". The past-tense slot in standup formats is unforgiving because everyone hears it daily.
• Word-order in questions. "How it is going?" → "How is it going?"; "You can review it?" → "Can you review it?" Rising intonation on a statement works in speech but reads as a typo in writing.
• "on the call" / "in the meeting" (not "in the call" / "on the meeting"), "on vacation", "at standup". Prepositions are arbitrary; these particular ones are just high-traffic enough to memorize.

Register and tone mistakes

• Over-apologizing. "Sorry to bother you, sorry, quick question, sorry if this is stupid" spends status for nothing. Budget: one apology per incident, zero per question. The replacement for apology-as-greeting is the considerate ask from Chapter 3; the replacement for apology-as-filler is "thanks": "thanks for your patience" instead of "sorry for the delay" flips the frame from your debt to their virtue. (Real mistakes get real apologies, once, per Chapter 10.)
• Over-hedging. "I might be wrong, but maybe we could possibly consider perhaps caching?" contains one idea and four escape hatches. Calibration (Chapter 13) wants exactly one uncertainty marker per claim, sized honestly: "I think caching fixes this; not certain about invalidation."
• Under-hedging is rarer but costlier: bare confident assertions about guesses. If it later proves wrong, the miss is remembered as a broken promise rather than a bad guess, entirely because of the grammar it was delivered in.
• Command grammar at peers. "Fix the flaky test before merging" from a non-manager reads as rank-pulling. Requests take question form or we-form: "Could you fix the flaky one first?" / "Let's get the flaky one fixed before this lands." (Incident command is the exception: during an outage, imperatives are the correct register: "Roll it back. Sam, comms.")
• Mock-formality. "Dear esteemed colleagues, greetings of the day" in a Slack channel is a register error in the formal direction, and it reads as either machine translation or sarcasm. When unsure, default to the neutral middle: "Hi all," plus plain sentences.
• Humor and sarcasm in writing. Tone does not survive text serialization across cultures. Sarcasm in a PR comment ("great, another singleton") will be read straight by someone. Affectionate irony works only where a relationship already carries it; in public channels, play it straight.

Structure mistakes, and the structures that fix them

The deepest "articulate" secret is boring: articulate people answer in structures, and the structures are learnable in an afternoon.

Mistake: context-first ordering. The engineer's instinct is chronological: all the background, then the investigation story, then, eventually, the point. In professional communication the order inverts:

• BLUF / answer-first. Verdict, then reasoning on demand: "No, we can't make March. The blocker is the vendor migration; here's the chain..." (Chapter 8 covers the executive version.)
• PREP for spoken answers: Point, Reason, Example, Point restated. "I'd hold the release (point). The canary caught a memory climb (reason); same signature as the March incident (example). So: hold until we've bisected it (point)." Twenty seconds, complete, calm. When you feel a ramble beginning, PREP is the exit.
• The rule of one. One message, one topic, one ask. The five-topic message gets answered on its easiest topic and the hard four die (Chapter 3's numbered-list trick is the multi-topic escape hatch).

Mistake: burying the ask. If the reader cannot answer "what do you want from me?" after one read, the message failed. Bold the ask in long messages; in short ones, end on it, as a question mark.

Mistake: wall-of-text. Paragraph breaks, bullets for parallel items, code blocks for anything verbatim (error text, commands, names). Formatting is not decoration; it is parsing assistance, and senior readers judge messages partly by whether they can be skimmed.

Mistake: filler in speech. "Basically", "actually", "like", "you know", "sort of" survive under pressure. The professional replacement is the pause. A two-second silence before answering reads as thought, not weakness; "let me think for a second" is a complete and confident sentence. Non-native speakers fear the pause because it feels like a fluency failure; listeners hear the opposite.

Speaking as a non-native: the honest notes

• Clarity beats accent, always. Nobody who matters is grading your accent; everybody is affected by pace and volume. The single highest-value speech habit is going 10% slower than feels natural, especially on video calls with compression and lag.
• Scripts for the hard moments are legitimate. "Could you say that again? The audio dropped" (blaming the audio is the polite convention, used by native speakers too). "Let me make sure I understood: you want X by Friday, right?" (the playback from Chapter 8, doubling as comprehension insurance). Rehearsing your standup line or your design-review opener out loud once is not cheating; it is what polished speakers do.
• Written channels are a legitimate strength to play. If your written English is stronger than your spoken, steer big topics to docs and threads: "I'll write this up; it deserves better than my improvising." That sentence is itself fluent professional English.

The polish checklist

Before sending anything that matters, thirty seconds:

1. Is the ask unmissable, with a date?
2. Is the first line the point (BLUF), not the background?
3. Names spelled exactly right? (Chapter 1)
4. One hedge per claim, sized honestly?
5. Apologies ≤ 1, and earned?
6. Could a screenshot of this appear anywhere without embarrassing you? (The durable-record test: chat is forever.)
7. Read it once as the recipient: what do they know, what do they need, what will they feel?

That last item is the whole book in one line. Every technique in these chapters (the no-hello rule, the purpose tags, the severity labels, the steelman, the early flag, the calibrated hedge) is a special case of modeling the reader before you press send.

👉 That closes the lexicon, but not the book. Messages are one genre; the record is another. Next: the written artifacts that outlive every chat scroll (bug reports, PR descriptions, commit messages, runbooks, postmortems), each with a fixed anatomy that is faster to fill than to improvise. On to Chapter 17.

The written record: tickets, PRs, commits, postmortems

Chat evaporates; the written record is what your team actually keeps. Bug reports, tickets, pull request descriptions, commit messages, release notes, runbooks, and postmortems are read months later by people with no context, often including a future version of you at 3 a.m. Each genre has a fixed anatomy, and filling the anatomy is faster than improvising, because the anatomy is exactly the list of questions readers will otherwise have to ask you.

The register rule for all of them: write for a stranger. No "the issue we discussed", no "the usual fix", no abbreviations that are local slang (Chapter 12's doc rule). The reader has your text and nothing else.

Bug reports

The anatomy, in order:

Title:      Checkout returns 500 when the cart contains only a gift card

Environment: prod, eu-west, Chrome and curl both; started ~2026-07-19
Steps:
  1. Create a cart with a single gift-card item (no physical goods)
  2. POST /checkout
Expected:   200 with order confirmation
Actual:     500; response body and trace ID below (verbatim)
Impact:     ~40 checkouts/day hit this path (query attached); workaround
            exists (add any physical item), so severity 3
Evidence:   trace 4f2a..., log excerpt, HAR file attached
Not it:     payment provider status page green; same fail with card
            payments disabled, so not the gateway

The parts that separate a report engineers thank you for from one they bounce back:

• The title states symptom plus trigger, because titles are what triage sees. "URGENT: site broken!!" contains zero of either.
• Steps are a numbered recipe starting from nothing. The gold standard is the minimal reproduction: the smallest input that still fails. Every step you strip is an hour the assignee does not spend.
• Expected versus actual is the load-bearing pair; a surprising number of "bugs" dissolve when the reporter writes down what they expected.
• Evidence is verbatim (Chapter 14): paste the exact error, never a paraphrase. "Some kind of auth error" is a séance; "403: token audience mismatch" is a diagnosis.
• "Not it" (what you already ruled out) is the mark of a report by an engineer: it saves the assignee from re-walking your dead ends.

Don't be confused: severity and priority are different dimensions and most trackers have both. Severity is impact ("how bad is it when it happens"); priority is ordering ("how soon do we work on it"). A crash affecting one internal demo tool is high severity, low priority; a typo in the signup flow's pricing is low severity, very high priority. Filling one field from the other is the classic triage error, and "why is this P3, it crashes!" arguments are usually the two dimensions talking past each other.

Tickets and stories

For planned work, the reader's questions are scope questions, so the anatomy is: context (one paragraph), the change requested, acceptance criteria (the checkable list that defines done), and explicit non-goals. Acceptance criteria in the checkable form: "retries capped at 3; the cap is a config value; a metric counts exhausted retries." Vague tickets ("improve retry behavior") do not shrink work; they relocate the scoping argument to the code review, the most expensive place to have it.

Pull request descriptions

The reviewer's questions, in the order they have them:

What:      Cap checkout retries at 3 and surface a metric for exhaustion.
Why:       Uncapped retries amplified Tuesday's outage (INC-214); this is
           action item 2 from the postmortem.
How:       Config-driven cap in RetryPolicy; new counter checkout_retry_
           exhausted; no behavior change when the flag is unset.
Testing:   Unit tests for 0/1/n; ran the INC-214 replay locally, storm
           does not amplify. Screenshot of the new dashboard panel below.
Rollout:   Behind flag retry_cap, default off; enable per-region.
Rollback:  Flag off; no schema changes.
Links:     Fixes #4821. Postmortem: go/inc-214.

"What" and "why" are for every reader forever; "testing" and "rollback" are for the reviewer and the on-call. A PR description that says "see title" outsources all four to archaeology. Two habits worth stealing: state what you did not do ("does not touch the payment retries; that is #4830"), and when the diff looks bigger than the change, say why ("mostly mechanical rename; the real change is in retry_policy.py").

Commit messages

The convention, stable across most of the industry: a subject line in the imperative mood ("Add retry cap", not "Added" or "Adds"), around 50 characters, no trailing period; then a blank line; then a body that explains why, wrapped at ~72 characters. The imperative reads oddly until you notice it completes the sentence "if applied, this commit will...". The body is where you talk to the future debugger:

Cap checkout retries at 3

Uncapped retries turned a 2-minute payment blip into a 40-minute
brownout during INC-214: every failed checkout re-entered the queue
and competed with live traffic. A cap of 3 keeps the recovery
property (transient blips still heal) without the amplification.

The cap is config-driven because BFCM traffic may want 1.

Many teams add a type prefix (Conventional Commits: fix:, feat:, chore:) so changelogs can be generated; adopt whatever the repo already does. The anti-patterns are universal: "wip", "fix", "final fix", "actually final" tell the future nothing, and squashing them before merge is basic hygiene.

Release notes and changelogs

Two genres wearing one name. The changelog is for engineers: exhaustive, terse, per-change ("Cap checkout retries at 3 (#4821)"). Release notes are for users, written in outcomes and the second person: "Checkout now recovers faster during payment provider hiccups." The translation discipline is Chapter 20's whole subject; the one-line version is that users do not have retries, they have slow checkouts. Never let the internal name of a thing leak into user-facing notes ("fixed a bug in HydraQueue v2").

Runbooks

A runbook is instructions for a stressed person at 3 a.m., which sets the style rules: imperative sentences, exact commands (copy-pasteable, with placeholders marked), expected output after each step so the operator knows they are still on the path, and explicit decision points ("if the queue depth is falling, stop here; if not, continue"). The words should, probably, and usually are bugs in a runbook. So is any step that has never been executed; untested runbooks are fiction in a confident font, and the fix is a game day (a scheduled practice run).

Postmortems

The capstone genre, and the one with the strictest culture rules (Chapter 10). The standard skeleton:

1. Summary: three sentences a director can read alone.
2. Impact: who, what, how long, how many, in numbers.
3. Timeline: timestamped facts only, no analysis mixed in ("14:02 alert fired; 14:09 acknowledged; 14:31 rollback started").
4. Contributing factors: plural on purpose, systems not people (Chapter 7's blameless grammar). The trigger gets a sentence; the conditions get the pages.
5. What went well / what went poorly: including in the response itself ("paging worked; the runbook was stale").
6. Action items: each with an owner and a date, filed as real tickets. A postmortem whose action items are not tracked was a writing exercise, not an engineering artifact.

Write the timeline the day of the incident while the logs and memories agree, and write the analysis a day later when the adrenaline does not.

👉 The written record covers work; the next chapters cover people. First the conversation that shapes your career more than any design review: the 1:1 with your manager, and the language of feedback, promotion, and pay. On to Chapter 18.

1:1s, feedback, and career conversations

The recurring meeting with your manager is the highest-leverage conversation you have, and most engineers spend it on the lowest-value content: status their manager could read in the tracker. This chapter is the language of using it properly, plus the adjacent genres nobody practices until the stakes are high: asking for feedback, giving it, asking for a promotion, and talking about money.

The 1:1 is your meeting

The near-universal convention: the report owns the agenda, the manager owns the safety of the room. Bring two or three topics, and say the shape out loud at the start:

• "Quick status is in the tracker, so I'd rather spend the time on two things: the on-call load, and a career question."
• "Nothing burning this week; can we do a longer-term topic? I've been thinking about where the platform work is heading."
• "One sensitive thing this week; I'd like most of the time for it."

Topics that repay the slot: friction ("the review latency from platform is costing us days; can you help me route it?"), context ("what is the pressure behind the Q3 date? Knowing the why would change how I cut scope"), early warnings ("flagging that Ravi and I keep colliding on the API surface; nothing broken yet, but worth watching"), and growth (below). Topics that waste it: reciting the standup you already gave.

Disagreeing with your manager belongs here too, in private first, exactly per Chapter 5: "I want to push back on the staffing call before it's final. Can I make the case?" You get candor credit for the attempt even when you lose.

Asking for feedback

"Any feedback for me?" reliably produces "no, you're doing great", because the question is unanswerably broad and mildly dangerous to answer. Narrow it and it starts working:

• "What's one thing about how I ran the design review that you'd change?"
• "Was the incident update cadence right, or too noisy?"
• "If I want to be trusted with the next migration, what would you need to see first?"

When feedback arrives vague ("be more strategic"), mine it politely for an instance: "Can you point me at a recent moment where I could have been more strategic? An example would help me aim." And when it stings, the professional move is the same as Chapter 5's: receive first, evaluate later. "That's useful and a little painful. Let me sit with it and come back Thursday with what I plan to change." Arguing with feedback in the moment teaches people to stop giving it to you, which is the actual career damage.

Giving feedback: SBI

The standard structure is SBI: Situation, Behavior, Impact. Anchor the moment, describe observable behavior (not character), state the effect:

• Peer, corrective: "In yesterday's review (situation), you answered the first three questions before Priya finished asking them (behavior). She stopped contributing for the rest of the meeting, and we lost our storage expert's read (impact). I don't think you noticed, which is why I'm mentioning it."
• Peer, positive, same structure: "In the incident (S), you posted updates every fifteen minutes even when nothing changed (B). Nobody pinged the channel asking for status even once (I). That's the standard now, as far as I'm concerned."
• Upward: "When the priority changed on Tuesday (S), the team heard it from the PM before you (B), and it read like we were out of the loop on our own project (I). A two-line heads-up would fix it entirely."

Note what SBI removes: verdicts about the person ("you're dismissive", "you're disorganized") that trigger defense and carry no repro steps. It is Chapter 11's description formula applied to humans: observable, specific, scoped.

Don't be confused: a mentor and a sponsor are different assets. A mentor talks to you: advice, review of your plans, pattern matching from experience. A sponsor talks about you: says your name in rooms you are not in, puts you up for the visible project, spends their own credibility on your promotion. Mentors are easy to get and valuable; sponsors are hard to get and career-deciding. "Who is sponsoring this case?" is the real question behind most promotion outcomes, and cultivating a sponsor mostly means doing visible work and making it easy to retell (Chapter 2's credit mechanics, pointed at yourself for once).

The promotion conversation

The mistake is raising it as a verdict request ("do I get promoted this cycle?"), which invites a one-word answer. Raise it as a gap analysis, early, in writing-friendly form:

• "I'd like to be a credible senior case within two cycles. Can we spend a 1:1 on what the gap looks like from your side?"
• "What would a promotion packet for me be missing today? I'd rather hear it now than at calibration."
• After the answer, convert it to record: "Summarizing what I heard: the gap is cross-team scope and a design doc with my name leading. I'll aim the queue-split work at exactly that; can we check the read in a month?"

Two supporting habits. Keep a brag document: a running file of outcomes with numbers and links ("led INC-214 response; wrote the postmortem; retry cap adopted org-wide"), updated monthly, because promotion packets and self-reviews are written from evidence and memory fabricates. And make your manager's job easy: "here are the six bullets for my packet, each with a link" beats "you know what I did."

The salary conversation runs on the same grammar, plus data and no bluffing: "I'd like to talk about compensation at our next 1:1, so flagging it now. My research puts the band for this role at X to Y; I'm at Z with two cycles of exceeds. What would it take to close that?" Never voice a leaving threat you are not prepared to execute; it converts the conversation from adjustment to countdown.

Self-reviews and interview stories

The self-review genre rewards exactly what the status chapter rewards: outcomes with numbers, claimed at the right size. "Led the retry redesign; checkout brownouts went from monthly to zero across two quarters" is a review bullet; "worked on reliability" is filler, and "singlehandedly saved checkout" invites your reviewers to correct you. Claim your real role with plain verbs: led, designed, shipped, unblocked, reviewed, mentored.

For behavioral interviews and review narratives alike, the standard container is STAR: Situation, Task, Action, Result. One tuned example: "Our checkout amplified a payment blip into a 40-minute brownout (S). I owned the fix under a two-week deadline (T). I capped retries behind a flag, replayed the incident traffic to prove it, and wrote the runbook (A). The next provider blip lasted 90 seconds and self-healed; the pattern was adopted by two other teams (R)." The most common failure is drowning in S; interviewers want A and R, told in "I" sentences, with honest edges ("what I'd do differently is flag it per-region from day one").

👉 Careers are the vertical human conversations; the horizontal ones are the social fabric around the work: joining a team, leaving one, congratulating, condoling, calling in sick, and handing over before vacation. Small genres, high stakes-per-word. On to Chapter 19.

The social layer: joining, leaving, and everything human

Around the work sits a layer of small human genres: introductions, congratulations, goodbyes, condolences, sick days, vacations. Each is short, each has conventions, and each is memorable out of proportion to its length; people forget your standups and remember your farewell message. This chapter is the phrasebook for the moments that are about people, not systems.

Joining a team

The self-introduction message, posted in the team channel in week one:

Hi all o/  I'm Alex, joining the platform team today from FinCo, where
I mostly did payments infrastructure. I'll be picking up the queue
workstream with Sam. Currently drinking from the firehose, so expect
basic questions for a few weeks; pointers to docs I should have read
are very welcome. In person I'm in the Lisbon office, usually 9 to 5
WEST.

The anatomy: name, where from (one clause), what you will work on, an explicit license for your own beginner questions, and logistics. The beginner-questions line is doing real work: it pre-frames a month of "where does X live?" as expected rather than worrying. Use the license while it lasts; the new-joiner card quietly expires after a quarter, and the asking chapter's show-your-work rules take over.

The receiving side takes one line and is worth it every time: "Welcome Alex! I own the deploy tooling; ping me any time, no question too basic." Teams where every joiner gets three of those messages onboard measurably faster, and it costs ten seconds.

Congratulations

Specific beats generic here exactly as in Chapter 2; "congrats!" is a reaction emoji in word form, while one detail makes it a message:

• Promotion: "Congrats, very well deserved. The INC-214 response alone was a senior-engineer performance."
• Launch: "Congrats on shipping! The migration path especially was clean work."
• New baby: "Congratulations! Enjoy the leave and ignore this channel completely; we've got it." (The second clause is the gift.)
• Leaving for a new job: "Congrats on the new role; their gain, our loss. Thanks for everything on the queue work." Never guilt-trip a leaver, and never speak of their new employer with resentment.

Farewells

Your own leaving message is read by everyone and remembered; the genre rules are strict because the failure modes are famous. Gratitude, specifics, contact info, zero grievances:

Friday is my last day after four years. Highlights I'll carry with me:
the 2024 rewrite (still the best team I've worked on), and watching
the platform go from two nines to four. Thanks especially to Sam, who
taught me what a good design review feels like, and to this channel
for answering five hundred of my questions. I'm at alex@... and on
LinkedIn; if you're ever near Lisbon, coffee is on me. Keep the DLQ
drained o7

Whatever the real reasons for leaving, the farewell message is not the venue; the exit interview is. A bitter goodbye buys ten seconds of satisfaction and a permanent last impression, and the industry is small.

When a teammate is laid off (as opposed to leaving), the register changes: no public celebration of their "next chapter" they did not choose. Reach out privately, concretely: "I'm so sorry. I'd be glad to be a reference, and I know two teams hiring for exactly your profile; want intros?" Offers of specific help land; "let me know if you need anything" politely evaporates.

Condolences and hard news

When a colleague loses someone or faces serious illness, the rules are: short, warm, zero questions, zero pressure to reply, and concrete cover for their work:

• "I'm so sorry, Maria. No need to reply to this. Your on-call is covered and the review can wait; take whatever time you need."
• On their return, follow their lead: "Good to have you back" and normal work talk unless they open the topic.

Never ask for details of an illness or absence; "take care of yourself, we've got it covered" is complete. The manager may need specifics; you do not.

Sick days, time off, and handovers

The sick-day message owes exactly two things, availability and coverage, and zero medical detail:

Out sick today, hopefully back tomorrow. Nothing of mine blocks
anyone; the #4132 review can go to Ravi if it gets urgent. I'll be
off Slack.

("I'll be off Slack" is a boundary sentence, and teams with healthy norms respect it; do not write "available if needed" unless you mean it.)

Planned time off has two moves. The early flag, weeks out: "Planning to be out July 3 to 14; flagging now so the release plan can route around it." And the handover note the day before, which is a runbook for your absence:

OOO July 3-14, back the 15th. Handover:
- Queue migration: 60% done, paused safely; nothing runs while I'm out.
  State doc: go/queue-mig. Sam has context if platform asks.
- On-call: swapped with Ravi (thanks Ravi).
- Decisions that can't wait: Dana can make any call on the migration;
  bias to "pause" over "improvise".
- Everything else keeps until the 15th.

The matching OOO auto-reply is three lines: dates, who covers what, when a reply can be expected. "I will respond to your email upon my return" beats promising to check mail on a beach, and then actually not checking it; a boundary stated is a boundary others can plan around.

Don't be confused: PTO is the accounting unit (paid days off, covering vacation and often sickness); OOO is the state of being unavailable, whatever the reason; leave is the word for the long structured absences (parental leave, medical leave, sabbatical). "I'm on PTO Friday" and "I'm OOO Friday" both work for a day off, but someone "on leave" is gone for weeks or months and should be dropped from day-to-day threads entirely, not cc'd "just in case".

The small apology

Not the incident kind (Chapter 10); the human kind, for the day you were short with someone:

• "Hey, I was curt with you in standup; the deadline is not your fault and I'm sorry. Your question was legitimate; here's the real answer."

Anatomy: name the behavior plainly, no "sorry if you felt", no excuse riding in the same sentence, and repair (the real answer) attached. It takes thirty seconds, and it is one of the strongest seniority signals in this book precisely because it is rare.

Small talk: the map

Small talk is protocol, not content (Chapter 1), and the skill is topic selection plus graceful exit:

Cross-cultural note: the amount of expected small talk varies hugely (two exchanges in Berlin, ten in Austin, and in much of Asia the relationship-building is the meeting). Match the room. Exiting gracefully: "I'll let you get to it; good luck with the launch" or, in a call, the host's "alright, let's dive in" ends the phase for everyone.

Opting out of social events is allowed and needs one line, no excuse inflation: "I'll skip the karaoke but see everyone at dinner." Nobody professional keeps score of your evenings, and "I don't drink, I'll have a coke" requires no elaboration in any healthy workplace.

👉 Everything so far assumed engineers talking to engineers. The next chapter crosses the aisle: product managers, designers, support, sales, and customers, where the same facts need different words and the translation itself is the skill. On to Chapter 20.

Talking across the aisle: product, support, customers

Inside engineering, "the p99 regressed after the pool change" is a complete sentence. Say it to a product manager and you have transmitted anxiety without information; say it to a customer and you have leaked an internal organ. Cross-functional communication is translation: the facts stay fixed while the load-bearing details change per audience. This chapter is the phrasebook for the main audiences: product, design, support and sales, and the customer.

The translation principle

Each audience consumes a different projection of the same event:

The discipline is answering their question, not restating yours. "The connection pool was exhausted" answers an engineering question. The product answer to the same event is "checkout was slow for about 8% of users for 40 minutes; it's fixed; preventing the class of problem costs about a week and I recommend we spend it."

Engineer-speak to product-speak

The recurring translations, worth memorizing as pairs:

The pattern in every row: mechanism becomes consequence, jargon becomes cost or risk, and "it depends" becomes a range plus the variable that decides it (Chapter 13's calibration, worn for a different room).

Two product-side phrases to adopt yourself. "What problem are we solving?" is the legitimate first question for any feature request, and asking it marks you as senior rather than obstructive if the tone is curious. And when a "small change" lands: "Small on the screen, large underneath: this touches how we store addresses, so it's a two-weeker. Happy to walk through why, and there's a genuinely small version if we can accept X." (Then the PM makes an informed trade, which is their actual job; the PRD, product requirements document, is their genre the way the RFC in Chapter 4 is yours.)

Don't be confused: output and outcome are product's load-bearing pair. Output is what shipped ("we launched saved searches"); outcome is what changed in the world ("repeat visits rose 12%"). Engineering naturally reports output; product and executives are paid in outcomes. Wiring the two into one sentence ("shipped the retry cap; checkout brownouts went from monthly to zero") is the single fastest upgrade to how your work reads upward. Your brag document should be written entirely in that wired form.

Working with design

Design critique runs on Chapter 5's exact rules, with one addition: separate feasibility from preference, loudly. "I can build this two ways: pixel-faithful in three weeks, or 90% of it in three days; the gap is the custom scroll behavior" gives the designer a real choice instead of a veto. And when you have a taste opinion, tag it as one: "Taste reaction, feel free to ignore: the empty state feels crowded to me." Designers extend engineers the same courtesy about architecture roughly in proportion to receiving it.

Support and sales: the promise firewall

Support and sales live at the edge of the company, where words become commitments. Two standing rules:

• Escalations in: treat support tickets as bug reports from an ally who lacks your tools, and answer with triage plus a script: "Great repro, thanks. Triaged as P2: it's cosmetic, workaround exists (the export button), fix targeted for the next release. Feel free to tell the customer exactly that, minus the P2." Support quoting you verbatim to a customer is the design constraint; write accordingly.
• Promises out: sales will ask "can we tell the prospect X ships in Q3?" The firewall sentence: "Here's what I can commit to: what's shipped today, and that Q3 is the current plan, not a contract. For a contractual date, that's Dana's call, not mine." You are not being unhelpful; you are keeping promise-making with the people accountable for promises. A casual "yeah, probably Q3" in a hallway becomes a clause in someone's renewal negotiation with alarming reliability.

Writing for customers

The same incident, internal then external, is the best possible illustration of every rule in this section:

Internal (channel):
  INC-214 mitigated. Root cause: uncapped checkout retries amplified
  the payment provider blip; rollback of 14:00 deploy stopped the
  bleeding, retry cap lands tomorrow. Impact: 8% of checkouts erroring
  or >10s for 40 min, eu-west only. Postmortem Thursday.

External (status page):
  Resolved: Between 14:02 and 14:43 UTC, some customers in Europe
  experienced errors or slow loading during checkout. This is fully
  resolved, and completed orders were not affected. We're sorry for
  the disruption, and we've made changes to prevent this class of
  issue from recurring.

What the translation did: dropped the internal nouns (INC numbers, deploy times, provider blame, team names), converted percentages into "some customers" with honest scope ("in Europe"), added the fact customers actually care about ("completed orders were not affected"), apologized once in plain words, and claimed prevention only because it is true. What it refused to do: minimize ("a small number of users may have briefly..."), speculate, or promise "this will never happen again", which no engineer can sign.

Customer-facing apology register, in general: human, brief, unhedged, and free of both legal panic and theatrical self-flagellation. "We're sorry for the disruption" plus the facts beats a paragraph of "we deeply regret any inconvenience that may have been experienced." (For anything with legal or contractual weight, comms and legal review the wording; volunteering your own draft of a breach notification is not the moment for initiative.)

Demos to non-engineers follow the same translation: narrate outcomes ("watch the order recover on its own"), hide the terminal unless asked, and translate every number on screen into a consequence the room prices ("that 40ms is why the page feels instant now").

👉 Sixteen chapters of technique and four of genres; what remains is watching it all run at once. The last part of the book is the situation room: full transcripts of real situations (a feature from first pitch to launch, an incident minute by minute, and the five hardest conversations), annotated line by line with why each sentence is doing what it does. On to Chapter 21.

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.

Situation walkthrough: an incident, minute by minute

Incident communication is where every rule in this book runs at combat speed. This chapter replays a realistic incident channel from first alert to postmortem, annotated. The scenario is the one from Chapter 20: a payment provider blip that uncapped retries amplify into a checkout brownout.

The cast: Ravi, on call. Alex and Sam, engineers. Dana, engineering manager. Marta, support lead.

Don't be confused: mature incident response separates three roles that small teams collapse into one. The first responder (usually the on-call) acknowledges and starts investigating. The incident commander (IC, awkwardly colliding with "individual contributor") owns coordination and communication, and deliberately does not debug. Subject matter experts debug. The commander role exists because the person elbow-deep in logs is the worst-placed person to also run updates, and the transcript below shows the handoff working.

14:02 to 14:20: detection and mobilization

14:02  [bot] ALERT: checkout 5xx rate 4.1% (threshold 1%), eu-west
14:04  Ravi: Ack, looking. Thread here please.
14:09  Ravi: Real, not a blip: 5xx climbing, 6% now, eu-west only.
       Checkout p99 also degraded, 400ms -> 2.1s. Opening INC-214,
       severity 2 for now. I need a second pair of eyes on the
       payment path; Alex, you're up if available.
14:10  Alex: Here. Taking the payment provider angle.
14:12  Dana: I'll run comms as of now so Ravi can debug. Updates from
       me every 15 min in this channel. Current status:
       investigating, impact ~6% of eu-west checkouts, no data loss
       suspected. Next update 14:27.
14:16  Alex: Provider status page shows elevated errors on their side
       since 13:58. But our 5xx rate is 6x their reported error rate,
       so something of ours is amplifying. Suspect the retries;
       checking.
14:19  Marta: Support here: 11 tickets so far, all eu-west, all
       checkout. Using the wording "we're aware and investigating";
       shout if you want different.

Annotations:

• "Ack, looking. Thread here please" does three jobs in six words: claims ownership, starts the record, and routes chatter out of the main channel. Nothing kills incident comms like four side conversations.
• Ravi's 14:09 is the description formula under fire: rate with baseline, percentile with baseline, scope, and an honest severity guess "for now". No adjectives, no panic.
• Dana's 14:12 is the commander handoff in one message: who runs comms, the cadence promise, the current state word (investigating), and the next-update time. From this point the debuggers never break focus to answer "any update?", because the answer is always "at :27, from Dana".
• Alex's 14:16 models suspicion discipline: a fact ("their page shows errors"), the reasoning gap ("6x their rate"), and a hypothesis explicitly labeled ("suspect the retries; checking"), not asserted.
• Marta's message is the support ally pattern in reverse: she brings data (ticket count as an impact signal) and syncs the external wording instead of freelancing it.

14:27 to 14:45: diagnosis and the call

14:27  Dana: Status: cause identified with high confidence. The 14:00
       deploy raised the retry ceiling; combined with provider
       errors, retries are amplifying load ~6x. Two options on the
       table, decision in this thread in <10 min. Impact steady at
       6-8%. Next update 14:42.
14:31  Ravi: Options: (A) roll back the 14:00 deploy, ~8 min, high
       confidence, also reverts two unrelated fixes; (B) hotfix just
       the retry config, ~20 min incl. review, surgical but slower.
       I lean A: reversibility beats elegance mid-incident.
14:33  Sam: +1 A. The unrelated fixes are cosmetic; nothing depends
       on them today. Confirmed by checking the deploy manifest.
14:34  Dana: Decision: A. Ravi executes, Alex watches provider-side
       recovery so we don't misattribute. Go.
14:42  Dana: Status: rollback deployed 14:39. 5xx rate falling, 3.1%
       and dropping. Calling it mitigated, not resolved: the retry
       config that allowed this is still in the codebase, and the
       provider is still degraded. Next update 14:57.

Annotations:

• 14:27 upgrades the state word deliberately: identified, with a confidence marker, and pre-announces a decision with a deadline. Compare the anti-pattern: silence until someone asks.
• Ravi's option framing is the escalation decision-request shape, compressed: two options, costs, a lean, and a principle ("reversibility beats elegance mid-incident") that makes the lean auditable.
• Sam's "+1 A" carries weight because it arrives with its evidence ("confirmed by checking the manifest"), not as a vibe.
• Dana's decision message assigns the watching job too. "Alex watches provider-side recovery so we don't misattribute" prevents the classic post-rollback error: declaring victory over a graph that was recovering anyway.
• 14:42 refuses the premature all-clear: mitigated, not resolved, with the reason spelled out. This one distinction (Chapter 10) is the most-audited sentence in any incident record.

15:10: standing down

15:10  Dana: Status: resolved. 5xx back to 0.1% baseline for 20+
       minutes, provider recovered, retry cap PR is up for tomorrow
       (#4821). Standing down the incident. Timeline notes are in the
       doc while memories are fresh: go/inc-214. Postmortem Thursday
       10:00, blameless as always; if you touched this incident,
       please add your timestamps to the doc today. Thanks all;
       textbook response, and Marta's ticket feed was our best
       impact gauge for the first ten minutes.

The stand-down message closes every loop it opened: the metric that justifies resolved, the follow-up work already tracked, the postmortem scheduled with its ground rule restated, the same-day timeline ask (Chapter 17), and specific credit (Chapter 2) to the least glamorous contribution in the room.

Thursday: the postmortem, two extracts

Dana:  Ground rule reminder: we're debugging the system, not the
       people. Everything anyone did made sense at the time with the
       information they had, or we have a different problem to fix.

Alex:  Contributing factor two: the retry ceiling change shipped
       without a load test because our load tests don't model
       provider degradation at all. I wrote the change, and given
       what the tooling showed me, I'd write it again. That's the
       point: the tooling has to show the next person more.

Sam:   Proposed action items: (1) retry cap with a config maximum,
       owner Alex, this week, already in review. (2) Add provider-
       degradation profile to load tests, owner me, two weeks.
       (3) The runbook said "check the queue depth" but not where;
       one-line fix, owner Ravi, today. Filing all three now.

Annotations: Dana's ground rule is the blameless frame said out loud, not assumed. Alex demonstrates the partner move: plain first-person facts ("I wrote the change") wrapped in system analysis, neither hiding nor flagellating. And Sam's action items each carry an owner and a date and become tickets in the meeting, which is the entire difference between a postmortem and a support group.

The external note

The customer-facing translation of everything above is four sentences, and writing it is Chapter 20's discipline:

Resolved: Between 14:02 and 14:39 UTC, some customers in Europe saw
errors or slow loading during checkout. Completed orders were not
affected. The issue was resolved by reverting a configuration change,
and we are adding safeguards against this class of problem. We're
sorry for the disruption.

No INC numbers, no provider blame, no percentages that invite arithmetic, one plain apology, and only claims an engineer would sign.

👉 One walkthrough remains: the conversations everyone dreads. Slipping a date to your manager's face, reclaiming credit that walked away, being put on the spot by an executive, taking a harsh review, and saying no to a colleague, each played out with the words that work. On to Chapter 23.

Situation walkthrough: the hard conversations

The last chapter of the book is the five conversations engineers lose sleep over, played out in full: slipping a date face to face, reclaiming taken credit, being put on the spot by an executive, receiving a harsh review, and refusing a colleague. Each scene shows the words, the annotation shows the machinery, and a "if it goes sideways" note covers the branch where the other person does not cooperate.

Scene 1: slipping the date, in person

The 1:1, Tuesday. Alex has known since Monday morning that the migration will miss Friday.

Alex:  Before anything else: the migration won't make Friday. Tuesday
       is the honest date. The backfill runs 4x slower against prod
       data than staging predicted; I found out yesterday and spent a
       day confirming it's real before bringing you a false alarm.
       Two options: take Tuesday, or hold Friday by skipping the
       audit table and backfilling it next week. Both are safe; I
       lean taking Tuesday.

Dana:  Marketing has the announcement queued for Friday.

Alex:  Then option B may genuinely be better; the audit table isn't
       user-visible. What I don't want is to discover a third
       constraint on Thursday. Who else is planning around Friday?

Dana:  Let me find out. Good flag; I'd much rather redo a plan today
       than apologize on Friday.

Annotations: bad news first, no throat-clearing (Chapter 10); the delay between knowing and telling is explained (confirming, not hiding); options arrive with the news; and Alex's question ("who else is planning around Friday?") treats the date as a shared system, not a personal failing. Note what is absent: apology spirals, blame of the staging environment, and optimism theater ("we might still make it if everything goes perfectly").

If it goes sideways: if the response is anger ("this is unacceptable"), do not absorb it as a verdict on you; return to the decision: "I hear that, and Friday still isn't real. Which option hurts less?" Anger at bad news is weather; the date is climate.

Scene 2: the credit that walked away

In the sprint review, a director praised "Sam's caching design". The design was Alex's; Sam presented it. Alex, in a DM the same afternoon:

Alex:  Small thing I'd rather handle directly: in the review, the
       caching design came up as yours. I designed it, you presented
       it, and the room came away with the wrong picture. I don't
       think you did it deliberately, but I'd like it corrected.
       Would you rather fix it in the channel, or should I?

Sam:   Ugh, you're right, that's on me; I said "my design" out of
       habit. I'll post the correction now and cc Dana.

Alex:  Thanks. For the next one: happy to co-present, which also
       solves it structurally.

Annotations: private first, facts stated without a character verdict ("came away with the wrong picture", not "you stole my work"), intent explicitly given its most charitable reading while the correction is still required, and the ask is specific with an either/or that makes correcting easy. The closer converts the incident into a structure ("co-present next time") instead of a grudge.

If it goes sideways: if Sam deflects ("does it really matter?"), the escalation is calm and named in advance, per Chapter 10: "It matters to me, and promotion packets are built from exactly these impressions. If you'd rather not correct it, I'll mention my role to Dana myself; I wanted you to hear that from me first." Documented contribution (Chapter 18's brag doc) makes this conversation factual rather than testimonial.

Scene 3: put on the spot by an executive

A quarterly review. A VP turns to Alex mid-meeting: "Can we have multi-region by March?"

Alex:  I don't want to hand you a bad number in a good meeting. The
       honest answer today is: the storage layer is the long pole,
       and I haven't sized it. I can have a real answer with a
       confidence range by Thursday noon. Directionally: March is
       possible only if we descope failover to read traffic first.

VP:    I'll take Thursday. Send it to me directly.

Annotations: the refusal to improvise a date is framed as protecting the VP ("a bad number in a good meeting"), not as unpreparedness; a concrete delivery time replaces the number; and the "directionally" sentence gives the room something real to plan around without becoming a commitment. This is Chapter 8's executive register plus Chapter 7's estimate-versus-commitment line, under stage lights. The one fatal move here is the reflexive "yeah, March should be fine", which becomes a plan of record before the elevator reaches the lobby.

Scene 4: the harsh review

Alex opens a PR and finds: "This whole approach is wrong. Did you read the architecture doc at all?"

Alex (after a deliberate hour, in the PR):
       There's a real objection in here and I want to engage with it
       properly. Which constraint from the doc does this violate?
       If it's the single-writer rule, section 3 of my description
       explains why this path is exempt; if I've misread that, I
       genuinely want to know.

Reviewer:
       ...it's the single-writer rule, and I hadn't read your
       section 3. The exemption argument mostly holds. My comment
       was harsher than the situation deserved; sorry. One real
       issue remains in the lock ordering.

Alex:  No harm done, and the lock ordering point is right; fixing.

Annotations: the deliberate hour is the whole trick; the first draft of any reply to that comment should never be sent. Alex's actual reply extracts the technical claim from the hostility and answers only that, with genuine openness to being wrong. Refusing to match tone is not submission; it is the move that makes the other person's tone visible to everyone reading, including themselves. Most such exchanges end exactly like this one: partial concession, small apology, one real issue that survives.

If it goes sideways: a reviewer who stays hostile after a clean reply is no longer a wording problem. Move channels (Chapter 6): "We're not converging in text; fifteen minutes on a call?" If the pattern is chronic, that conversation belongs in your 1:1, described with SBI (Chapter 18), not suffered in silence.

Scene 5: the no

Ines asks Alex to "quickly add" an export format her team needs this sprint.

Ines:  It's probably a day of work? It would really unblock us.

Alex:  I believe you that it's important, so let me be straight
       about the cost side. My sprint is committed to the retry cap,
       which is a postmortem action item with a date. A day of your
       feature is a day off that, and I don't get to make that trade
       alone. Two real paths: Dana can reprioritize me if this
       outranks the action item, or I can pair with someone on your
       team for an hour tomorrow so you can build it yourselves;
       the export interface is friendlier than it looks.

Ines:  The pairing option honestly sounds faster than waiting.
       Tomorrow at 10?

Alex:  Booked. And if it turns out gnarlier than an hour, I'll say
       so rather than disappear on you.

Annotations: the no never actually says no; it prices the yes and routes the priority call to its owner (Chapter 10's costed yes), while the pairing offer converts refusal into capability transfer, which is the version of no that builds relationships instead of spending them. The closing promise ("I'll say so rather than disappear") names and forecloses the failure mode that makes people fear asking engineers for anything.

Don't be confused: across all five scenes, keep apology, explanation, and excuse distinct. An apology owns impact ("I'm sorry I was short with you"). An explanation gives mechanism ("I'd been up since 4 with the pager"). An excuse deploys the mechanism to cancel the ownership ("well, I'd been up since 4, so"). The first two combine fine in that order; apology, then mechanism, then repair. The moment the mechanism arrives before the ownership, or instead of it, the listener hears an excuse, and the apology stops working.

The pattern under all five

Strip the scenes to their skeletons and one shape repeats: facts before feelings, options before verdicts, the other person's out prepared in advance. Alex never once argues about being a good engineer, a wronged colleague, or a trustworthy estimator; every conversation is steered onto ground where evidence can settle it. That is the deepest habit this book has to teach, and it is Chapter 16's final checklist item (read it as the recipient) running at the hardest difficulty setting.

👉 That is the end of the situation room and of the playbook. What remains is the References: the books, guides, and standards behind these chapters, each worth your time in full.

References

The sources this book draws on, grouped by what they are best for. Links were checked as live in July 2026.

Chat and everyday etiquette

• no hello, the one-page site behind the no-hello rule in Chapter 1: https://nohello.net. It exists in a dozen languages, and linking it (gently, once) is itself a chat tradition.
• The XY problem, canonical explanation of the asking failure covered in Chapter 3, with the original mailing-list history: https://xyproblem.info
• Eric S. Raymond and Rick Moen, "How To Ask Questions The Smart Way": http://www.catb.org/~esr/faqs/smart-questions.html. The classic text on well-formed technical questions; abrasive by modern standards, but foundational.

Code review

• Google Engineering Practices, Code Review Developer Guide: https://google.github.io/eng-practices/review/. Covers both halves of the review relationship (reviewer and author), including the standard-of-approval philosophy behind "LGTM".
• Conventional Comments: https://conventionalcomments.org. The label taxonomy (praise, nitpick, suggestion, issue, question, thought, chore) that Chapter 6's severity table is based on.

Disagreement, feedback, and difficult conversations

• Kim Scott, Radical Candor (2017; revised 2019). The care-personally, challenge-directly framing that underlies "soften the person, sharpen the substance".
• Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler, Crucial Conversations (2002; 3rd ed. 2021). The standard text on high-stakes disagreement mechanics: safety, shared goals, and returning to facts.
• Marshall Rosenberg, Nonviolent Communication (1999; 3rd ed. 2015). Source of the observation-versus-evaluation distinction ("adjectives are verdicts") used throughout Chapter 5.
• Erin Meyer, The Culture Map (2014). The field guide to how directness, criticism, and disagreement norms vary across countries; essential reading for international teams.
• Amazon leadership principles: https://www.amazon.jobs/content/en/our-workplace/leadership-principles. Origin of "disagree and commit" as an operating rule and of the one-way/two-way door decision framing (the latter articulated in Jeff Bezos's 2015 shareholder letter).

Incidents, blamelessness, and operations language

• Google SRE Book, chapter 15, "Postmortem Culture: Learning from Failure": https://sre.google/sre-book/postmortem-culture/. The canonical statement of blameless postmortems behind the retro and incident language in Chapters 7 and 10.
• John Allspaw, "Blameless PostMortems and a Just Culture" (Etsy, 2012): https://www.etsy.com/codeascraft/blameless-postmortems/. The blog post that popularized the practice in industry.
• Atlassian incident communication guide and templates: https://www.atlassian.com/incident-management/incident-communication. Worked examples of the investigating/identified/mitigated/resolved state machine.

Writing craft

• William Zinsser, On Writing Well (1976; 30th-anniversary ed. 2006). The single best book on plain professional prose; the de-inflation stance of Chapter 13 ("use" over "utilize") is pure Zinsser.
• William Strunk Jr. and E. B. White, The Elements of Style (1959; 4th ed. 1999). Dated in places, still the fastest vaccination against clutter.
• BLUF (bottom line up front), background on the military-origin structure adopted throughout this book: https://en.wikipedia.org/wiki/BLUF_(communication)
• The PREP method (Point, Reason, Example, Point) from Chapter 16 is widely documented in public-speaking training, for example Toastmasters materials.

Careers, feedback, and the written record

• Chris Beams, "How to Write a Git Commit Message": https://cbea.ms/git-commit/. The seven rules (imperative subject, 50/72 wrapping, body explains why) behind Chapter 17's commit section.
• Conventional Commits v1.0.0: https://www.conventionalcommits.org/en/v1.0.0/. The feat:/fix: prefix specification.
• PagerDuty postmortem guide: https://postmortems.pagerduty.com. Worked templates and role definitions behind Chapters 17 and 22, including the incident commander role.
• Camille Fournier, The Manager's Path (2017). The standard map of 1:1s, feedback, and career ladders from both sides of the table; background for Chapter 18.
• The Situation-Behavior-Impact (SBI) feedback model, developed by the Center for Creative Leadership; the structure used in Chapter 18.
• The STAR method (Situation, Task, Action, Result) is widely documented in interviewing and performance-review guidance; used in Chapter 18.

Dialect and global Englishes

• Braj Kachru's work on World Englishes, and the Oxford English Dictionary entries for "prepone" and question-sense "doubt". Background for Chapter 16's position that these are dialect features rather than errors; the chapter's advice is about audience mapping, not correctness.

Terms of art

• Parkinson's law of triviality, the 1957 bike-shed committee story behind "bikeshedding": https://en.wikipedia.org/wiki/Law_of_triviality
• "Yak shaving", the MIT AI Lab etymology: https://en.wiktionary.org/wiki/yak_shaving
• Architecture decision records, templates and background for the ADRs mentioned in Chapter 4: https://adr.github.io