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:
| Audience | What they need from you |
|---|---|
| Engineers | Mechanism: what broke, why, how it's fixed |
| Product | Impact and options: what users feel, what it costs to fix, what it displaces |
| Executives | Risk and dates: is the commitment safe, what decision is needed |
| Support | Symptoms and script: what users will report, what to tell them |
| Customers | Effect and remedy: what happened to them, what we did, what changes |
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:
| You say internally | Say across the aisle |
|---|---|
| "We need to refactor this module" | "This area has gotten expensive to change; a week of cleanup makes the next three features faster and safer" |
| "That's tech debt" | "That's a shortcut we took deliberately; here is the interest we're paying on it per sprint" |
| "We need a spike first" | "There's an unknown that could swing the estimate 3x; two days of investigation buys a real number" |
| "The tests are flaky" | "Our safety net has holes; until it's fixed, releases carry more risk than they appear to" |
| "That's a breaking change" | "Shipping this forces every integration to do work; we owe them notice and a migration path" |
| "It depends" | "Between two and six weeks. The swing is the vendor API; I'll know which end by Friday" |
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.