zhongwei/gh-lyndonkl-claude
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:38:26 +08:00
commit 41d9f6b189
304 changed files with 98322 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

168
skills/role-switch/resources/evaluators/rubric_role_switch.json Normal file
View File

@@ -0,0 +1,168 @@
{
"name": "Role Switch Evaluator",
"description": "Evaluates role-switch analyses for perspective quality, tension surfacing, synthesis realism, and actionability in multi-stakeholder decision contexts",
"criteria": [
{
"name": "Decision Framing Clarity",
"weight": 1.3,
"scale": {
"1": "Vague decision ('improve things', 'align stakeholders') with no constraints, stakes unclear",
"2": "Decision stated but constraints missing (no timeline/budget/scope), why alignment matters not articulated",
"3": "Decision clear with some constraints stated, stakes mentioned but impact not quantified",
"4": "Specific decision with clear constraints (time, budget, scope), stakes articulated with consequences",
"5": "Exemplary: Precise, bounded decision (not open-ended), all constraints explicit (timeline, budget, scope, quality bars), stakes quantified (what happens if wrong, why alignment critical), current state and success criteria defined"
}
},
{
"name": "Role Selection Relevance",
"weight": 1.4,
"scale": {
"1": "Roles missing (< 3) or redundant (5 roles with similar perspectives), no rationale for selection",
"2": "3-4 roles selected but lack diversity (all internal or all same function), missing key stakeholders with veto power",
"3": "3-5 roles with some diversity (eng + PM + user) but missing critical perspectives (e.g., legal for compliance decision), rationale brief",
"4": "3-6 roles with clear diversity (different goals, incentives, constraints), key stakeholders included, rationale for inclusion stated",
"5": "Exemplary: 3-6 roles selected for maximum perspective diversity (internal + external, different goals/incentives/time horizons/constraints), decision authority and veto holders identified (RACI or power-interest mapping), rationale for inclusion/exclusion explicit, covers critical perspectives without overloading"
}
},
{
"name": "Perspective Depth & Authenticity",
"weight": 1.5,
"scale": {
"1": "Shallow stereotypes ('finance wants to cut costs', 'eng wants perfect code'), no specific metrics or fears",
"2": "Generic perspectives with broad goals ('sales wants revenue') but no specific metrics, fears, or constraints articulated",
"3": "Roles have specific goals and some fears stated, but position vs interest not distinguished, steel-manning weak",
"4": "Each role has clear mandate, specific success metrics, genuine fears, constraints, position vs interest distinguished",
"5": "Exemplary: Perspectives charitably inhabited (steel-manned, not strawman), specific metrics/KPIs stated (e.g., 'quota is $2M/qtr'), genuine fears articulated (not caricature), constraints explicit (headcount, budget, process, political), position vs interest clearly distinguished (surface demand vs underlying need), what they optimize for and what they'd trade off, incentive structure understood"
}
},
{
"name": "Tension & Tradeoff Identification",
"weight": 1.5,
"scale": {
"1": "No tensions surfaced (pretends everyone agrees) or conflicts vague ('some disagreement'), no tradeoffs stated",
"2": "Conflicts mentioned but not analyzed (e.g., 'speed vs quality') without specifics on upside/downside of each option",
"3": "Tensions identified with general tradeoffs (e.g., 'fast = bugs, slow = quality') but not quantified, who wins/loses not stated",
"4": "Clear tensions mapped with explicit tradeoffs (upside/downside for each option), incompatible goals articulated, who wins/loses identified",
"5": "Exemplary: Tensions explicitly named (not glossed over), common ground identified (shared goals, mutual fears) before conflicts, tradeoffs articulated with concrete upside/downside for each option (e.g., 'launch in 2 weeks = hit market but 20% bug rate', 'delay 4 weeks = miss competitor but strong quality'), who wins/loses for each option, nature of conflict clear (sequential bottleneck, resource allocation, incompatible goals)"
}
},
{
"name": "Synthesis Realism & Quality",
"weight": 1.5,
"scale": {
"1": "No synthesis ('need to align') or wishful thinking ('everyone compromises'), no concrete proposal",
"2": "Vague synthesis ('find middle ground', 'balance priorities') without specific resolution or actionable path",
"3": "Proposal stated but doesn't address key interests, forced consensus (ignores legitimate conflicts), tradeoffs not acknowledged",
"4": "Concrete proposal addressing core interests (not just positions), tradeoffs explicitly accepted, risk mitigation for key fears",
"5": "Exemplary: Synthesis is concrete and actionable (not 'find balance'), addresses interests not positions (goes beneath surface demands), how it satisfies each role's core need stated explicitly, tradeoffs acknowledged (who bears cost), sequencing if relevant (do X first, then Y), risk mitigation for top fears, realistic (not forced consensus when power dynamics say otherwise), hybrid/creative options explored (sequential decisions, pilot/experiment, constraints as forcing function)"
}
},
{
"name": "Power Dynamics & Decision Authority",
"weight": 1.3,
"scale": {
"1": "Power dynamics ignored (pretends all roles equal), decision authority unclear, no escalation path",
"2": "Decision authority mentioned but veto holders not identified, hierarchy not acknowledged, escalation path missing",
"3": "Decision owner stated, some acknowledgment of power (e.g., 'CEO has final say') but veto holders and influence not mapped",
"4": "Decision authority clear (who has final call), veto holders identified (legal, security, finance), escalation path defined",
"5": "Exemplary: Decision authority explicit (RACI or decision rights framework), veto holders identified and addressed first (legal/security/regulatory cannot be overridden by consensus), power-interest mapping or influence mapping (who influences whom), hierarchy acknowledged (manager prerogative vs peer conflict), escalation path defined (3 levels if consensus fails), synthesis respects power dynamics (doesn't assume consensus when autocratic/consultative decision)"
}
},
{
"name": "Actionability & Accountability",
"weight": 1.2,
"scale": {
"1": "No next steps, no owners assigned, no timeline, no success metrics",
"2": "Vague next steps ('socialize proposal', 'gather feedback') with no owners or deadlines",
"3": "Some next steps with owners but no deadlines, success metrics missing or vague ('make stakeholders happy')",
"4": "Clear next steps with owners and deadlines, success metrics stated, decision owner and execution owner assigned",
"5": "Exemplary: Concrete next steps with owners and deadlines (e.g., 'PM drafts spec - Alice - 2 weeks'), decision owner (final call) and execution owner (drives implementation) assigned, stakeholder communication plan (who updates whom, cadence), success metrics defined (how we know it's working), review timeline (when to reassess), escalation path if implementation stalls"
}
},
{
"name": "Multi-Stakeholder Facilitation Readiness",
"weight": 1.1,
"scale": {
"1": "Analysis would not prepare you for stakeholder conversations (perspectives shallow, synthesis unrealistic)",
"2": "Some useful insights but missing key perspectives or synthesis weak, would need significant rework before presenting",
"3": "Analysis covers main perspectives and proposes path forward, but steel-manning weak or power dynamics ignored",
"4": "Analysis prepares well for conversations (perspectives understood, synthesis concrete), minor gaps (e.g., some interests could be deeper)",
"5": "Exemplary: Analysis demonstrates deep stakeholder understanding (could present each role's perspective to them and they'd feel heard), synthesis would be credible starting point for alignment meeting, steel-manning strong (strongest version of each viewpoint), pre-work for facilitation clear (what to socialize 1:1 before group meeting), handles impasse scenarios (what if consensus fails), ready to present without major revision"
}
}
],
"guidance": {
"by_decision_type": {
"product_decisions": {
"key_roles": "Engineering (feasibility), Product (value), Design (UX), Users (actual need), Sales (customer asks), Support (operational burden)",
"common_tensions": "Speed vs quality, customer requests vs product vision, build vs buy, feature bloat vs simplicity",
"synthesis_patterns": "Phased releases (MVP first, full features later), tiered offerings (basic vs premium), build/buy hybrid (core in-house, periphery bought)"
},
"business_strategy": {
"key_roles": "Leadership (vision), Finance (economics), Sales (go-to-market), Operations (execution), Customers (value), Investors (return)",
"common_tensions": "Growth vs profitability, short-term vs long-term, organic vs acquisition, premium vs volume",
"synthesis_patterns": "Sequential priorities (growth phase then efficiency phase), portfolio approach (multiple bets), experiment to de-risk (pilot before scale)"
},
"organizational_change": {
"key_roles": "Leadership (collaboration), Employees (autonomy), HR (retention), Finance (cost), Managers (productivity)",
"common_tensions": "Flexibility vs structure, remote vs in-office, standardization vs customization, speed vs consensus",
"synthesis_patterns": "Hybrid models (balance extremes), role-based policies (nuance not one-size), opt-in incentives (voluntary vs mandate), trial periods (data-driven)"
},
"regulatory_compliance": {
"key_roles": "Legal (risk), Compliance (audit), Business (operations), Privacy (data protection), Regulators (public interest), Users (rights)",
"common_tensions": "Compliance cost vs business agility, data utility vs privacy, disclosure vs competitive secrecy",
"synthesis_patterns": "Regulatory constraints are non-negotiable (find commercial model within constraints), privacy-preserving techniques (differential privacy, aggregation), phased compliance (critical first, nice-to-have later)"
}
}
},
"common_failure_modes": {
"strawman_perspectives": {
"symptom": "Caricatured roles (e.g., 'finance just wants to cut costs', 'eng wants perfect code'), shallow or adversarial framing",
"root_cause": "Insufficient empathy, confirmation bias (projecting own view onto others), lack of steel-manning",
"fix": "Inhabit perspective charitably (what's strongest version of their argument?), use specific metrics and genuine fears (not stereotypes), distinguish position from interest (surface vs underlying need)"
},
"forced_consensus": {
"symptom": "Synthesis pretends win-win is always possible, ignores legitimate conflicts, avoids naming tradeoffs",
"root_cause": "Conflict aversion, wishful thinking, ignoring power dynamics (some roles have veto or final authority)",
"fix": "Explicitly name tensions (not gloss over), articulate tradeoffs with who wins/loses, acknowledge when perspectives are incompatible (escalate or experiment, don't force agreement), respect decision authority (consensus not required if autocratic/consultative decision)"
},
"missing_veto_holders": {
"symptom": "Synthesis ignores Legal/Security/Compliance who can block decision regardless of other alignment",
"root_cause": "Focusing on loudest voices (e.g., Sales, PM) and missing quiet but critical stakeholders with veto power",
"fix": "Identify veto holders (Legal, Security, Compliance, Regulatory), address their constraints first (non-negotiable), map power dynamics (RACI, power-interest matrix) not just vocal stakeholders"
},
"position_vs_interest_confusion": {
"symptom": "Synthesis addresses what stakeholders say they want (positions) not why they want it (interests)",
"root_cause": "Taking surface demands at face value, not digging into underlying needs ('I want this feature' vs 'because customers are churning')",
"fix": "Ask 'why' 2-3 times to uncover interests, distinguish position (surface demand) from interest (underlying need), synthesize at interest level (often can satisfy interest without meeting position)"
},
"ignoring_power_dynamics": {
"symptom": "Synthesis assumes all perspectives have equal weight, pretends peer consensus when decision is autocratic",
"root_cause": "Idealism (how we wish decisions worked) vs realism (how authority and hierarchy actually work)",
"fix": "Clarify decision authority (who has final say), acknowledge hierarchy (manager can override), respect veto power (Legal can block), synthesis should reflect power realities not ignore them"
},
"analysis_replaces_stakeholder_input": {
"symptom": "Role-switch treated as substitute for talking to actual stakeholders, no validation of perspective accuracy",
"root_cause": "Over-confidence in perspective-taking, avoiding difficult stakeholder conversations",
"fix": "Use role-switch to prepare for conversations (not replace them), validate perspectives with actual stakeholders ('did I understand your view correctly?'), flag information asymmetry (some roles have context you lack)"
}
},
"excellence_indicators": [
"Decision framing is specific and bounded (not vague), constraints and stakes explicit",
"3-6 roles selected with clear diversity (different goals, incentives, constraints, time horizons)",
"Decision authority and veto holders identified (RACI or power-interest mapping)",
"Each perspective charitably inhabited (steel-manned not strawman), specific metrics and genuine fears",
"Position vs interest distinguished for each role (surface demand vs underlying need)",
"Common ground identified before conflicts (shared goals, mutual fears)",
"Tensions explicitly named with concrete tradeoffs (upside/downside, who wins/loses)",
"Synthesis is concrete and actionable (not 'find balance'), addresses interests not positions",
"Tradeoffs explicitly accepted (who bears cost, what we're sacrificing)",
"Risk mitigation for each role's top fears",
"Sequencing if relevant (do X first, then Y), hybrid/creative options explored",
"Power dynamics acknowledged (decision authority, veto holders, hierarchy)",
"Escalation path defined if consensus fails (3 levels)",
"Accountability clear (decision owner, execution owner, stakeholder communication)",
"Next steps with owners and deadlines, success metrics defined",
"Analysis would prepare you well for actual stakeholder conversations (not theoretical exercise)"
]
}

354
skills/role-switch/resources/methodology.md Normal file
View File

@@ -0,0 +1,354 @@
# Role Switch: Advanced Methodologies
## Table of Contents
1. [Stakeholder Mapping & Selection](#1-stakeholder-mapping--selection)
2. [Cognitive Empathy Techniques](#2-cognitive-empathy-techniques)
3. [Power Dynamics & Decision Authority](#3-power-dynamics--decision-authority)
4. [Synthesis Strategies](#4-synthesis-strategies)
5. [Facilitation for Multi-Stakeholder Alignment](#5-facilitation-for-multi-stakeholder-alignment)
6. [Advanced Patterns](#6-advanced-patterns)
## 1. Stakeholder Mapping & Selection
### RACI Matrix (Responsibility Assignment)
Map stakeholders by their relationship to the decision:
- **R** (Responsible): Does the work, executes the decision
- **A** (Accountable): Has decision authority, owns outcome (only ONE per decision)
- **C** (Consulted): Provides input, must be heard before deciding
- **I** (Informed): Notified after decision, affected but not consulted
**Example (API deprecation decision):**
- **R**: Engineering (implements deprecation, migration tooling)
- **A**: VP Engineering (final call on timeline and support model)
- **C**: Product (customer impact), Finance (revenue implications), Customer Success (migration support)
- **I**: Sales (so they can communicate to prospects), Marketing (public messaging)
**Selection rule**: Always include **A** (decision authority). Include **R** if execution feasibility is uncertain. Include **C** stakeholders with veto power or critical constraints. Consider **I** stakeholders if their reaction could derail implementation.
### Power-Interest Matrix
Map stakeholders by **power** (ability to influence decision) and **interest** (how much they care):
```
High Interest, High Power → MANAGE CLOSELY (key players)
High Interest, Low Power → KEEP INFORMED (advocates/resistors)
Low Interest, High Power → KEEP SATISFIED (don't let them block)
Low Interest, Low Power → MONITOR (minimal engagement)
```
**Example (pricing change):**
- **High Power, High Interest**: CFO (margin), Sales VP (quota), top customers (retention)
- **High Power, Low Interest**: CEO (busy, delegates to CFO unless escalated)
- **Low Power, High Interest**: Individual sales reps (compensation), customer success managers (renewal risk)
- **Low Power, Low Interest**: Marketing ops (just implements new pricing in systems)
**Selection for role-switch**: Focus on high-interest stakeholders (top two quadrants). Include high-power stakeholders even if low interest (they can block). Deprioritize low-power, low-interest (not decision-critical).
### Influence Mapping (Who Influences Whom)
Some stakeholders don't decide but influence deciders:
**Example (hospital EMR selection):**
- **Formal authority**: CIO (signs contract), CFO (budget approval)
- **Informal influence**: Chief of Surgery (respected voice, if she opposes no one proceeds), Head of Nursing (staff adoption critical)
- **Technical veto**: CISO (security compliance), Legal (contract terms)
**Map influence paths**: Identify who the decision authority listens to. Include those influencers in role-switch even if they lack formal authority.
## 2. Cognitive Empathy Techniques
### Perspective-Taking Protocol
**Step 1: Inhabit the role's context**
- What is this role measured on? (OKRs, KPIs, promotion criteria)
- What are they accountable for? (what gets them fired if it fails)
- What information do they have that others don't? (asymmetric context)
- What pressures are they under? (boss's expectations, quarterly reviews, competitive threats)
**Step 2: Adopt their time horizon**
- **Short-term** (this quarter): Sales (quota), Support (ticket backlog)
- **Medium-term** (this year): Product (roadmap), Engineering (technical debt)
- **Long-term** (3+ years): Leadership (strategy), Legal (precedent setting)
Conflicts often arise from mismatched time horizons (sales wants deal today, eng sees 5-year maintenance burden).
**Step 3: Understand their incentive structure**
- **Aligned incentives**: Marketing and Sales both want customer acquisition (but marketing = leads, sales = closed deals)
- **Misaligned incentives**: Sales (maximize deal size) vs Finance (minimize discounts)
- **Perverse incentives**: Support (minimize handle time) vs Customers (thorough resolution)
**Step 4: Identify their constraints**
- **Resource constraints**: Headcount, budget, tooling access
- **Time constraints**: Quarterly deadlines, regulatory timelines, market windows
- **Process constraints**: Approval chains, audit requirements, compliance gates
- **Political constraints**: Board expectations, stakeholder promises, prior commitments
### Steel-Manning Perspectives
**Steel-manning**: Construct the *strongest possible* version of a role's position (opposite of strawman).
**Process**:
1. State their position as they would state it (use their language)
2. Identify the strongest evidence/reasoning for that position
3. Articulate what they might be right about (even if you disagree)
4. Note what legitimate values or priorities drive their stance
**Example (feature prioritization conflict):**
**Strawman (weak)**: "Sales just wants to promise customers everything to close deals, they don't care about product quality"
**Steel-man (strong)**: "Sales sees customer requests as real market signals—if multiple prospects ask for the same capability, it indicates unmet need and competitive gap. Prioritizing these features captures revenue that would otherwise go to competitors and validates product-market fit. Sales fears that saying 'no' to customer requests will result in lost deals, making it harder to hit quota, and signaling to the market that we're not responsive to customer needs."
Steel-manning builds trust when you present perspectives to stakeholders ("you see I understood your position") and surfaces legitimate concerns that deserve addressing.
### Position vs Interest Negotiation
**Position**: What they say they want (surface demand)
**Interest**: Why they want it (underlying need)
**Example**:
- **Position**: "We need this feature by Q1"
- **Interest**: "We promised a key customer in the sales cycle, and if we don't deliver we risk $500K annual contract and relationship damage"
**Why this matters**: You can often satisfy the interest without meeting the position.
- Alternative to building feature by Q1: Offer workaround solution, partner integration, or professional services to satisfy customer while buying time for proper feature in Q2.
**Uncovering interests**: Ask "why" 2-3 times:
- "Why do you want this feature?" → "Customer is asking for it"
- "Why is this customer important?" → "They're our largest account and up for renewal"
- "Why does this specific feature matter for renewal?" → "Competitor has it, they're considering switching"
Now you see the interest: competitive differentiation for retention, not the feature itself.
## 3. Power Dynamics & Decision Authority
### Decision Rights Framework
**Types of decision authority:**
- **Autocratic**: One person decides, others provide input (e.g., CEO on strategic pivot)
- **Consultative**: Decision-maker seeks input, but retains final call (e.g., PM on feature prioritization)
- **Consensus**: All stakeholders must agree (e.g., co-founders on equity split)
- **Democratic**: Majority vote (e.g., board approval)
- **Delegated**: Authority holder delegates to expert (e.g., CEO → CTO on tech stack)
**Role-switch implication**: Synthesis should acknowledge decision authority. If PM has final say on roadmap, synthesis can note "Engineering recommends X but PM decides based on customer commitments." Don't pretend consensus is required when it's not.
### Veto Power Identification
Some roles can't make the decision but can block it:
**Examples:**
- **Legal**: Can veto on liability/compliance grounds (not a suggestion, a blocker)
- **Security**: Can veto on risk grounds (breach could be existential)
- **Finance**: Can veto if budget doesn't exist (hard constraint)
- **Regulatory**: External veto (FDA, FTC, etc. can block regardless of internal consensus)
**Synthesis strategy**: Address veto-holders first. If Legal says "this contract exposes us to unacceptable IP risk," that's non-negotiable. Synthesis must either fix legal issue or find alternative path. No amount of alignment among other stakeholders overrides veto.
### Navigating Hierarchy
**Peer conflicts** (same level, e.g., VP Eng vs VP Product):
- Escalate to shared manager if consensus fails
- Frame as tradeoff for leadership to decide (don't make it personal)
- Offer to run experiment/pilot to gather data (de-emotionalize)
**Vertical conflicts** (manager vs subordinate):
- Subordinate's role: Make recommendation, provide data, articulate risks
- Manager's prerogative: Override with context subordinate may lack
- Synthesis should acknowledge manager has broader context (benefit of doubt)
**Cross-functional conflicts** (different orgs):
- Identify shared OKRs or company goals to align on
- Escalate to neutral party (e.g., COO) if functions can't resolve
- Avoid "us vs them"—frame as "how do we both win?"
## 4. Synthesis Strategies
### Sequential Decision-Making
When perspectives conflict, decompose into sequence:
**Pattern**: "Do X first (satisfies role A), then Y (satisfies role B), then Z (satisfies role C)"
**Example (build vs buy):**
- **Engineering**: "Build in-house for control"
- **Product**: "Buy to launch faster"
- **Synthesis**: "Buy now to hit market window (Product wins short-term). As we scale, evaluate build for strategic capabilities (Engineering wins long-term). Set decision checkpoint at 10K users (concrete trigger)."
**Benefits**: Reduces present conflict (only deciding immediate action), creates learning period (gather data before next decision), aligns incentives over time.
### Hybrid Approaches
Combine elements from multiple perspectives:
**Example (pricing strategy):**
- **Finance**: "Charge premium to maximize margin"
- **Sales**: "Offer competitive pricing to win deals"
- **Marketing**: "Simple, transparent pricing"
- **Synthesis**: "Tiered pricing (Finance gets premium tier, Sales gets accessible entry tier, Marketing gets 3 clear tiers with public pricing)"
**Example (work policy):**
- **Leadership**: "In-office for collaboration"
- **Employees**: "Remote for flexibility"
- **Synthesis**: "Hybrid 3 days/week in-office (Leadership gets collaboration days), 2 days remote (Employees get flexibility), core hours 10am-3pm Tue-Thu (ensures overlap)"
### Pilot/Experiment to Resolve Uncertainty
When conflict stems from different predictions, run experiment:
**Example:**
- **Sales**: "Customers will pay 20% more for premium tier"
- **Product**: "Customers are price-sensitive, will churn at higher price"
- **Synthesis**: "Run 2-week pricing test with 10% of new trials. Measure conversion rate and NPS. Decision rule: If conversion drops <5%, proceed with premium pricing. If drops >10%, stay at current price."
**Benefits**: Converts opinions to data, de-risks decision, builds consensus around evidence.
### Constraints as Creative Forcing Function
Use one role's constraint to sharpen another's solution:
**Example:**
- **Finance**: "We have $100K budget, not $500K"
- **Product**: "We want features A, B, C, D, E"
- **Synthesis**: "Budget constraint forces ruthless prioritization. Which single feature drives 80% of value? (Pareto principle). Build only that feature to MVP standard in Q1, defer B-E to Q2 based on usage data from A."
Constraint (budget) forces clearer thinking about value (Product benefits from discipline).
### Risk Mitigation for Fears
Address each role's top fear with specific mitigation:
**Example (technical migration):**
- **Engineering fear**: "Migration will surface hidden dependencies and blow up timeline"
- **Mitigation**: 2-week technical spike to map dependencies, discovery phase with 30% time buffer
- **Product fear**: "Feature freeze will let competitor gain ground"
- **Mitigation**: Incremental migration (no freeze), maintain feature velocity on new system
- **User fear**: "Downtime will disrupt workflows"
- **Mitigation**: Blue-green deployment, rollback plan, phased rollout starting with low-risk cohort
Naming fears explicitly and mitigating shows you took each perspective seriously.
## 5. Facilitation for Multi-Stakeholder Alignment
### Pre-Work for Alignment Meetings
**Before bringing stakeholders together:**
1. **Identify decision framing**: What exactly are we deciding? (avoid vague "alignment meeting")
2. **Pre-socialize positions**: Talk to each stakeholder 1:1 to understand their stance (no surprises in group)
3. **Find common ground**: Identify 2-3 shared goals to anchor discussion
4. **Prepare synthesis options**: Come with 2-3 proposals that address key interests (don't start from blank slate)
5. **Clarify decision authority**: Who has final say if consensus fails?
### Facilitation Techniques
**Round-robin sharing** (ensure all voices heard):
- Each stakeholder shares their perspective (2 min, uninterrupted)
- Others listen without rebutting (defer debate to later)
- Captures positions before conflict dominates
**Interest articulation** (go beneath positions):
- Facilitator asks: "What outcome would satisfy your core need?" (not "what do you want us to do")
- Reframe positions as interests: "I hear you want X because you're trying to achieve Y"
**Tradeoff matrix** (make tradeoffs explicit):
- On whiteboard, list options across top, criteria down left side
- Score each option (1-5) against each criterion
- Visually shows why no option is perfect (builds realistic expectations)
**Consensus-building ladder**:
1. **Full agreement**: Everyone enthusiastically supports
2. **Agreement with minor reservations**: Support with noted concerns
3. **Support with significant reservations**: "I disagree but won't block"
4. **Abstain**: "I have no strong opinion"
5. **Stand aside**: "I disagree but defer to group"
6. **Block**: "I cannot support this" (veto)
Most decisions don't need Level 1. Level 2-3 is sufficient. Reserve Level 6 (block) for ethical/legal/existential issues.
### Dealing with Impasse
**When stakeholders can't agree:**
**Option 1: Escalate**
- Clearly frame tradeoff for decision authority
- Example: "Engineering recommends A (technical merit), Sales recommends B (customer promise). VP Product, your call."
**Option 2: Decouple**
- Split into multiple decisions with different owners
- Example: "Engineering decides tech stack (their domain). Product decides feature scope (their domain)."
**Option 3: Time-box discussion**
- "We'll discuss for 30 min. If no consensus, we'll go with default option C and revisit in 3 months."
**Option 4: Introduce new information**
- "Let's gather customer feedback / run competitive analysis / build prototype before deciding."
## 6. Advanced Patterns
### Divergent Incentives (Sales vs Finance vs Ops)
**Scenario**: Sales wants custom contracts to close deals, Finance wants standardized pricing to forecast revenue, Operations wants limited SKUs to simplify fulfillment.
**Tension**: Each role optimizes for different metric (deal size vs predictability vs complexity).
**Synthesis**:
- **Core offering**: Standardized packages (Finance & Ops win on base case)
- **Custom tier**: Allow customization for enterprise deals >$500K with CFO approval (Sales wins on strategic accounts)
- **Operational tax**: Custom deals pay 20% premium to fund ops complexity (Ops gets resourced, Sales pays for flexibility)
**Principle**: Tiered approach where standardization is default, customization is available but priced to internalize costs.
### Temporal Conflicts (Short-Term vs Long-Term)
**Scenario**: Marketing wants aggressive growth spend (customer acquisition), Finance wants profitability (unit economics), Leadership wants sustainable growth.
**Tension**: Short-term growth (sacrifice margins) vs long-term health (profitable unit economics).
**Synthesis**:
- **Phase 1** (Year 1): Growth mode—invest in acquisition, LTV:CAC = 2:1 acceptable (Marketing wins)
- **Phase 2** (Year 2): Efficiency mode—optimize unit economics, LTV:CAC = 4:1 target (Finance wins)
- **Trigger for shift**: Hit $10M ARR or 18 months, whichever comes first (Leadership defines graduation criteria)
**Principle**: Sequence priorities over time with clear phase transitions.
### Regulatory/Ethical vs Commercial Tensions
**Scenario**: Product wants to use customer data for personalization (revenue driver), Privacy/Legal want data minimization (compliance, trust).
**Tension**: Commercial opportunity (more data = better product) vs regulatory/ethical constraint (less data = lower risk).
**Synthesis**:
- **Explicit consent**: Only use data if customer opts in (Legal satisfied—compliant)
- **Value exchange**: Show customer how data improves their experience (Product satisfied—retention driver)
- **Minimization**: Collect only what's needed for stated purpose, delete after 90 days (Privacy satisfied—limits exposure)
- **Differential privacy**: Aggregate data for analytics, never expose individual records (Security satisfied—no breach risk)
**Principle**: Regulatory constraints are non-negotiable. Find commercial model that works within those constraints (not around them).
### Cross-Cultural or Cross-Organizational Differences
**Scenario**: Acquiring company (startup culture) vs acquired company (enterprise culture) have different decision norms.
**Tension**: Fast, informal decisions (startup) vs deliberate, documented decisions (enterprise).
**Synthesis**:
- **Categorize decisions**: Reversible (fast process), irreversible (rigorous process) (Amazon "Type 1 vs Type 2")
- **Reversible examples**: UI changes, feature experiments → Startup process (bias to action)
- **Irreversible examples**: Infrastructure migrations, M&A, pricing model → Enterprise process (diligence, documentation)
- **Hybrid team norms**: Preserve startup speed for Type 2 decisions, adopt enterprise rigor for Type 1 (best of both)
**Principle**: Integrate cultural differences by creating framework that specifies when each approach applies.
---
## When to Use Methodology
**Simple decisions** (<4 stakeholders, clear authority): Use template.md
**Complex decisions** (5+ stakeholders, power dynamics, veto players): Use this methodology for:
- RACI and power-interest mapping (Section 1)
- Steel-manning and interest negotiation (Section 2)
- Decision rights and veto identification (Section 3)
- Advanced synthesis strategies (Section 4)
- Facilitation for multi-party alignment (Section 5)

354
skills/role-switch/resources/template.md Normal file
View File

@@ -0,0 +1,354 @@
# Role Switch Template
## Workflow
Copy this checklist and track your progress:
```
Role Switch Progress:
- [ ] Step 1: Frame decision and context
- [ ] Step 2: Select 3-6 relevant roles
- [ ] Step 3: Inhabit each role's perspective
- [ ] Step 4: Map tensions and tradeoffs
- [ ] Step 5: Synthesize alignment path
```
**Step 1: Frame decision and context**
Complete the [Decision Framing](#decision-framing) section. Clarify what's being decided and why it matters.
**Step 2: Select 3-6 relevant roles**
Identify stakeholders in the [Roles Selected](#roles-selected) section. Choose roles with different goals or constraints.
**Step 3: Inhabit each role's perspective**
For each role, complete the [Role Perspectives](#role-perspectives) section. Articulate what they optimize for and fear.
**Step 4: Map tensions and tradeoffs**
Identify conflicts in the [Tensions & Tradeoffs](#tensions--tradeoffs) section. Document where perspectives are incompatible.
**Step 5: Synthesize alignment path**
Propose resolutions in the [Synthesis & Path Forward](#synthesis--path-forward) section. Find common ground and actionable next steps.
---
## Role Switch Analysis
### Decision Framing
**Decision/Situation**: [What's being decided or analyzed]
**Key Constraints**:
- **Timeline**: [Deadline or urgency level]
- **Budget**: [Financial constraints or cost sensitivity]
- **Scope**: [What's in/out of scope, non-negotiables]
- **Quality bars**: [Performance, security, compliance requirements]
**Why alignment matters**: [Stakes—what happens if we get this wrong? Why do these stakeholders need to align?]
**Current state**: [Where we are today, what prompted this decision]
**Success looks like**: [Desired outcome that would satisfy most stakeholders]
---
### Roles Selected
**Primary roles** (3-6 with different goals/incentives):
1. **[Role Name]**: [Brief description of this role's mandate and what they're accountable for]
2. **[Role Name]**: [...]
3. **[Role Name]**: [...]
4. **[Role Name]**: [...]
5. **[Role Name]**: [...]
6. **[Role Name]**: [...]
**Why these roles**: [Rationale for selection—what diversity of perspective do they bring?]
**Roles intentionally excluded**: [Any stakeholders not included, and why (e.g., not directly impacted, defer to their delegate)]
---
### Role Perspectives
For each role, complete this analysis:
#### Role 1: [Role Name]
**Core mandate**: [What is this role responsible for? What's their job?]
**What they optimize for**:
- [Primary success metric or goal, e.g., "Customer retention rate"]
- [Secondary goal, e.g., "Support ticket volume reduction"]
- [Tertiary goal, e.g., "Team morale and retention"]
**What they fear** (risks they want to avoid):
- [Top risk, e.g., "Customer churn from poor experience"]
- [Secondary risk, e.g., "Team burnout from unsustainable workload"]
- [Tertiary risk, e.g., "Losing competitive differentiation"]
**How they measure success**: [Metrics or indicators, e.g., "NPS >40, ticket resolution <24h, team tenure >2 years"]
**Constraints they face**:
- [Resource constraint, e.g., "Headcount freeze—can't hire"]
- [Time constraint, e.g., "Quarterly business review in 2 weeks"]
- [Process constraint, e.g., "Must comply with SOC 2 audit requirements"]
**Perspective on this decision**:
- **Position** (what they say they want): [Surface demand, e.g., "I want this feature built"]
- **Interest** (why they want it): [Underlying need, e.g., "Because customers are churning and cite this gap"]
- **Proposed solution**: [What would this role advocate for?]
- **Tradeoffs they're willing to accept**: [What would they compromise on?]
- **Non-negotiables**: [Where they won't budge]
---
#### Role 2: [Role Name]
**Core mandate**: [...]
**What they optimize for**:
- [...]
- [...]
**What they fear**:
- [...]
- [...]
**How they measure success**: [...]
**Constraints they face**:
- [...]
- [...]
**Perspective on this decision**:
- **Position**: [...]
- **Interest**: [...]
- **Proposed solution**: [...]
- **Tradeoffs they're willing to accept**: [...]
- **Non-negotiables**: [...]
---
#### Role 3: [Role Name]
[Repeat structure for each role...]
---
#### Role 4: [Role Name]
[Repeat structure...]
---
#### Role 5: [Role Name]
[Repeat structure...]
---
#### Role 6: [Role Name]
[Repeat structure...]
---
### Tensions & Tradeoffs
**Where perspectives align** (common ground):
- **Shared goals**: [What do all/most roles want? E.g., "All want company to succeed, customer to be happy"]
- **Compatible sub-goals**: [Where objectives overlap, e.g., "Marketing and Product both want clear value proposition"]
- **Mutual fears**: [What do all want to avoid? E.g., "No one wants reputational damage or security breach"]
**Where perspectives conflict** (tensions):
| Tension | Role A → Position | Role B → Position | Nature of Conflict |
|---------|-------------------|-------------------|-------------------|
| [Tension 1, e.g., "Speed vs Quality"] | [Eng: "Ship fast"] | [QA: "Test thoroughly"] | Sequential bottleneck—thorough testing delays launch |
| [Tension 2, e.g., "Cost vs Capability"] | [Finance: "Minimize cost"] | [Product: "Premium features"] | Resource allocation—budget caps feature scope |
| [Tension 3, e.g., "Privacy vs Personalization"] | [Privacy: "Minimize data collection"] | [Marketing: "Rich user profiles"] | Incompatible goals—less data = less personalization |
**Explicit tradeoffs**:
For each major tension, articulate the tradeoff:
**Tradeoff 1: [Tension name]**
- **Option A** (favors [Role]): [Description, e.g., "Launch in 2 weeks with minimal testing"]
- **Upside**: [What this achieves, e.g., "Hit market window, revenue starts sooner"]
- **Downside**: [What this sacrifices, e.g., "Higher bug rate, potential customer complaints"]
- **Who wins/loses**: [...]
- **Option B** (favors [Role]): [Description, e.g., "Delay 4 weeks for full QA cycle"]
- **Upside**: [What this achieves, e.g., "High quality launch, strong first impression"]
- **Downside**: [What this sacrifices, e.g., "Miss market window, competitor may launch first"]
- **Who wins/loses**: [...]
- **Hybrid option** (if exists): [Description, e.g., "Launch core features in 2 weeks, full feature set in 4 weeks"]
- **Upside**: [...]
- **Downside**: [...]
- **Who wins/loses**: [...]
**Tradeoff 2: [Tension name]**
[Repeat structure...]
**Tradeoff 3: [Tension name]**
[Repeat structure...]
---
### Synthesis & Path Forward
**Common ground identified**:
- [Shared goal 1 that can be starting point for alignment]
- [Shared goal 2...]
- [Mutual fear that all want to mitigate...]
**Proposed resolution** (synthesis):
**Decision**: [Recommended path forward that addresses core concerns]
**Rationale**: [Why this resolution addresses most critical interests across roles]
**How it addresses each role's core interests**:
- **[Role 1]**: [How this meets their key need or mitigates their key fear]
- **[Role 2]**: [...]
- **[Role 3]**: [...]
- **[Role 4]**: [...]
- **[Role 5]**: [...]
- **[Role 6]**: [...]
**Explicit tradeoffs accepted**:
- [Tradeoff 1: What we're sacrificing and who bears the cost]
- [Tradeoff 2: ...]
**Sequencing** (if relevant):
1. **Phase 1** (immediate): [What happens first, who owns, timeline]
2. **Phase 2** (near-term): [What follows, dependencies]
3. **Phase 3** (later): [Longer-term steps, contingencies]
**Risk mitigation**:
- **Risk 1** ([Role's fear]): [Mitigation plan, e.g., "To address Eng's fear of tech debt, schedule Q2 refactoring sprint"]
- **Risk 2** ([Role's fear]): [Mitigation plan...]
- **Risk 3** ([Role's fear]): [Mitigation plan...]
**Accountability**:
- **Decision owner**: [Who has final call, authority to commit resources]
- **Execution owner**: [Who drives implementation]
- **Stakeholder communication**: [Who updates which stakeholders, cadence]
- **Success metrics**: [How we'll know this is working, review timeline]
**Escalation path** (if consensus fails):
- **Level 1**: [First escalation point if implementation stalls, e.g., "Team leads meet to resolve resource conflicts"]
- **Level 2**: [Second escalation if unresolved, e.g., "VP decides tradeoff between cost and quality"]
- **Level 3**: [Final escalation for fundamental conflicts, e.g., "CEO call on strategic direction"]
**Open questions**:
- [Question 1 that needs answering before committing]
- [Question 2...]
- [Question 3...]
**Next steps**:
- [ ] [Action 1, owner, deadline, e.g., "PM drafts feature spec - Alice - 2 weeks"]
- [ ] [Action 2, owner, deadline, e.g., "Finance models ROI scenarios - Bob - 1 week"]
- [ ] [Action 3, owner, deadline, e.g., "Eng spikes technical feasibility - Carol - 3 days"]
- [ ] [Action 4: Schedule alignment meeting with stakeholders - You - Tomorrow]
---
## Guidance for Each Section
### Decision Framing
**Good framing** (specific, bounded):
- ✓ "Should we deprecate API v1 in Q1 2025 or extend support through Q4 2025?"
- ✓ "Choose between building in-house analytics vs buying Mixpanel (decision by Dec 1)"
- ✓ "Set return-to-office policy: full remote, hybrid (2 days/week), or full in-office"
**Bad framing** (vague, open-ended):
- ❌ "Improve our product"
- ❌ "Make customers happier"
- ❌ "Do the right thing"
### Role Selection
**Choose roles with different**:
- **Goals**: Marketing (brand), Sales (quota), Finance (margin)
- **Incentives**: Eng (technical excellence), PM (shipping features), Support (ticket reduction)
- **Constraints**: Legal (risk), Operations (scalability), Users (usability)
- **Time horizons**: Leadership (long-term vision), Sales (quarterly quota), Customers (immediate pain)
**Avoid**:
- Too many roles (>6 becomes unwieldy)
- Too few roles (< 3 misses diversity)
- Redundant roles (two perspectives that would be identical)
### Inhabiting Perspectives
**Make perspectives real**:
- Use specific metrics (not "sales wants more", but "sales measured on quarterly quota attainment")
- Articulate genuine fears (not "eng doesn't like change", but "eng fears tech debt will compound and slow future velocity")
- Distinguish position (surface demand) from interest (underlying need)
**Avoid caricature**:
- ❌ "Finance only cares about cutting costs"
- ✓ "Finance optimizes for sustainable margin and cash flow to fund growth while managing risk"
### Synthesis Quality
**Strong synthesis**:
- Addresses interests, not just positions
- Proposes concrete, actionable resolution
- Acknowledges tradeoffs explicitly
- Sequences decisions to build momentum
- Includes risk mitigation for key fears
**Weak synthesis**:
- "We should find a middle ground" (no specifics)
- "Everyone needs to compromise" (no proposed resolution)
- Ignores power dynamics (pretends all roles have equal weight)
- Avoids naming tradeoffs (pretends win-win is always possible)
---
## Quality Checklist
Before finalizing, verify:
**Decision framing:**
- [ ] Decision is specific and bounded (not vague)
- [ ] Constraints explicitly stated (time, budget, scope)
- [ ] Stakes articulated (why alignment matters)
**Role selection:**
- [ ] 3-6 roles selected with different goals/incentives/constraints
- [ ] Roles cover key stakeholders (internal + external if relevant)
- [ ] Rationale for inclusion/exclusion stated
**Perspectives:**
- [ ] Each role has clear mandate, success metrics, fears
- [ ] Position vs interest distinguished
- [ ] Perspectives charitably inhabited (strongest version, not strawman)
- [ ] Non-negotiables and tradeoff willingness stated
**Tensions:**
- [ ] Shared goals and mutual fears identified (common ground)
- [ ] Conflicts explicitly named (not glossed over)
- [ ] Tradeoffs articulated with upside/downside for each option
**Synthesis:**
- [ ] Proposed resolution is concrete and actionable
- [ ] Resolution addresses core interests (not just positions)
- [ ] Tradeoffs explicitly accepted (who bears cost)
- [ ] Risk mitigation for key fears included
- [ ] Accountability (decision owner, execution owner) assigned
- [ ] Next steps with owners and deadlines
**Quality standards:**
- [ ] Analysis would prepare you well for actual stakeholder conversations
- [ ] Synthesis is realistic (not wishful thinking or forced consensus)
- [ ] Power dynamics acknowledged (who has authority)
- [ ] Escalation path defined if consensus fails