Stakeholder Communication Rampstackco Claude Skills

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

- [`references/update-templates.md`](references/update-templates.md): Ready-to-use templates for the most common stakeholder communications, with annotated examples.