Stakeholder Communication
Get the right information to the right people at the right time, in a form they can act on. Stack-agnostic. Applies to any team operating with cross-functional stakeholders.
When to use
- Writing weekly or monthly status updates
- Preparing for an executive review or board update
- Sharing a technical decision with a non-technical audience
- Communicating a delay, miss, or quality problem
- Asking for help, resources, or decisions
- Managing up to a manager or sponsor
- Designing the communication cadence for a project
- Drafting an internal announcement
When NOT to use
- Customer-facing communication (use marketing/support skills)
- Public comms or press (different framework, different stakes)
- Incident communication during an active incident (use )
- Internal documentation that isn't time-sensitive (use )
- Specific delivery formats (slide deck design, email tone) - this skill is about content and structure
Required inputs
- The audience (who specifically, what's their context, what do they care about)
- The purpose (inform, decide, escalate, ask, celebrate)
- The substance (what's actually happening)
- The medium (email, doc, meeting, slide, chat)
- Time constraints (when do they need this)
The framework: 5 questions
Before any stakeholder communication, answer:
Question 1: Who is the audience?
Specifically. "Leadership" is too vague. The CFO and the VP of Engineering have different concerns.
For each named audience:
- What do they care about? (revenue, risk, quality, velocity, costs, customers)
- What do they already know? (background you can skip)
- What's their level of detail tolerance? (executives want headlines; ICs want details)
- What action do you want from them? (acknowledgment, decision, help, no action)
Question 2: What's the headline?
If they read only one sentence, what should they take away?
The headline goes first. Always. The narrative supports it; the data confirms it.
This is the biggest gap in most stakeholder communication: people start with context and build to a conclusion. Stakeholders want the conclusion first.
Question 3: What's the so-what?
Stakeholders ask "and?" implicitly. Answer it explicitly.
- "We hit 80% of the milestone." → so what?
- "We hit 80% of the milestone, which puts the launch one week behind plan." → that's the so-what.
The so-what makes the information actionable.
Question 4: What do you want?
Communications generally have one of these requests:
- Inform: no action needed. Just keeping them in the loop.
- Decide: a decision is needed; here are the options and recommendation.
- Escalate: something is stuck; we need help.
- Ask: a specific request (resource, introduction, review).
- Celebrate: a win to share; no action needed but morale matters.
State which. Don't bury the request.
Question 5: What format?
- Async written (doc, email): rich content, decision trail, easy to reference
- Sync written (chat, ticket comment): quick exchange, conversational
- Sync spoken (meeting, call): nuance, debate, alignment
- Mixed (doc + meeting): the doc is read in advance; meeting is decision
For most updates: async written. Save sync time for actual discussion.
The structure: the inverted pyramid
Stakeholder communication reads like a news article, not an essay.
Headline (one sentence)
The "so what" and the request (one paragraph)
Status / progress (the body)
Risks and asks (what we need)
Detail / appendix (what curious readers want)
Cut from the bottom. If your update gets shortened, the top survives.
Update templates
Weekly project update
**Project:** [Name]
**Status:** [On track / At risk / Off track]
**Headline:** [One-sentence summary]
**This week:**
- [Specific accomplishment]
- [Specific accomplishment]
- [Specific accomplishment]
**Next week:**
- [Specific plan]
- [Specific plan]
**Risks / blockers:**
- [Risk + what we're doing about it / what we need]
**Metrics:**
- [Metric: value vs target]
- [Metric: value vs target]
The status indicator (on track / at risk / off track) is essential. Stakeholders scan for it.
Executive review
**Headline:** [The summary, one sentence]
**Key points:**
1. [Point with one supporting sentence]
2. [Point with one supporting sentence]
3. [Point with one supporting sentence]
**Decisions needed:**
- [Decision A: options and recommendation]
- [Decision B: options and recommendation]
**Asks:**
- [Specific request]
**Detail:** [Linked doc or appendix]
Executives skim. They click into detail when interested.
Bad news
The hardest update to write well.
**Headline:** [The bad news, plainly stated]
**What happened:**
[Specific facts, no euphemisms]
**Impact:**
[Who's affected, how much, by when]
**What we're doing:**
[Specific actions and owners]
**What we need:**
[Specific asks, if any]
**Timeline:**
[When the next update will land]
Don't soften the headline. Soft headlines on bad news erode trust faster than the news itself.
Decision request
**Decision:** [What needs to be decided]
**Context:** [The minimum needed to understand]
**Options:**
1. [Option A: description, pros, cons]
2. [Option B: description, pros, cons]
3. [Option C: description, pros, cons]
**Recommendation:** [Option X, because...]
**Need by:** [Date]
**Decision rights:** [Who decides]
Recommendation matters. Not making one is putting the work back on the decider.
Tone and register
Across audiences
| Audience | Tone | Detail | Length |
|---|
| Direct manager | Candid, briefer | Mid | Medium |
| Skip-level / VP | Polished, sharper | Low | Short |
| Cross-functional peer | Collaborative, specific | Mid-high | Medium |
| Executive / board | Headlines, confident | Low (with detail available) | Short |
| Team / IC stakeholders | Detailed, direct | High | Long |
What to avoid
- Hedging when confident. "I think maybe we might be able to..." Just say what you mean.
- Confidence when uncertain. "Definitely launching Friday" when there's risk. Calibrate.
- Jargon for non-technical audiences. Replace with plain language.
- Burying the lede. Headline first.
- Implicit asks. State explicitly what you want.
- Status updates that are 90% activity, 10% outcome. Focus on outcomes; activity is supporting evidence.
Workflow
Step 1: Define the audience and purpose
Before writing, answer Q1-Q5 above. Often this clarifies the message before any drafting.
Step 2: Draft the headline
One sentence. The takeaway. If you can't write the headline, you don't know yet what you're communicating.
Step 3: Write inverted pyramid
Headline, so-what, body, asks, detail.
Step 4: Cut
A first draft is usually 30-50% too long.
- Cut activities that don't have outcomes
- Cut adjectives (great, awesome, excellent, exciting)
- Cut filler (just, really, very, actually)
- Cut hedging (kind of, sort of, somewhat) when confident
- Cut sentences that don't add information
Step 5: Verify the request
Reread. Is the ask clear? Is it specific? Is the deadline named?
Step 6: Check the audience
Imagine the recipient reading. Will they understand the headline? Have you skipped context they need? Have you given context they don't need?
Step 7: Send and follow up
After sending:
- Did the right people see it? Acknowledge the right channel.
- Did they understand? Watch for confused replies; address them.
- Did they act? Follow up on stale asks.
Cadence design
Different audiences need different cadences.
High-frequency (weekly or more)
- Direct team, manager, sponsor
- Active project stakeholders
- People making day-to-day decisions
Medium-frequency (biweekly to monthly)
- Skip-level
- Cross-functional partners
- Adjacent teams
- Strategic stakeholders
Low-frequency (quarterly)
- Executive review
- Board update
- Wider organization
- External stakeholders (where relevant)
The right cadence is what's needed, not what fills the calendar. Update people when there's something new; don't manufacture updates.
Failure patterns
Long preamble before the point. Three paragraphs of context, then the one sentence that mattered. Lead with the point.
Status: yellow. Same status three weeks in a row. Yellow with no change is red. Be honest about progress.
Update without a clear ask. "We're working on it." OK, what do you want? If nothing, say "no action needed."
Sandwiching bad news in good news. "We've done X and Y, and unfortunately Z is delayed, but we've also done W." The bad news gets lost. Lead with it if it's the headline.
Walls of text. Too long, unread. Cut to the structure.
Activity vs outcome. "Met with team. Reviewed plan. Updated tickets." So what? "Cut scope to hit launch date" is an outcome.
Different update for every audience. Maintaining 5 versions doubles work. Have one core update; tailor the framing.
Status update that's actually a request. Buries an ask in a wall of status. Pull the ask out. Make it visible.
Optimistic projections. "We'll be back on track next week." Then we're not. Then again. Trust erodes. Be honest about the path.
No follow-up on asks. Asked for a decision; didn't get one; moved on. Now the project is stuck. Follow up.
Communicating bad news only when forced to. Stakeholders find out from someone else, or from a missed deadline. Lose trust. Communicate proactively.
Performative comms for the audience of one. Every update reads like a sales pitch to the boss. Stakeholders see through it. Be direct.
No comms when no news. Silence is worse than "no change this week." Set expectations on cadence and stick to it.
Output format
A communication plan for a project includes:
- Stakeholder map: named people, their interests, their decision rights
- Cadence: what updates go to whom, how often
- Templates: standardized formats for repeated updates
- Escalation paths: who to involve when something's at risk
- Decision log: running record of decisions made, by whom, why
For individual communications:
- Headline: the takeaway
- Body: the supporting structure
- Ask: the request, explicitly
- Distribution: who gets it, in what form
Reference files
references/update-templates.md