--- name: rampstackco/stakeholder-communication source: https://app.decimal.ai/s/rampstackco-stakeholder-communication@1/SKILL.md source_sha256: 83e7b12ed3f9 --- # 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.