stakeholder-communication

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 incident-response)
• Internal documentation that isn't time-sensitive (use documentation-strategy)
• 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-fr