Stakeholder Communication

Key Points

Translation is the senior's force multiplier. Tech ↔ business fluency unlocks roadmap, budget, and trust.
Lead with the answer (BLUF). Executives and PMs read the first sentence and skim the rest.
Pyramid Principle (Minto): conclusion → supporting arguments → evidence. Reverse of how engineers naturally write.
A good RFC is short, opinionated, and lists what you rejected. Length is not effort.
Status updates answer "should I worry?" — not "what did the team do this week?"
Disagree without being a jerk. "I see it differently — here's why" beats "this is wrong" every time.
Listening is a senior skill. The loudest engineer is rarely the most senior.

Concepts (deep dive)

Why this matters at staff/senior level

The further you climb, the less your impact comes from code and the more it comes from influencing decisions you don't directly own. PMs, EMs, designers, security, finance, customers — your job is to make their decisions better with technical truth they can actually use.

The mistake junior-staff engineers make: assuming "the work speaks for itself". It doesn't. Communication is the work.

Frameworks that scale

BLUF — Bottom Line Up Front

Military comms doctrine. First sentence = the conclusion or the ask.

❌ "We've been investigating the latency issue for the last sprint, looking at traces, profiling, examining the database, and there are several factors that could contribute…"

✅ "p99 latency is up 40% because of the new audit log. Recommend rolling back today; root fix in 3 days. Details below."

Pyramid Principle (Barbara Minto)

              [Answer / Recommendation]
              /         |          \
        [Reason 1]  [Reason 2]  [Reason 3]
         /  \         /  \         /  \
      [evidence] [evidence] [evidence] [evidence]

Engineers write bottom-up (evidence → conclusion). Executives read top-down. Invert your draft before sending.

STAR for postmortems / readouts to non-eng

Situation: what was happening
Task: what we needed to do
Action: what we did
Result: outcome + lesson

Crisp narrative arc that non-engineers can follow without translation.

Writing RFCs / design docs that survive review

Opinionated structure (steal it):

# RFC-NN: <title>
**Author:** ...   **Status:** Draft | In Review | Accepted | Rejected
**One-line summary:** <the BLUF>

## Context
Why are we even talking about this? Constraints, prior art, ADRs.

## Problem
Specific, measurable. "Latency p99 > 800ms" not "it's slow".

## Options Considered
### Option A: <name>
Pros / Cons / Cost / Risk

### Option B: ...

### Option C: Do nothing
(Always include.)

## Recommendation
Option B because <reason>. Trade-offs we accept: <list>.

## Open Questions
What we don't know yet. Who decides.

What NOT to include: - ❌ Implementation minutiae (save for the ticket). - ❌ Marketing language ("best-in-class"). - ❌ A pre-decided answer dressed as analysis (reviewers smell it). - ❌ More than ~5 pages. If you need more, the doc is two RFCs.

Status updates

PMs and EMs reading your weekly status want, in order: 1. Are we on track? (green / yellow / red) 2. What's blocked, who can unblock it? 3. What changed since last week that affects scope, date, or risk.

What engineers want to write (and shouldn't): - ❌ Detailed enumeration of PRs merged. - ❌ Internal architecture wins with no business framing. - ❌ "Worked on X, then Y, then Z" — verb soup.

Template:

**Status:** 🟢 On track / 🟡 At risk / 🔴 Off track
**Date risk:** Ship date holds / +1 week / TBD
**Headline:** <one sentence; the BLUF>
**Wins:** 2-3 bullets, business-framed
**Risks / asks:** what you need; from whom; by when
**Detail (optional):** for those who care

Escalation

When to escalate: decision is blocked > 48h, or risk you can't own.
How: name the decision, the deadline, and the options. Not "help".
Who: the person who can actually decide. Not your skip-level by default.
The loop: know your named escalation path (tech lead → EM → director → VP). Pre-walked, not invented mid-incident.

Leading design reviews

Scope upfront: "We're deciding X today; Y is out of scope."
Time-box options. Five minutes per option max; people will keep talking.
Capture the decision in the room. "So we're going with B; objections?" Then write it down before anyone leaves.
Park rabbit holes explicitly: "good question — parking lot, follow up async."
Send the decision and rationale within 24h as an ADR or summary doc.

Tactical: explain it like I'm a PM

Analogies that work: - ✅ Database connection pool → restaurant tables (limited; reservations). - ✅ Eventual consistency → bank transfer that posts later that day. - ✅ Tech debt interest → minimum credit card payments. - ✅ Rate limiting → a bouncer at the door.

Analogies that don't: - ❌ Other tech things ("it's like Kafka but…"). - ❌ Strained metaphors that need their own explanation. - ❌ Anything that requires "well actually".

Difficult conversations

When you think someone's idea is bad:

❌ "That won't work." ❌ "Have you considered that this is wrong?"

✅ "I see it differently — what I'm worried about is X. Want to walk through it?" ✅ "Help me understand the assumption around Y. If Y holds, this works; if not, we'd hit Z."

The frame is collaborative truth-seeking, not winning. People defend ideas attached to their identity; attack the idea, leave the identity alone.

Listening

Restate before responding. "What I'm hearing is X — is that right?" Catches half the misunderstandings before they happen.
Wait three seconds after someone finishes. Most people fill silence with the thing they were actually worried about.
The quietest person in the room often has the sharpest objection. Make space.

Patterns

BLUF memo — Intent: lead every written comm (Slack, email, doc) with the conclusion. Skim-resilient.
Pyramid restructure — Intent: drafted bottom-up (engineering brain), shipped top-down (executive brain). Invert before sending.
Decision doc + async review — Intent: circulate RFC 48h before the meeting; meeting decides only the open questions. Saves hours of read-aloud.
Pre-mortem before the work — Intent: "imagine this fails — why?" with stakeholders before kickoff. Surfaces hidden risks while they're cheap.
Two-track narrative — Intent: technical detail in the appendix; business framing in the body. Same doc serves both audiences.

Pros & cons / trade-offs

Approach	Pros	Cons
Async-first (docs, email)	Scales, archived, time-zone friendly	Slower decisions, easy to ignore
Sync (meetings, calls)	Fast resolution, builds trust	Doesn't scale, no record
BLUF / Pyramid	Respects reader's time	Feels abrupt to engineers
Long detailed docs	Comprehensive	Nobody reads past page 2
Strong-opinion RFCs	Drives decisions	Risk of being seen as inflexible

When to use / when to avoid

✅ Async (doc + comments) for design decisions, RFCs, status, anything reviewable. ✅ Sync for incidents, sensitive feedback, brand-new relationships, decisions stuck > 24h async. ✅ BLUF always — there is no audience for which "context first" beats "answer first".

❌ Avoid Slack for decisions that need to outlive the week — it's a chat log, not a record. ❌ Avoid meetings to "align" with no agenda or decision — that's a status email. ❌ Avoid emojis-as-tone in serious comms with execs or external stakeholders.

Senior-level tips

💡 Write the email you wish you'd received. Three sentences. Action item. Deadline.
💡 Name the decision-maker explicitly in any escalation. "@Alex, can you decide by Friday?" — ambiguity is the enemy.
💡 Translate eng-speak in real time in cross-functional meetings. "When Bob says 'idempotent' he means 'safe to retry'." Builds trust on both sides.
💡 Bring options, not problems. "X is broken; here are 3 fixes with costs" >> "X is broken, what should we do?"
💡 Praise in public, critique in private. Universal but underused.
💡 Repeat the decision 3 times across 3 channels. People miss things; that's not their fault.
💡 Have a "things-I'm-worried-about" doc you share with your manager. Pre-empts surprise.
💡 Apologize cleanly when wrong. "I was wrong about X; here's the corrected view." Builds more credibility than being right the first time.

Common pitfalls

⚠️ Burying the ask under context — execs stop reading.
⚠️ Jargon as gatekeeping — "idempotent retry semantics" to a PM is hostile, not precise.
⚠️ Status as activity log instead of risk signal.
⚠️ Disagreeing in a public channel when DM would do.
⚠️ Writing 8-page RFCs that nobody reviews; ship a 2-pager and iterate.
⚠️ Treating PMs as the enemy. They're trying to do their job; help them.
⚠️ Saying "yes" when you mean "yes if X, Y, Z" — sets up future blame.
⚠️ Dropping bad news on Friday afternoon. Tuesday morning, with options.