git:20260505.c80b896 to git:20260507.ac2b078

---

name: stakeholder-communication

description: "Communicate effectively with stakeholders across functions and seniority levels. Use this skill when writing status updates, preparing executive reviews, sharing technical decisions with non-technical audiences, managing up, communicating bad news, or designing the communication cadence for a project. Triggers on stakeholder update, status report, executive summary, exec review, manage up, communicate bad news, project comms, status meeting, weekly update. Also triggers when a project is going off track and the team needs to communicate it."

category: process-and-team

catalog_summary: "Status updates, exec readouts, project communications"

display_order: 1

---

# 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-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