stakeholder-communication（利益相关者沟通）

Stakeholder Communication Skill

A framework for adapting technical communication to different audiences, ensuring your message lands effectively whether speaking with engineers, product managers, executives, or customers.

When to Use This Skill

• Presenting technical decisions to non-technical stakeholders
• Writing status updates for different audience levels
• Translating complex technical concepts for business partners
• Building alignment across engineering, product, and business teams
• Communicating with executives (brevity, business impact)
• Customer-facing technical communication
• Cross-functional project coordination

Core Framework: Audience-First Communication

The Fundamental Question

Before any communication, ask: "Who is my audience and what do they need?"

Different stakeholders have different:

• Knowledge levels: Technical depth they can absorb
• Decision criteria: What matters for their decisions
• Time constraints: How much attention they can give
• Action orientation: What they need to do with this information

The Four Audience Types

Quick Adaptation Guide

For Engineers

Focus on:

• Technical architecture and design decisions
• Implementation approach and trade-offs
• Code quality, testing, and reliability
• Performance characteristics and constraints

Avoid:

• Over-simplified explanations (they'll feel condescended to)
• Hiding technical debt or known issues
• Vague timelines without technical justification

For Product Managers

Focus on:

• Feature capabilities and limitations
• Timeline and scope trade-offs
• User impact and experience changes
• Dependencies and risks to roadmap

Avoid:

• Deep implementation details (unless relevant to decisions)
• Technical jargon without context
• Binary answers when trade-offs exist

For Executives

Focus on:

• Business impact (revenue, cost, risk)
• Decision points requiring their input
• Progress against strategic objectives
• Resource implications

Avoid:

• Technical details (unless specifically asked)
• Problems without proposed solutions
• Lengthy explanations (get to the point)

For Customers

Focus on:

• Benefits and value they receive
• Reliability and trust signals
• Clear, jargon-free explanations
• What they need to do (if anything)

Avoid:

• Internal technical details
• Blame or excuses
• Uncertainty without reassurance

The Translation Principle

Technical → Business Translation:

The Formula:

[Technical action] → [Business benefit] + [Risk if not done]

Example:

• Technical: "We need to upgrade from.NET 6 to.NET 8"
• Business: "Upgrading our framework ensures continued security support and enables 20% faster response times, avoiding security vulnerabilities when.NET 6 support ends in November"

Communication Patterns

The Executive Summary Pattern

For any executive communication:

1. Bottom Line Up Front (BLUF): Lead with the conclusion or ask
2. Context: Minimal background needed to understand
3. Options/Recommendation: What you suggest and why
4. Ask: What you need from them

Template:

**Summary:** [One sentence: what this is about and what you need]

**Context:** [2-3 sentences: why this matters now]

**Recommendation:** [What you propose]

**Ask:** [Specific decision or action needed]

**Details:** [Available if they want to dig deeper]

The Cross-Functional Update Pattern

For status updates that go to mixed audiences:

1. Progress: What's done (accomplishments, metrics)
2. Plans: What's next (upcoming work, timeline)
3. Problems: What's blocking (issues, risks, needs)

Template:

## [Project Name] Update - [Date]

### Progress
- [Accomplishment with metric or outcome]
- [Accomplishment with metric or outcome]

### Plans
- [Upcoming work] - [Target date]
- [Upcoming work] - [Target date]

### Problems
- [Issue]: [Impact] - [Proposed solution or ask]

The Technical Decision Pattern

For communicating technical decisions to non-technical stakeholders:

1. Decision: What we decided
2. Why: Business rationale (not technical details)
3. Impact: What changes for them
4. Timeline: When it happens

Template:

**Decision:** We're [decision].

**Why:** This [business benefit] and [risk mitigation].

**Impact:** [What they'll see/experience differently].

**Timeline:** [When this takes effect].

Common Mistakes

Mistake 1: Same Message to All Audiences

Problem: Sending identical communication to engineers and executives.

Fix: Create layered communication:

• Executive summary for leadership
• Detailed version for technical teams
• Customer-facing version if applicable

Mistake 2: Leading with Technical Details

Problem: Starting with how something works before why it matters.

Fix: Always lead with business impact, then offer technical details for those who want them.

Mistake 3: Assuming Shared Context

Problem: Using acronyms, project names, or references others don't know.

Fix: Define terms, provide context, link to background information.

Mistake 4: All Problems, No Solutions

Problem: Escalating issues without proposed solutions.

Fix: Always bring options. "We have a problem" → "We have a problem. I recommend X because Y."

Mistake 5: Binary Answers to Complex Questions

Problem: "Yes we can" or "No we can't" without nuance.

Fix: "Yes, with these trade-offs" or "Not as asked, but here's what we could do."

References (Load When Needed)

Detailed Frameworks

• Audience Adaptation Matrix: Complete communication tactics by audience type
• Technical Translation: Simplifying jargon for non-technical audiences
• Executive Communication: Business impact framing and brevity techniques
• Cross-Functional Alignment: Building shared understanding across teams

Related Skills and Commands

• professional-communication skill - General communication patterns
• difficult-conversations skill - Challenging stakeholder discussions
• /soft-skills:stakeholder-communication skill - Transform content for audience

Example Scenarios

Scenario 1: Explaining a Delay to Executives

**Situation:** Feature launch delayed 2 weeks due to unexpected technical complexity.

**Bad:** "The API integration is taking longer because the third-party
documentation was incorrect and we had to reverse-engineer their
authentication flow, plus we discovered race conditions in our queue
processing that required refactoring."

**Good:** "Launch is moving to [date] - 2 weeks later than planned.
The integration was more complex than estimated based on available
documentation. We've de-risked the remaining work and are confident
in the new date. Impact: [business impact]. No action needed from you
unless you have questions."

Scenario 2: Technical Update for Mixed Audience

**Situation:** Database migration completed successfully.

**For Engineers:**
"Migration complete. 2.3M records transferred with zero data loss.
Rollback scripts tested and available. New indexes improving query
performance by 40% on high-traffic endpoints. Monitoring dashboard
updated. On-call runbook in wiki."

**For Executives:**
"Database upgrade complete. System is faster and more reliable.
No customer impact during transition. Cost savings of $X/month
from improved efficiency."

**For Customers (if applicable):**
"We've upgraded our systems to serve you better. You may notice
faster load times. No action needed on your end."

Scenario 3: Requesting Resources

**Situation:** Need additional engineer for critical project.

**Bad:** "We're behind and need help."

**Good:** "Request: 1 additional engineer for [project] through [date].

Why: Current velocity puts us 3 weeks behind [strategic goal].
Adding capacity now enables on-time delivery.

Impact of not acting: [Specific business consequence].

Recommendation: Temporarily reassign [name] from [lower-priority work].

Cost: [Lower-priority work] delayed by [X weeks].

Ask: Approve reassignment by [date] to maintain timeline."

Anti-Patterns to Avoid

In Written Communication

• Wall of text: Break into scannable sections
• Buried lead: Put the key point first
• Jargon soup: Define terms or use plain language
• Missing ask: Be clear about what you need

In Verbal Communication

• Monologuing: Pause for questions and reactions
• Defensive posture: Be open to feedback
• Over-explaining: Match depth to audience interest
• Vague commitments: Be specific about next steps

Success Metrics

Effective stakeholder communication achieves:

• Understanding: They grasp what you're saying
• Alignment: They agree on direction or know how to disagree
• Action: They can take appropriate next steps
• Trust: They feel informed and respected
• Efficiency: Neither party's time was wasted

User-Facing Interface

When invoked directly by the user, this skill adapts technical content for a specific audience.

Execution Workflow

1. Parse Arguments - Extract the technical content and target audience from $ARGUMENTS. Format: <technical content> for <audience>. If incomplete, ask what content to adapt and for whom.
2. Identify Audience Type - Classify the target audience (engineers, product managers, executives, customers, or mixed).
3. Analyze Technical Content - Identify jargon, technical details, acronyms, and implementation specifics that need translation.
4. Apply Translation Principle - Transform technical language into audience-appropriate communication using the formula: [Technical action] -> [Business benefit] + [Risk if not done].
5. Generate Adapted Output - Produce the rewritten content with appropriate depth, framing, and action orientation for the target audience.
6. Suggest Communication Pattern - Recommend the appropriate format (Executive Summary, Cross-Functional Update, Technical Decision pattern) based on content type.

Version History

• v1.0.0 (2025-12-23): Initial release with audience-first framework