Initial commit

2025-11-30 08:38:26 +08:00
commit 41d9f6b189
304 changed files with 98322 additions and 0 deletions
--- a/skills/stakeholders-org-design/SKILL.md
+++ b/skills/stakeholders-org-design/SKILL.md
@@ -0,0 +1,256 @@
+---
+name: stakeholders-org-design
+description: Use when designing organizational structure (team topologies, Conway's Law alignment), mapping stakeholders by power-interest for change initiatives, defining team interface contracts (APIs, SLAs, decision rights, handoffs), assessing capability maturity (DORA, CMMC, agile maturity models), planning org restructures (functional to product teams, platform teams, shared services), or when user mentions "org design", "team structure", "stakeholder map", "team interfaces", "capability maturity", "Conway's Law", or "RACI".
+---
+
+# Stakeholders & Organizational Design
+
+## Table of Contents
+1. [Purpose](#purpose)
+2. [When to Use](#when-to-use)
+3. [What Is It](#what-is-it)
+4. [Workflow](#workflow)
+5. [Stakeholder Mapping](#stakeholder-mapping)
+6. [Team Interface Contracts](#team-interface-contracts)
+7. [Capability Maturity](#capability-maturity)
+8. [Common Patterns](#common-patterns)
+9. [Guardrails](#guardrails)
+10. [Quick Reference](#quick-reference)
+
+## Purpose
+
+Stakeholders & Organizational Design provides frameworks for mapping influence networks, designing effective team structures aligned with system architecture (Conway's Law), defining clear team interfaces and responsibilities, and assessing organizational capability maturity to guide improvement.
+
+## When to Use
+
+**Invoke this skill when you need to:**
+- Design or restructure organizational teams (functional → product, monolith → microservices teams, platform teams)
+- Map stakeholders for change initiatives (power-interest matrix, influence networks, champions/blockers)
+- Define team interfaces and contracts (APIs, SLAs, handoff protocols, decision rights)
+- Assess capability maturity (DevOps/DORA, security/CMMC, agile, data, design maturity models)
+- Apply Conway's Law (align team structure with desired system architecture)
+- Establish governance frameworks (RACI, decision rights, escalation paths)
+- Plan cross-functional collaboration models (product triads, embedded vs centralized)
+- Design team topologies (stream-aligned, platform, enabling, complicated-subsystem)
+
+**User phrases that trigger this skill:**
+- "How should we structure our teams?"
+- "Map stakeholders for [initiative]"
+- "Define team interfaces"
+- "Assess our [capability] maturity"
+- "Conway's Law"
+- "Team Topologies"
+- "RACI matrix"
+
+## What Is It
+
+A framework combining:
+1. **Stakeholder Mapping**: Power-interest matrix, influence networks, RACI for decision rights
+2. **Organizational Design**: Team structures aligned with architecture and strategy
+3. **Team Interface Contracts**: APIs, SLAs, handoff protocols, communication patterns
+4. **Capability Maturity**: Assessment using standard models (DORA, CMMC, CMM, custom rubrics)
+
+**Quick example (Platform Team Design):**
+
+**Stakeholder Map:**
+- **High Power, High Interest**: Engineering VP (sponsor), Product teams (customers)
+- **High Power, Low Interest**: CTO (keep satisfied with metrics)
+- **Low Power, High Interest**: Individual engineers (keep informed)
+
+**Team Structure:**
+- **Platform Team** (8 people): Developer experience, infrastructure, observability
+- **Interface**: Self-service APIs, documentation, office hours
+- **SLA**: 99.9% uptime, <2 week feature delivery, <4hr critical bug fix
+
+**Capability Maturity** (DORA metrics):
+- Deployment frequency: Daily → Weekly (target: Daily)
+- Lead time: 1 week → 2 days (target: <1 day)
+- MTTR: 4 hours → 1 hour (target: <1 hour)
+- Change failure rate: 15% → 5% (target: <5%)
+
+## Workflow
+
+Copy this checklist and track your progress:
+
+```
+Org Design Progress:
+- [ ] Step 1: Map stakeholders and influence
+- [ ] Step 2: Define team structure and boundaries
+- [ ] Step 3: Specify team interfaces and contracts
+- [ ] Step 4: Assess capability maturity
+- [ ] Step 5: Create transition plan with governance
+```
+
+**Step 1: Map stakeholders and influence**
+
+Identify all stakeholders, categorize by power-interest, map influence networks. See [Stakeholder Mapping](#stakeholder-mapping) for power-interest matrix and RACI frameworks.
+
+**Step 2: Define team structure and boundaries**
+
+Design teams aligned with architecture and strategy. For straightforward restructuring → Use [resources/template.md](resources/template.md). For complex org design with Conway's Law → Study [resources/methodology.md](resources/methodology.md).
+
+**Step 3: Specify team interfaces and contracts**
+
+Define APIs, SLAs, handoff protocols, decision rights between teams. See [Team Interface Contracts](#team-interface-contracts) for contract patterns.
+
+**Step 4: Assess capability maturity**
+
+Evaluate current state using maturity models (DORA, CMMC, custom). See [Capability Maturity](#capability-maturity) for assessment frameworks.
+
+**Step 5: Create transition plan with governance**
+
+Define migration path, decision rights, review cadence. Self-check using [resources/evaluators/rubric_stakeholders_org_design.json](resources/evaluators/rubric_stakeholders_org_design.json). Minimum standard: Average score ≥ 3.5.
+
+## Stakeholder Mapping
+
+### Power-Interest Matrix
+
+| Quadrant | Engagement | Example |
+|----------|------------|---------|
+| High Power, High Interest | Manage Closely (frequent communication) | Executive sponsor, product owner |
+| High Power, Low Interest | Keep Satisfied (status updates) | CFO for tech project, legal |
+| Low Power, High Interest | Keep Informed (engage for feedback) | Individual contributors, early adopters |
+| Low Power, Low Interest | Monitor (minimal engagement) | Peripheral teams |
+
+### RACI Matrix
+
+- **R - Responsible**: Does the work (can be multiple) — Example: Engineering team builds feature
+- **A - Accountable**: Owns outcome (**exactly one** per decision) — Example: Product manager accountable for feature success
+- **C - Consulted**: Provides input before decision (two-way) — Example: Security team consulted on auth design
+- **I - Informed**: Notified after decision (one-way) — Example: Support team informed of launch
+
+### Influence Network Mapping
+
+**Identify**: Champions (advocates), Blockers (resistors), Bridges (connectors), Gatekeepers (control access)
+**Map**: Who influences whom? Formal vs informal power, trust relationships, communication patterns
+
+## Team Interface Contracts
+
+### API Contracts
+
+**Specify**: Endpoints, data format/schemas, authentication, rate limits, versioning/backward compatibility
+**Example**: Service: User Auth API | Owner: Identity Team | Endpoints: /auth/login, /auth/token | SLA: 99.95% uptime, <100ms p95
+
+### SLA (Service Level Agreements)
+
+**Define**: Availability (99.9%, 99.99%), Performance (p50/p95/p99 latency), Support response times (critical: 1hr, high: 4hr, medium: 1 day), Capacity (requests/sec, storage)
+
+### Handoff Protocols
+
+**Design → Engineering**: Specs, prototype, design review sign-off | **Engineering → QA**: Feature complete, test plan, staging | **Engineering → Support**: Docs, runbook, training | **Research → Product**: Findings, recommendations, prototypes
+
+### Decision Rights (DACI)
+
+**D - Driver** (orchestrates), **A - Approver** (exactly one), **C - Contributors** (input), **I - Informed** (notified)
+**Examples**: Architectural (Tech Lead approves, Architects contribute) | Hiring (Hiring Manager approves, Interviewers contribute) | Roadmap (PM approves, Eng/Design/Sales contribute)
+
+## Capability Maturity
+
+### DORA Metrics (DevOps Maturity)
+
+| Metric | Elite | High | Medium | Low |
+|--------|-------|------|--------|-----|
+| Deployment Frequency | Multiple/day | Weekly-daily | Monthly-weekly | <Monthly |
+| Lead Time | <1 hour | <1 day | 1 week-1 month | >1 month |
+| MTTR | <1 hour | <1 day | 1 day-1 week | >1 week |
+| Change Failure Rate | 0-15% | 16-30% | 31-45% | >45% |
+
+### Generic Maturity Levels (CMM)
+
+**Level 1 Initial**: Unpredictable, reactive | **Level 2 Repeatable**: Basic PM | **Level 3 Defined**: Documented, standardized | **Level 4 Measured**: Data-driven | **Level 5 Optimizing**: Continuous improvement
+
+### Custom Capability Assessment
+
+**Template**: Capability Name | Current Level (1-5 with evidence) | Target Level | Gap | Action Items
+
+## Common Patterns
+
+**Pattern 1: Functional → Product Teams (Spotify Model)**
+- **Before**: Frontend team, Backend team, QA team, DevOps team
+- **After**: Product Squad 1 (full-stack), Product Squad 2 (full-stack)
+- **Interfaces**: Squads own end-to-end features, shared platform team for infrastructure
+- **Benefit**: Faster delivery, reduced handoffs, clear ownership
+
+**Pattern 2: Platform Team Extraction**
+- **Trigger**: Multiple product teams duplicating infrastructure work
+- **Design**: Create platform team providing self-service tools
+- **Interface**: Platform team APIs + documentation, office hours, SLA
+- **Staffing**: 10-15% of engineering (1 platform engineer per 7-10 product engineers)
+
+**Pattern 3: Embedded vs Centralized Specialists**
+- **Embedded**: Security/QA/Data engineers within product teams (close collaboration)
+- **Centralized**: Specialists in separate team (consistency, expertise depth)
+- **Hybrid**: Center of Excellence (set standards) + Embedded (implementation)
+- **Choice Factors**: Team size, maturity, domain complexity
+
+**Pattern 4: Conway's Law Alignment**
+- **Principle**: System design mirrors communication structure
+- **Application**: Design teams to match desired architecture
+- **Example**: Microservices → Small autonomous teams per service
+- **Anti-pattern**: Monolithic team structure → Monolithic architecture persists
+
+**Pattern 5: Team Topologies (4 Fundamental Types)**
+- **Stream-Aligned**: Product teams, aligned with flow of change
+- **Platform**: Internal products enabling stream-aligned teams
+- **Enabling**: Build capability in stream-aligned teams (temporary)
+- **Complicated-Subsystem**: Specialists for complex areas (ML, security)
+
+## Guardrails
+
+**Conway's Law is inevitable:**
+- Teams will produce systems mirroring their communication structure
+- Design teams intentionally for desired architecture
+- Reorganizing teams = reorganizing system boundaries
+
+**Team size limits:**
+- **2-pizza team**: 5-9 people (Amazon)
+- **Dunbar's number**: 5-15 close working relationships
+- Too small (<3): Fragile, lacks skills diversity
+- Too large (>12): Communication overhead, subgroups form
+
+**Cognitive load per team:**
+- Each team has limited capacity for domains/systems
+- **Simple**: 1 domain per team
+- **Complicated**: 2-3 related domains
+- **Complex**: Max 1 complex domain per team
+
+**Interface ownership clarity:**
+- Every interface needs one clear owner
+- Shared ownership = no ownership
+- Document: Owner, SLA, contact, escalation
+
+**Avoid matrix hell:**
+- Minimize dual reporting (confusing accountability)
+- If matrix needed: Clear primary vs secondary manager
+- Define decision rights explicitly (RACI/DACI)
+
+**Stakeholder fatigue:**
+- Don't manage all stakeholders equally
+- High power/interest = frequent engagement
+- Low power/interest = minimal updates
+- Adjust as power/interest shifts
+
+**Maturity assessment realism:**
+- Don't grade on aspirations
+- Evidence-based assessment (metrics, artifacts, observation)
+- Common pitfall: Over-rating current state
+- Use external benchmarks when available
+
+## Quick Reference
+
+**Resources:**
+- **Quick org design**: [resources/template.md](resources/template.md)
+- **Conway's Law & Team Topologies**: [resources/methodology.md](resources/methodology.md)
+- **Quality rubric**: [resources/evaluators/rubric_stakeholders_org_design.json](resources/evaluators/rubric_stakeholders_org_design.json)
+
+**5-Step Process**: Map Stakeholders → Define Teams → Specify Interfaces → Assess Maturity → Transition Plan
+
+**Stakeholder Mapping**: Power-Interest Matrix (High/Low × High/Low), RACI (Responsible/Accountable/Consulted/Informed), Influence Networks
+
+**Team Interfaces**: API contracts, SLAs (availability/performance/support), handoff protocols, decision rights (DACI/RAPID)
+
+**Maturity Models**: DORA (deployment frequency, lead time, MTTR, change failure rate), Generic CMM (5 levels), Custom assessments
+
+**Team Types**: Stream-Aligned (product), Platform (internal products), Enabling (capability building), Complicated-Subsystem (specialists)
+
+**Guardrails**: Conway's Law, team size (2-pizza, Dunbar), cognitive load limits, interface ownership clarity, avoid matrix hell
--- a/skills/stakeholders-org-design/resources/evaluators/rubric_stakeholders_org_design.json
+++ b/skills/stakeholders-org-design/resources/evaluators/rubric_stakeholders_org_design.json
@@ -0,0 +1,206 @@
+{
+  "name": "Stakeholders & Organizational Design Evaluator",
+  "description": "Evaluates org designs for stakeholder mapping completeness, Conway's Law alignment, team interface clarity, capability maturity assessment, and transition planning",
+  "criteria": [
+    {
+      "name": "Stakeholder Mapping Completeness & Strategy",
+      "weight": 1.3,
+      "scale": {
+        "1": "No stakeholder mapping, or only lists names without analysis, missing key stakeholders (forgot legal, finance, or affected teams)",
+        "2": "Stakeholders identified but power-interest not assessed, no RACI, no engagement strategy, champions/blockers not identified",
+        "3": "Power-interest matrix complete, some RACI defined, general engagement strategy but not tailored per quadrant, some key stakeholders identified",
+        "4": "Comprehensive stakeholder map (power-interest + RACI + influence network), champions/blockers identified, engagement strategy per quadrant, decision rights clear",
+        "5": "Exemplary: Complete stakeholder ecosystem mapped (internal + external, formal + informal power), power-interest assessed with evidence (not assumptions), RACI for all key decisions with exactly one Accountable each, influence network analyzed (champions, blockers, bridges, gatekeepers documented), coalition building strategy (WIIFM per stakeholder, sequencing plan), tailored engagement per quadrant (manage closely, keep satisfied, keep informed, monitor), political dynamics understood (competing agendas, veto power, historical context)"
+      }
+    },
+    {
+      "name": "Conway's Law Alignment",
+      "weight": 1.5,
+      "scale": {
+        "1": "No mention of Conway's Law, team structure clearly misaligned with desired architecture (e.g., monolithic teams for microservices), no analysis of current misalignment",
+        "2": "Conway's Law mentioned but not applied, team structure doesn't match desired architecture, current architecture-team mismatches not identified",
+        "3": "Basic alignment attempt (team boundaries roughly match system boundaries), some misalignments identified but not resolved, rationale provided",
+        "4": "Good alignment (team boundaries match desired architecture), reverse Conway maneuver applied, current misalignments identified and transition plan addresses them",
+        "5": "Exemplary: Perfect architecture-team alignment (each team owns complete bounded context/service), reverse Conway maneuver explicitly applied (designed teams to produce desired architecture), current Conway violations identified with evidence (coordination bottlenecks, tightly-coupled modules despite team separation), team boundaries match system boundaries 1:1 (or clear rationale for deviation), interface contracts between teams = interface contracts between systems, team communication patterns designed to enable desired system evolution, fracture planes identified for future team splitting"
+      }
+    },
+    {
+      "name": "Team Structure Design Quality",
+      "weight": 1.4,
+      "scale": {
+        "1": "Arbitrary team structure (no rationale), team sizes unrealistic (<3 or >15), ownership unclear (shared code ownership, no clear boundaries)",
+        "2": "Some rationale but weak (based on politics not principles), team sizes sometimes problematic, ownership boundaries fuzzy",
+        "3": "Reasonable team structure with some rationale, team sizes mostly 5-12, ownership generally clear but some overlaps, team types not specified",
+        "4": "Well-designed structure (Team Topologies applied: stream/platform/enabling/subsystem), team sizes 5-9, clear ownership boundaries, cognitive load considered",
+        "5": "Exemplary: Optimal team topology (4 fundamental types applied correctly: stream-aligned for products, platform for shared services, enabling for capability building, complicated-subsystem for deep specialties), team sizes follow 2-pizza rule (5-9) with rationale for deviations, cognitive load explicitly managed (1 simple domain, 2-3 related, or max 1 complex per team), ownership boundaries crystal clear (bounded contexts from DDD), team interaction modes defined (collaboration temporary, X-as-a-Service for stable, facilitating time-boxed), evolution path from current to target state with intermediate steps, staffing model defined (platform: 1 engineer per 7-10 product engineers)"
+      }
+    },
+    {
+      "name": "Team Interface Contracts Clarity",
+      "weight": 1.4,
+      "scale": {
+        "1": "No interfaces defined, or vague ('teams will collaborate'), ownership of interfaces unclear, no SLAs, no contact/escalation info",
+        "2": "Interfaces listed but not specified (no APIs, no SLAs, no handoff protocols), ownership mentioned but not documented, minimal contact info",
+        "3": "Basic interface contracts (APIs or workflows identified, some SLAs, contact info), ownership assigned but not detailed, handoffs described generally",
+        "4": "Good interface contracts (APIs with endpoints, SLAs with metrics, handoff protocols with triggers/inputs/outputs, decision rights with DACI), every interface has clear owner",
+        "5": "Exemplary: Complete interface specifications for every team boundary: Technical interfaces (API contracts with endpoints, data formats, auth, rate limits, versioning, documentation links, performance SLAs with p50/p95/p99 targets, availability SLAs with uptime %, support SLAs with response times), Organizational interfaces (handoff protocols with triggers/inputs/outputs/timelines for Design→Eng, Eng→QA, Eng→Support, Research→Product), Decision rights (DACI for each decision type with exactly one Approver, Contributors, Informed stakeholders), Team API documented (what we provide, how to reach us, interaction modes, SLAs), every interface has single clear owner (name + contact + escalation path), monitoring and alerting defined for SLA violations"
+      }
+    },
+    {
+      "name": "Capability Maturity Assessment Rigor",
+      "weight": 1.3,
+      "scale": {
+        "1": "No maturity assessment, or purely subjective ('we're pretty good'), no evidence, no benchmarks",
+        "2": "Vague maturity claims ('we need to improve testing') without levels or evidence, no structured assessment framework",
+        "3": "Some structured assessment (DORA or CMM levels) but incomplete, current state assessed but not all capabilities, some evidence provided, gaps identified generally",
+        "4": "Structured assessment using standard frameworks (DORA, CMMC, CMM), current state with evidence, target state defined, gaps identified, action items with owners",
+        "5": "Exemplary: Rigorous capability maturity assessment using appropriate frameworks (DORA for DevOps, CMMC for security, CMM for process, custom rubrics for domain-specific), each capability rated on 1-5 scale with specific evidence (metrics like deployment frequency: 2x/month, MTTR: 4 hours; artifacts like runbooks, dashboards; observations from team surveys), current state realistic (not aspirational—evidence-based), target state justified (why this level? business value?), gap analysis detailed (what's missing: specific tools, processes, skills), action items SMART (specific actions, measurable outcomes, assigned owners, realistic timelines, time-bound), external benchmarks used where available (DORA Elite/High/Medium/Low percentiles)"
+      }
+    },
+    {
+      "name": "Transition Plan Feasibility & Governance",
+      "weight": 1.3,
+      "scale": {
+        "1": "No transition plan, or unrealistic (big bang with no risk mitigation), no governance, no success metrics, no communication plan",
+        "2": "Vague transition plan ('we'll migrate over 6 months') without phases, weak governance (no decision authority), no metrics, minimal communication",
+        "3": "Basic transition plan (phases identified), some governance (steering committee), process metrics, general communication plan, some risks identified",
+        "4": "Good transition plan (incremental or pilot approach, phases with success criteria, risk mitigation), clear governance (decision authority, review cadence), success metrics baselined, communication plan by audience",
+        "5": "Exemplary: Detailed transition plan with approach justified (big bang/incremental/pilot/hybrid with rationale), phases defined (3-5 phases with timelines, goals, teams affected, specific changes, success criteria, risks with mitigations), governance structure (steering committee for go/no-go, working group for execution, escalation path defined, review cadence: weekly/monthly/quarterly), success metrics (process: migration timeline, teams transitioned; outcome: DORA metrics, team satisfaction, cross-team dependencies, all baselined with targets), communication plan (audience-specific: all employees/affected teams/leadership/stakeholders, what to communicate, when, which channel), rollback plan if transition fails, celebration milestones for momentum"
+      }
+    },
+    {
+      "name": "Org Design Principles Adherence",
+      "weight": 1.2,
+      "scale": {
+        "1": "Violates core principles (matrix hell with unclear accountability, shared ownership anti-patterns, teams too large >15 or too small <3, excessive coordination required)",
+        "2": "Some principle violations (unclear decision rights, some shared ownership, team sizes sometimes problematic, high coordination overhead not addressed)",
+        "3": "Mostly follows principles (team sizes reasonable, ownership generally clear, decision rights defined, some coordination needed), few violations with weak rationale",
+        "4": "Adheres to principles (team sizes 5-9, clear ownership, explicit decision rights, minimal coordination overhead, cognitive load managed), violations have good rationale",
+        "5": "Exemplary: Strictly adheres to all principles: Team sizes (5-9 people, 2-pizza rule, Dunbar's number constraints respected), Cognitive load (1 simple domain, 2-3 related, or max 1 complex per team, <10% time in cross-team coordination), Clear ownership (every system/service has exactly one owning team, no shared code ownership), Decision rights (RACI/DACI with exactly one Accountable per decision, no matrix ambiguity), Interface clarity (every interface has owner, documented contracts, measurable SLAs), Autonomy (teams can deploy independently >80% of time), Conway's Law alignment (team structure = desired architecture), Violations explicitly documented with strong rationale and mitigation"
+      }
+    },
+    {
+      "name": "Actionability & Practicality",
+      "weight": 1.1,
+      "scale": {
+        "1": "Purely theoretical, no concrete steps, unclear how to implement, no consideration of practical constraints (hiring, budget, politics)",
+        "2": "Some concrete steps but vague ('form platform team'), doesn't address practical constraints, unclear execution path, no ownership",
+        "3": "Reasonably actionable (specific teams to form, general timelines, some constraints addressed), execution path somewhat clear, some ownership assigned",
+        "4": "Actionable design (specific actions, realistic timelines, constraints addressed, ownership clear), execution path clear, risk mitigation planned",
+        "5": "Exemplary: Completely actionable with detailed execution plan: Specific actions (hire 3 platform engineers, split Checkout team on Oct 1, define API contracts by Nov 1), realistic timelines accounting for hiring/onboarding/ramp-up, practical constraints addressed (budget: platform team = $800K/year, existing team reshuffle before external hiring, political dynamics: sponsor identified for each team change), ownership explicit (named individuals or specific roles: 'Platform Team Lead: Alex Chen'), dependencies tracked (can't launch platform until CI/CD automated), assumptions documented ('assumes we can hire senior engineers in Q4—mitigation: start recruiting in Q3'), would survive 'Can we actually do this?' test from experienced engineering leaders"
+      }
+    }
+  ],
+  "guidance": {
+    "by_org_size": {
+      "startup_small": {
+        "size": "<30 people",
+        "team_structure": "1-3 cross-functional teams, no platform team yet (premature), all stream-aligned",
+        "interfaces": "Informal, lightweight, focus on communication over documentation",
+        "maturity": "Basic levels (ad-hoc to repeatable), focus on survival and product-market fit",
+        "stakeholders": "Small group (founders, early employees, investors, key customers)",
+        "typical_score": "Aim for 3.0-3.5 (functional design, not over-engineered)"
+      },
+      "scaleup_medium": {
+        "size": "30-150 people",
+        "team_structure": "4-15 stream-aligned teams, emerging platform team (1-2), possibly enabling team",
+        "interfaces": "Documented APIs, basic SLAs, clear handoffs, RACI for key decisions",
+        "maturity": "Repeatable to defined (DORA High/Medium), focus on standardization",
+        "stakeholders": "Multiple layers (exec, directors, managers, ICs, customers, partners)",
+        "typical_score": "Aim for 3.5-4.0 (solid design with some sophistication)"
+      },
+      "large_enterprise": {
+        "size": "150+ people",
+        "team_structure": "Many stream teams organized in tribes/platforms, multiple platform teams (federated), enabling teams, complicated-subsystem teams for specialties",
+        "interfaces": "Full API contracts, rigorous SLAs, comprehensive handoff protocols, DACI for all decision types",
+        "maturity": "Defined to optimizing (DORA Elite/High), focus on continuous improvement and innovation",
+        "stakeholders": "Complex ecosystem (internal: many layers, external: customers, partners, regulators, board)",
+        "typical_score": "Aim for 4.0-5.0 (sophisticated design, proven patterns)"
+      }
+    },
+    "by_change_type": {
+      "greenfield_new_org": {
+        "focus": "Design from scratch, no legacy constraints, optimize for target state",
+        "conways_law": "Design teams to match desired architecture (reverse Conway maneuver)",
+        "transition": "Hire into structure, big bang formation",
+        "challenges": "No existing team dynamics to leverage, everything new, high coordination to establish norms",
+        "typical_score": "Aim for 4.0-4.5 (clean slate enables better design)"
+      },
+      "restructure_existing": {
+        "focus": "Transition from current to target, manage people through change, legacy constraints",
+        "conways_law": "Identify current misalignments, plan transition addressing Conway violations",
+        "transition": "Incremental or pilot, manage resistance, communication critical",
+        "challenges": "Politics, sunk cost (existing teams), fear of change, coordination overhead during transition",
+        "typical_score": "Aim for 3.5-4.0 (constrained by legacy, focus on feasibility)"
+      },
+      "optimization_tuning": {
+        "focus": "Small adjustments to existing structure, interface improvements, capability upgrades",
+        "conways_law": "Minor realignments, extract platform or enabling teams from existing",
+        "transition": "Low-risk changes, quick wins, continuous improvement",
+        "challenges": "Incremental, may not address root causes if fundamental misalignment exists",
+        "typical_score": "Aim for 3.0-3.5 (incremental improvements)"
+      }
+    }
+  },
+  "common_failure_modes": {
+    "conways_law_ignored": {
+      "symptom": "Team structure doesn't match desired architecture. Example: Monolithic teams (Frontend, Backend, QA, DevOps) trying to build microservices → coordination nightmare, slow delivery.",
+      "root_cause": "Org design done in isolation from architecture design. Assuming team structure can be independent of system structure.",
+      "fix": "Reverse Conway maneuver: Design teams to match desired architecture. If want microservices, create teams per service with full-stack ownership. If want modular monolith, create teams per module."
+    },
+    "shared_ownership": {
+      "symptom": "Multiple teams 'share' ownership of service/system. Nobody feels accountable. Changes require coordination. Bugs fall through cracks.",
+      "root_cause": "Trying to maximize resource utilization or avoid 'siloing'. Misunderstanding that autonomy requires clear boundaries.",
+      "fix": "Every system/service has exactly one owning team. If system too large, split it. If team too small to own separately, merge teams but give clear combined ownership."
+    },
+    "no_interfaces": {
+      "symptom": "Teams expected to 'collaborate' but no defined interfaces. Constant meetings to coordinate. Unclear who to ask for what. No SLAs.",
+      "root_cause": "Belief that documentation and contracts are bureaucratic overhead. Informal works for small orgs, breaks at scale.",
+      "fix": "Document Team API for every team: What services provided (endpoints, SLAs), how to communicate (Slack, email, office hours), interaction modes (X-as-a-Service preferred, collaboration time-boxed)."
+    },
+    "unrealistic_maturity": {
+      "symptom": "Maturity assessment inflated ('we're Level 4') without evidence. Gaps underestimated. Action items vague ('improve testing').",
+      "root_cause": "Grading on aspirations not reality. Desire to look good. Lack of external benchmarks.",
+      "fix": "Evidence-based assessment only. Use metrics (deployment frequency: 2x/month = DORA Medium), artifacts (have runbooks? yes/no), observations (team survey: 60% say deployments scary). Compare to external benchmarks (DORA, CMMC). Be honest about current state—only then can you improve."
+    },
+    "matrix_hell": {
+      "symptom": "Dual reporting lines, unclear accountability, slow decisions ('need to check with both managers'), teams unsure who approves what.",
+      "root_cause": "Trying to get benefits of multiple structures (functional expertise + product alignment) without accepting tradeoffs.",
+      "fix": "Minimize matrix. If unavoidable: Define primary vs secondary manager explicitly. Use RACI/DACI for all decisions (exactly one Approver). Establish clear decision rights (tech decisions: tech lead; people decisions: people manager)."
+    },
+    "no_transition_plan": {
+      "symptom": "Beautiful target state design but no plan to get there. Big bang approach with no risk mitigation. Undefined governance. No metrics.",
+      "root_cause": "Focus on end state, not journey. Underestimating change management difficulty.",
+      "fix": "Incremental or pilot transition (not big bang). Phases with success criteria. Governance (steering, working group). Success metrics baselined. Communication plan. Rollback option if fails."
+    },
+    "team_size_violations": {
+      "symptom": "Teams of 2 people (fragile, lack skills) or 20 people (coordination overhead, subgroups form).",
+      "root_cause": "Not applying team size constraints (2-pizza, Dunbar). Trying to optimize for utilization not effectiveness.",
+      "fix": "Teams 5-9 people. If <5: Merge teams or accept fragility with cross-training. If >12: Split using natural seam (product area, service boundary, user journey)."
+    },
+    "ignoring_cognitive_load": {
+      "symptom": "Teams overwhelmed, owning too many systems/domains, spending >20% time in coordination meetings, constant context switching.",
+      "root_cause": "Assigning work based on capacity without considering cognitive limits. Treating teams as resource pools.",
+      "fix": "Limit cognitive load: 1 simple domain, 2-3 related domains, or max 1 complex domain per team. If team overloaded, reduce scope (extract platform team for infrastructure) or split team (cell division along domain boundary)."
+    }
+  },
+  "excellence_indicators": [
+    "All stakeholders identified including informal influencers",
+    "Power-interest matrix with evidence, RACI with exactly one Accountable per decision",
+    "Conway's Law alignment verified (team boundaries = system boundaries)",
+    "Team sizes 5-9 (2-pizza rule), cognitive load managed (<10% time in coordination)",
+    "Team types appropriate (stream-aligned, platform, enabling, complicated-subsystem)",
+    "Every team interface documented (API contracts, SLAs, handoffs, decision rights)",
+    "SLAs measurable (99.9% uptime, <100ms p95 latency, 1hr critical response)",
+    "Every interface has single clear owner with contact/escalation",
+    "Maturity assessed with evidence (metrics, artifacts, observations), not aspirations",
+    "External benchmarks used (DORA percentiles, CMMC levels)",
+    "Transition plan realistic (incremental/pilot, not big bang without mitigation)",
+    "Governance defined (decision authority, review cadence, escalation path)",
+    "Success metrics baselined with targets (DORA, team satisfaction, dependencies)",
+    "Communication plan audience-specific (employees, teams, leadership, stakeholders)",
+    "Principles adhered to (no shared ownership, clear decision rights, manageable coordination)",
+    "Design survives 'Would this work in practice?' test from experienced leaders",
+    "Assumptions and risks documented explicitly"
+  ]
+}
--- a/skills/stakeholders-org-design/resources/methodology.md
+++ b/skills/stakeholders-org-design/resources/methodology.md
@@ -0,0 +1,457 @@
+# Advanced Organizational Design Methodology
+
+## Workflow
+
+```
+Advanced Org Design Progress:
+- [ ] Step 1: Conway's Law analysis and reverse Conway maneuver
+- [ ] Step 2: Team Topologies design
+- [ ] Step 3: Domain-Driven Design alignment
+- [ ] Step 4: Advanced stakeholder techniques
+- [ ] Step 5: Organizational change patterns
+```
+
+**Step 1**: Conway's Law analysis - Understand current architecture-team misalignment. See [1. Conway's Law & Reverse Conway Maneuver](#1-conways-law--reverse-conway-maneuver).
+
+**Step 2**: Team Topologies - Apply 4 fundamental types + 3 interaction modes. See [2. Team Topologies Framework](#2-team-topologies-framework).
+
+**Step 3**: Domain-Driven Design - Align bounded contexts with team boundaries. See [3. Domain-Driven Design Alignment](#3-domain-driven-design-alignment).
+
+**Step 4**: Advanced stakeholder techniques - Influence networks, coalition building. See [4. Advanced Stakeholder Techniques](#4-advanced-stakeholder-techniques).
+
+**Step 5**: Organizational change - Transformation patterns, resistance management. See [5. Organizational Change Patterns](#5-organizational-change-patterns).
+
+---
+
+## 1. Conway's Law & Reverse Conway Maneuver
+
+### Conway's Law Statement
+
+**"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."** — Melvin Conway, 1967
+
+**Practical Implications:**
+- If you have 4 teams, you'll produce a system with 4 major components
+- If backend and frontend are separate teams, you'll get a clear backend/frontend split (potentially with API bloat)
+- If teams don't communicate, systems won't integrate well
+
+### Reverse Conway Maneuver
+
+**Principle**: Design team structure to match desired system architecture, not current org structure.
+
+**Process:**
+1. **Design target architecture** (microservices, modular monolith, etc.)
+2. **Identify system boundaries** (services, modules, domains)
+3. **Create teams matching boundaries** (one team per service/domain)
+4. **Define clear interfaces** (APIs between teams = APIs between systems)
+
+**Example: Microservices Transition**
+
+**Current State (misaligned):**
+- Monolithic team structure: Frontend team, Backend team, Database team, QA team
+- Want: Microservices architecture (User Service, Payment Service, Notification Service)
+- Problem: No team owns end-to-end service
+
+**Target State (aligned):**
+- User Service Team (owns frontend + backend + DB + deployment)
+- Payment Service Team (owns frontend + backend + DB + deployment)
+- Notification Service Team (owns frontend + backend + DB + deployment)
+- Platform Team (provides shared infrastructure, monitoring, deployment tools)
+
+**Result**: Teams naturally build microservices because that's their ownership boundary.
+
+### Architecture-Team Alignment Matrix
+
+| Architecture Style | Recommended Team Structure | Anti-pattern |
+|--------------------|---------------------------|--------------|
+| Monolith | Single cross-functional team (if <50 people) | Functional silos (FE/BE/QA teams) |
+| Modular Monolith | Teams per module with clear interfaces | Shared code ownership across teams |
+| Microservices | Teams per service, full-stack ownership | Shared service ownership |
+| Microfrontends | Teams per micro-app + platform team | Single frontend team for all micro-apps |
+| Platform/API | Product teams (consumers) + Platform team (provider) | Product teams building own platforms |
+
+### Detecting Conway's Law Violations
+
+**Symptoms:**
+- Architecture constantly diverging from intended design
+- Excessive coordination needed for simple changes
+- Modules/services tightly coupled despite supposed independence
+- Teams unable to deploy independently
+
+**Diagnostic Questions:**
+1. Do team boundaries match system boundaries?
+2. Can teams deploy without coordinating with other teams?
+3. Do frequent changes require cross-team sync meetings?
+4. Are interfaces well-defined or constantly renegotiated?
+
+**Fix**: Realign teams to match desired architecture OR redesign architecture to match practical team constraints.
+
+---
+
+## 2. Team Topologies Framework
+
+### Four Fundamental Team Types
+
+**1. Stream-Aligned Teams** (Product/Feature Teams)
+- **Purpose**: Aligned with flow of business change (features, products, user journeys)
+- **Characteristics**: Cross-functional, close to customer, fast flow
+- **Size**: 5-9 people
+- **Cognitive Load**: 1 product area, 1-2 user journeys
+- **Example**: Checkout Team (owns entire checkout experience), Search Team, Recommendations Team
+
+**2. Platform Teams** (Internal Product Teams)
+- **Purpose**: Reduce cognitive load of stream-aligned teams by providing internal services
+- **Characteristics**: Treat stream-aligned teams as customers, self-service, clear SLAs
+- **Size**: Larger (10-15 people) or multiple smaller platform teams
+- **Examples**: Developer Experience Platform (CI/CD, testing frameworks), Data Platform (analytics, ML infrastructure), Infrastructure Platform (AWS, Kubernetes)
+
+**3. Enabling Teams** (Capability Building)
+- **Purpose**: Build capability in stream-aligned teams (temporary, not permanent dependency)
+- **Characteristics**: Coaches not doers, time-boxed engagements (3-6 months), transfer knowledge then leave
+- **Size**: Small (2-5 people), specialists
+- **Examples**: Security Enablement (teach teams secure coding), Accessibility Enablement, Performance Optimization Enablement
+
+**4. Complicated-Subsystem Teams** (Specialists)
+- **Purpose**: Own complex subsystems requiring deep expertise
+- **Characteristics**: Specialist knowledge, reduce cognitive load on stream teams
+- **Size**: Small (3-8 people), domain experts
+- **Examples**: ML/AI team, Video encoding team, Payment processing team, Cryptography team
+
+### Three Team Interaction Modes
+
+**1. Collaboration Mode** (High Interaction)
+- **When**: Discovery, rapid innovation, solving novel problems
+- **Duration**: Temporary (weeks to months)
+- **Example**: Stream team collaborates with enabling team to learn new capability
+- **Characteristics**: High overlap, pair programming, joint problem-solving
+- **Warning**: Don't make permanent—high cognitive load
+
+**2. X-as-a-Service Mode** (Low Interaction)
+- **When**: Clear interface, stable requirements, proven solution
+- **Duration**: Permanent
+- **Example**: Stream team consumes platform team's CI/CD service
+- **Characteristics**: Self-service, clear SLA, API-first, minimal meetings
+- **Goal**: Reduce cognitive load, enable autonomy
+
+**3. Facilitating Mode** (Temporary Support)
+- **When**: Building new capability, unblocking stream team
+- **Duration**: Time-boxed (weeks to months)
+- **Example**: Enabling team teaches stream team performance testing
+- **Characteristics**: Knowledge transfer, workshops, pairing, then exit
+- **Goal**: Leave stream team self-sufficient
+
+### Team Topology Evolution
+
+**Stage 1: Single Team** (Startup, <10 people)
+- One stream-aligned team owns everything
+- No platform team yet (premature optimization)
+
+**Stage 2: Multiple Stream Teams** (Scale-up, 10-30 people)
+- 2-4 stream-aligned teams
+- Start seeing duplication (deployment, monitoring, data)
+- Platform team emerges from common pain
+
+**Stage 3: Stream + Platform** (Growth, 30-100 people)
+- 4-10 stream-aligned teams
+- 1-2 platform teams (developer experience, data, infrastructure)
+- Possibly 1 enabling team for critical capability gaps
+
+**Stage 4: Mature Topology** (Large, 100+ people)
+- Many stream-aligned teams (organized by value stream)
+- Multiple platform teams (federated platforms)
+- Enabling teams for strategic capabilities
+- Complicated-subsystem teams for deep specialties
+
+### Team API Design
+
+**Every team should document their "Team API":**
+
+1. **Code API**: What services/libraries do we provide? (Endpoints, SDKs, packages)
+2. **Documentation API**: What docs are available? (README, runbooks, architecture diagrams)
+3. **Communication API**: How to reach us? (Slack, email, office hours, on-call)
+4. **Collaboration API**: How to work with us? (Interaction mode, meeting cadence, decision process)
+
+**Template:**
+```
+Team: [Name]
+Type: [Stream-Aligned / Platform / Enabling / Complicated-Subsystem]
+
+Services Provided:
+- Service A: [Description] - SLA: [99.9% uptime]
+- Service B: [Description] - SLA: [<100ms p95]
+
+Documentation:
+- Architecture: [Link]
+- API Docs: [Link]
+- Runbooks: [Link]
+
+Communication:
+- Slack: #team-name
+- Email: team@company.com
+- Office Hours: Tuesdays 2-3pm
+- On-call: [PagerDuty link]
+
+Interaction Modes:
+- X-as-a-Service: Use our APIs (preferred)
+- Collaboration: For new integrations (time-boxed to 2 weeks)
+- Facilitation: We can teach your team [capability] (3-month engagement)
+```
+
+---
+
+## 3. Domain-Driven Design Alignment
+
+### Bounded Contexts & Team Boundaries
+
+**Principle**: Align team boundaries with bounded contexts (not just technical layers).
+
+**Bounded Context**: A conceptual boundary within which a domain model is consistent. Different contexts may have different models for same concept.
+
+**Example: E-commerce**
+- **Shopping Context**: Product (SKU, description, price, inventory)
+- **Fulfillment Context**: Product (tracking number, shipping address, delivery status)
+- **Analytics Context**: Product (page views, conversion rate, revenue)
+
+**Same entity ("Product"), different models, different teams.**
+
+### Context Mapping Patterns
+
+**1. Partnership** (Two teams collaborate closely)
+- Symmetric relationship, joint planning
+- Example: Checkout team + Payment team for new payment flow
+
+**2. Shared Kernel** (Small shared code/data)
+- Minimal shared model, high coordination cost
+- Example: Shared customer ID schema across all teams
+- Warning: Keep tiny—big shared kernels become bottlenecks
+
+**3. Customer-Supplier** (Upstream provides to Downstream)
+- Asymmetric relationship, SLA-based
+- Example: User Auth service (upstream) provides to all product teams (downstream)
+- Supplier responsible for meeting customer needs
+
+**4. Conformist** (Downstream conforms to Upstream)
+- Downstream has no influence on upstream
+- Example: Product teams conform to external payment provider API
+- Necessary when integrating third-party services
+
+**5. Anti-Corruption Layer** (Translation Layer)
+- Protect your model from external complexity
+- Example: Wrapper around legacy system to present clean API
+- Use when upstream is messy but you can't change it
+
+**6. Separate Ways** (No integration)
+- Contexts too different to integrate economically
+- Example: HR system and product analytics—no overlap
+
+### Team-to-Context Alignment
+
+**Rule**: One team per bounded context (ideally).
+
+**Options if context too large for one team:**
+1. **Split context**: Find natural seam within bounded context
+2. **Multiple teams share**: Requires tight coordination (expensive)
+3. **Sub-teams within**: Maintain as one logical team, sub-teams for focus areas
+
+**Options if team owns multiple contexts:**
+1. **OK if contexts small** and tightly related
+2. **Watch cognitive load**: Max 2-3 simple contexts per team
+
+---
+
+## 4. Advanced Stakeholder Techniques
+
+### Influence Network Analysis
+
+**Social Network Analysis for Organizations:**
+
+1. **Identify nodes**: All stakeholders
+2. **Map edges**: Who influences whom? (direction matters)
+3. **Calculate centrality**:
+   - **Degree centrality**: Number of connections (who's most connected?)
+   - **Betweenness centrality**: Who bridges disconnected groups? (critical connectors)
+   - **Closeness centrality**: Who can reach everyone quickly? (efficient communicators)
+
+**Application:**
+- **High betweenness**: Critical bridges—if they leave or resist, networks fragment
+- **High degree**: Opinion leaders—influence many directly
+- **Low centrality but critical domain**: Hidden experts—engage directly
+
+### Coalition Building
+
+**For Major Organizational Change:**
+
+**Phase 1: Identify Minimum Winning Coalition**
+- What's minimum set of stakeholders needed to approve change?
+- Who has veto power? (must include)
+- Who has high influence? (prioritize)
+
+**Phase 2: Address WIIFM (What's In It For Me)**
+- For each coalition member: What do they gain from this change?
+- If nothing: Can we adjust proposal to create gains?
+- Document value proposition per stakeholder
+
+**Phase 3: Sequence Engagement**
+- Start with champions (easy wins)
+- Then bridges (access to networks)
+- Then high-power neutrals (sway with champion support)
+- Finally address blockers (after coalition established)
+
+**Phase 4: Manage Defection**
+- Monitor for coalition members changing stance
+- Regular check-ins, address concerns early
+- Adjust proposal if needed to maintain coalition
+
+### Resistance Management
+
+**Kotter's 8-Step Change Model:**
+1. Create urgency (burning platform)
+2. Form guiding coalition (power + credibility)
+3. Develop vision (clear future state)
+4. Communicate vision (over-communicate 10x)
+5. Empower action (remove obstacles)
+6. Generate short-term wins (momentum)
+7. Consolidate gains (don't declare victory early)
+8. Anchor changes (make it "how we do things")
+
+**Resistance Patterns:**
+
+| Resistance Type | Symptom | Root Cause | Strategy |
+|-----------------|---------|------------|----------|
+| Rational | "This won't work because [data]" | Legitimate concerns | Address with analysis, pilot to test |
+| Emotional | "I don't like this" | Fear, loss of status/control | Empathy, involvement, WIIFM |
+| Political | "I'll block this" | Power play, competing agenda | Coalition, escalation, negotiation |
+| Cultural | "Not how we do things here" | Clashes with norms/values | Small wins, demonstrate compatibility |
+
+---
+
+## 5. Organizational Change Patterns
+
+### Spotify Model (Modified)
+
+**Squads** (Stream-aligned teams, 5-9 people)
+- Cross-functional, autonomous, long-lived
+- Own features end-to-end
+- Aligned with product areas
+
+**Tribes** (Collection of related squads, 40-150 people)
+- Share mission, loosely coordinated
+- Tribe lead facilitates, doesn't dictate
+- Regular tribe gatherings (demos, planning)
+
+**Chapters** (Functional expertise groups within tribe)
+- Engineers from different squads, same skill
+- Led by chapter lead (line manager)
+- Knowledge sharing, standards, career development
+
+**Guilds** (Communities of practice across tribes)
+- Voluntary, interest-based
+- Share knowledge org-wide (security, testing, frontend)
+- No formal authority, influence through expertise
+
+**When to Use:**
+- Large product orgs (100+ people)
+- Need autonomy + alignment
+- Strong engineering culture
+
+**When NOT to Use:**
+- Small orgs (<50 people) - too much overhead
+- Weak engineering culture - guilds/chapters won't self-organize
+- Highly regulated - too much autonomy
+
+### Amazon's Two-Pizza Teams
+
+**Principles:**
+- Team size: 5-9 people (can feed with 2 pizzas)
+- Fully autonomous: Own service end-to-end
+- APIs only: Teams communicate via documented APIs
+- You build it, you run it: Own production operations
+
+**Supporting Infrastructure:**
+- Service-oriented architecture (technical enabler)
+- Self-service platform (AWS, deployment tools)
+- Clear metrics (each team has dashboard)
+
+**Results:**
+- Reduced coordination overhead
+- Faster innovation
+- Clear accountability
+
+**Challenges:**
+- Requires mature platform (or teams duplicate infrastructure)
+- API versioning complexity
+- Potential for silos if over-isolated
+
+### Platform Team Extraction
+
+**When to Extract Platform Team:**
+- **Signal 1**: 3+ stream teams duplicating infrastructure work
+- **Signal 2**: Stream teams slowed by infrastructure
+ tasks (>20% time)
+- **Signal 3**: Infrastructure quality suffering (monitoring gaps, deployment issues)
+
+**How to Extract:**
+1. **Identify common pain** across stream teams (deployment, monitoring, data)
+2. **Form platform team** (pull volunteers from stream teams who enjoy infrastructure)
+3. **Define charter**: What platform provides, what it doesn't
+4. **Set SLAs**: Treat stream teams as customers
+5. **Build self-service**: Documentation, automation, APIs
+6. **Iterate**: Start small, expand based on demand
+
+**Staffing Ratio:**
+- **Rule of thumb**: 1 platform engineer per 7-10 product engineers
+- **Too many platform**: Over-engineering, bloat
+- **Too few platform**: Can't keep up with demand
+
+**Success Metrics:**
+- Stream team velocity (should increase after platform stabilizes)
+- Time to deploy (should decrease)
+- Platform adoption (% of stream teams using platform services)
+- Platform team satisfaction survey (NPS from stream teams)
+
+### Organizational Refactoring Patterns
+
+**Pattern 1: Cell Division** (Split large team)
+- **When**: Team >12 people, communication overhead high
+- **How**: Identify natural seam in ownership, split into 2 teams
+- **Example**: E-commerce team → Catalog team + Checkout team
+
+**Pattern 2: Merging** (Combine small teams)
+- **When**: Teams <4 people, lack skill diversity, too much coordination
+- **How**: Merge related teams, clarify combined ownership
+- **Example**: Frontend team + Backend team → Full-stack product team
+
+**Pattern 3: Extraction** (Pull out specialists)
+- **When**: Specialized need emerging across teams
+- **How**: Form complicated-subsystem or platform team
+- **Example**: Extract data engineers from product teams → Data Platform team
+
+**Pattern 4: Embedding** (Integrate specialists)
+- **When**: Specialist team bottleneck, stream teams need capability
+- **How**: Embed specialists into stream teams, dissolve central team
+- **Example**: Embed QA engineers into product teams, close central QA team
+
+---
+
+## 6. Measuring Organizational Effectiveness
+
+**Accelerate Metrics (beyond DORA):**
+- **Team autonomy**: % decisions made without escalation
+- **Psychological safety**: Team survey (Edmondson scale)
+- **Documentation quality**: % questions answerable via docs
+- **Cognitive load**: % time on primary mission vs toil/coordination
+
+**Org Design Quality Indicators:**
+- [ ] <10% time in cross-team coordination meetings
+- [ ] Teams can deploy independently (>80% deploys don't require sync)
+- [ ] Clear ownership (anyone can name team owning any component in <30 seconds)
+- [ ] Fast onboarding (new hire productive in <2 weeks)
+- [ ] Low turnover (voluntary attrition <10%/year)
+- [ ] High engagement (survey scores ≥4/5)
+
+**Anti-patterns:**
+- Conway's Law violations (architecture ≠ team structure)
+- Shared code ownership (nobody accountable)
+- Teams too large (>12) or too small (<3)
+- Matrix hell (dual reporting, unclear decision rights)
+- Platform teams building for themselves (not customer-focused)
+- Permanent collaboration mode (high cognitive load, burnout)
--- a/skills/stakeholders-org-design/resources/template.md
+++ b/skills/stakeholders-org-design/resources/template.md
@@ -0,0 +1,396 @@
+# Stakeholders & Organizational Design Template
+
+## Workflow
+
+Copy this checklist and track your progress:
+
+```
+Org Design Progress:
+- [ ] Step 1: Map stakeholders and influence
+- [ ] Step 2: Define team structure and boundaries
+- [ ] Step 3: Specify team interfaces and contracts
+- [ ] Step 4: Assess capability maturity
+- [ ] Step 5: Create transition plan with governance
+```
+
+**Step 1: Map stakeholders** - Power-interest matrix, RACI, influence networks. See [Section 1](#1-stakeholder-mapping).
+
+**Step 2: Define teams** - Team topology, size, ownership boundaries. See [Section 2](#2-team-structure-design).
+
+**Step 3: Specify interfaces** - API contracts, SLAs, handoffs, decision rights. See [Section 3](#3-team-interface-contracts).
+
+**Step 4: Assess maturity** - DORA, CMM, custom capability assessments. See [Section 4](#4-capability-maturity-assessment).
+
+**Step 5: Create transition plan** - Migration path, governance, review cadence. See [Section 5](#5-transition-plan).
+
+---
+
+## 1. Stakeholder Mapping
+
+### Organization Context
+
+**Domain/Initiative:**
+- **Name**: [What are we designing/changing]
+- **Scope**: [Boundaries of design/change]
+- **Timeline**: [When does this need to happen]
+- **Drivers**: [Why now? What triggered this?]
+
+### Stakeholder Inventory
+
+List all stakeholders (individuals or groups):
+
+| Stakeholder | Role | Power | Interest | Quadrant |
+|-------------|------|-------|----------|----------|
+| [Name/Group] | [What they do] | High/Low | High/Low | [See below] |
+| [Name/Group] | [What they do] | High/Low | High/Low | [See below] |
+| [Name/Group] | [What they do] | High/Low | High/Low | [See below] |
+
+**Power**: Ability to influence outcome (budget, authority, veto, resources)
+**Interest**: Engagement level, stake in outcome
+
+### Power-Interest Quadrants
+
+**High Power, High Interest** (Manage Closely):
+- [ ] Stakeholder 1: [Name] - [Engagement strategy]
+- [ ] Stakeholder 2: [Name] - [Engagement strategy]
+
+**High Power, Low Interest** (Keep Satisfied):
+- [ ] Stakeholder 3: [Name] - [How to keep satisfied]
+- [ ] Stakeholder 4: [Name] - [How to keep satisfied]
+
+**Low Power, High Interest** (Keep Informed):
+- [ ] Stakeholder 5: [Name] - [How to engage]
+- [ ] Stakeholder 6: [Name] - [How to engage]
+
+**Low Power, Low Interest** (Monitor):
+- [ ] Stakeholder 7: [Name] - [When to update]
+
+### Influence Network
+
+**Champions** (Advocates for change):
+- [Name]: Why champion? What do they gain?
+- [Name]: Why champion? What do they gain?
+
+**Blockers** (Resistors to change):
+- [Name]: Why blocking? What concerns?
+- [Name]: Why blocking? What concerns?
+
+**Bridges** (Connect groups):
+- [Name]: Connects [Group A] to [Group B]
+- [Name]: Connects [Group C] to [Group D]
+
+**Gatekeepers** (Control access):
+- [Name]: Controls access to [Key stakeholder/resource]
+
+### RACI for Key Decisions
+
+| Decision | Responsible | Accountable | Consulted | Informed |
+|----------|-------------|-------------|-----------|----------|
+| Team structure | [Who] | [One person] | [Who,Who] | [Who,Who,Who] |
+| Interface contracts | [Who] | [One person] | [Who,Who] | [Who,Who,Who] |
+| Migration timeline | [Who] | [One person] | [Who,Who] | [Who,Who,Who] |
+| [Custom decision] | [Who] | [One person] | [Who,Who] | [Who,Who,Who] |
+
+**Rule**: Exactly one Accountable per decision. Consulted = provide input before. Informed = notified after.
+
+---
+
+## 2. Team Structure Design
+
+### Current State
+
+**Existing Teams:**
+
+| Team Name | Size | Responsibilities | Problems |
+|-----------|------|------------------|----------|
+| [Team 1] | [#] | [What they own] | [Pain points] |
+| [Team 2] | [#] | [What they own] | [Pain points] |
+| [Team 3] | [#] | [What they own] | [Pain points] |
+
+**Current Structure Type:** [Functional / Product / Matrix / Hybrid]
+
+**Key Problems:**
+- [ ] Problem 1: [Describe]
+- [ ] Problem 2: [Describe]
+- [ ] Problem 3: [Describe]
+
+### Target State
+
+**Team Topology:** [Choose one or hybrid]
+- [ ] **Functional**: Teams organized by skill (Frontend, Backend, QA, DevOps)
+- [ ] **Product/Feature**: Cross-functional teams owning features/products
+- [ ] **Platform**: Product teams + Platform team providing shared services
+- [ ] **Team Topologies**: Stream-aligned + Platform + Enabling + Complicated-subsystem
+
+**Proposed Teams:**
+
+| Team Name | Type | Size | Responsibilities | Owner |
+|-----------|------|------|------------------|-------|
+| [Team A] | [Stream/Platform/Enabling/Subsystem] | [5-9] | [What they own] | [Lead] |
+| [Team B] | [Stream/Platform/Enabling/Subsystem] | [5-9] | [What they own] | [Lead] |
+| [Team C] | [Stream/Platform/Enabling/Subsystem] | [5-9] | [What they own] | [Lead] |
+
+**Team Sizing Principles:**
+- **2-pizza rule**: 5-9 people per team (Amazon model)
+- **Dunbar's number**: 5-15 close working relationships max
+- **Cognitive load**: 1 simple domain, 2-3 related domains, or max 1 complex domain per team
+
+### Team Boundaries & Ownership
+
+**Ownership Model:** [Choose one]
+- [ ] **Full-stack ownership**: Team owns frontend, backend, database, infrastructure for their domain
+- [ ] **Service ownership**: Team owns specific microservices
+- [ ] **Feature ownership**: Team owns features across shared codebase
+- [ ] **Platform ownership**: Team provides internal products/tools to other teams
+
+**Domain Boundaries** (using Domain-Driven Design):
+
+| Bounded Context | Owning Team | Responsibilities | Dependencies |
+|-----------------|-------------|------------------|--------------|
+| [Context A] | [Team X] | [What's in scope] | [Other contexts] |
+| [Context B] | [Team Y] | [What's in scope] | [Other contexts] |
+| [Context C] | [Team Z] | [What's in scope] | [Other contexts] |
+
+### Conway's Law Alignment
+
+**Desired System Architecture:**
+- [Describe target architecture: microservices, modular monolith, etc.]
+
+**Team Structure Alignment:**
+- [How team boundaries map to system boundaries]
+- [Example: Team A owns Service A, Team B owns Service B with well-defined APIs]
+
+**Anti-patterns to Avoid:**
+- [ ] Monolithic team creating microservices (coordination nightmare)
+- [ ] Fragmented teams with shared code ownership (merge conflicts, unclear responsibility)
+
+---
+
+## 3. Team Interface Contracts
+
+### Technical Interfaces (APIs)
+
+**For each team providing services:**
+
+**Service: [Name]**
+- **Owner Team**: [Team name]
+- **Purpose**: [What problem does it solve for consumers?]
+- **Consumers**: [Which teams depend on this?]
+
+**API Contract:**
+- **Endpoints**: [List key endpoints or link to API docs]
+- **Data Format**: [JSON, Protocol Buffers, GraphQL, etc.]
+- **Authentication**: [OAuth, API keys, mTLS, etc.]
+- **Rate Limits**: [Requests per second/minute]
+- **Versioning**: [Semantic versioning, backward compatibility policy]
+- **Documentation**: [Link to API docs, Swagger/OpenAPI spec]
+
+**SLA:**
+- **Availability**: [99.9%, 99.95%, 99.99%]
+- **Performance**: [p50: Xms, p95: Yms, p99: Zms]
+- **Support**: [Critical: 1hr response, High: 4hr, Medium: 1 day]
+- **On-call**: [Rotation schedule, escalation path]
+
+**Contact:**
+- **Slack**: [#team-channel]
+- **Email**: [team@company.com]
+- **On-call**: [PagerDuty link / escalation policy]
+
+### Organizational Interfaces (Workflows)
+
+**Cross-Team Workflows:**
+
+**Workflow: Design → Engineering**
+- **Trigger**: [When does handoff happen?]
+- **Inputs**: [What does Engineering need from Design?]
+  - [ ] Design specs (Figma/Sketch)
+  - [ ] User flows
+  - [ ] Design review sign-off
+  - [ ] Asset exports
+- **Outputs**: [What does Design get back?]
+  - [ ] Implementation feedback
+  - [ ] Edge cases discovered
+- **Timeline**: [How long for handoff? Review cycles?]
+
+**Workflow: Engineering → QA**
+- **Trigger**: Feature complete
+- **Inputs**: Test plan, staging environment, feature documentation
+- **Outputs**: QA report, bugs filed, sign-off for release
+- **Timeline**: 2-3 days QA cycle
+
+**Workflow: Engineering → Support**
+- **Trigger**: Feature launch
+- **Inputs**: Documentation, runbook, training session
+- **Outputs**: Support readiness confirmation
+- **Timeline**: 1 week before launch
+
+### Decision Rights (DACI)
+
+**For each cross-team decision type:**
+
+**Decision Type: [e.g., Architectural changes affecting multiple teams]**
+- **Driver**: [Who runs the decision process] - Example: Tech Lead from Team A
+- **Approver**: [Who makes final call - exactly one] - Example: Principal Architect
+- **Contributors**: [Who provides input] - Example: Team leads from Teams B, C, D
+- **Informed**: [Who is notified] - Example: Engineering VP, all engineers
+
+**Process:**
+1. Driver documents proposal
+2. Contributors review and provide feedback (deadline: X days)
+3. Approver makes decision (deadline: Y days)
+4. Informed stakeholders notified
+
+---
+
+## 4. Capability Maturity Assessment
+
+### DORA Metrics (DevOps Maturity)
+
+| Metric | Current | Target | Gap | Actions |
+|--------|---------|--------|-----|---------|
+| Deployment Frequency | [X/day, /week, /month] | [Elite: Multiple/day] | [Describe gap] | [How to improve] |
+| Lead Time | [X hours/days/weeks] | [Elite: <1 hour] | [Describe gap] | [How to improve] |
+| MTTR | [X hours/days] | [Elite: <1 hour] | [Describe gap] | [How to improve] |
+| Change Failure Rate | [X%] | [Elite: 0-15%] | [Describe gap] | [How to improve] |
+
+**DORA Performance Level**: [Elite / High / Medium / Low]
+
+### Custom Capability Assessments
+
+**Capability: [e.g., Testing Maturity]**
+
+**Current State** (Level 1-5):
+- **Level**: [1-5]
+- **Evidence**: [Metrics, artifacts, observations proving current level]
+- **Description**: [What does maturity look like at this level?]
+
+**Target State**:
+- **Level**: [Target 1-5]
+- **Rationale**: [Why this target? Business value?]
+
+**Gap Analysis**:
+- **Missing**: [What capabilities/processes/tools are missing?]
+- **Needed**: [What needs to change to reach target?]
+
+**Action Items**:
+- [ ] Action 1: [Specific, measurable action] - Owner: [Name] - Deadline: [Date]
+- [ ] Action 2: [Specific, measurable action] - Owner: [Name] - Deadline: [Date]
+- [ ] Action 3: [Specific, measurable action] - Owner: [Name] - Deadline: [Date]
+
+**Repeat for each capability:**
+- [ ] Security maturity
+- [ ] Design maturity
+- [ ] Data maturity
+- [ ] Agile/process maturity
+- [ ] [Custom capability]
+
+---
+
+## 5. Transition Plan
+
+### Migration Path
+
+**Approach:** [Choose one]
+- [ ] **Big Bang**: Switch all at once (risky, fast)
+- [ ] **Incremental**: Migrate team by team (safer, slower)
+- [ ] **Pilot**: Start with one team, learn, then roll out (recommended)
+- [ ] **Hybrid**: Different approaches for different teams
+
+**Phases:**
+
+**Phase 1: [Name] (Timeline: [Dates])**
+- **Goal**: [What we're achieving]
+- **Teams Affected**: [Which teams]
+- **Changes**: [Specific changes happening]
+- **Success Criteria**: [How we know it worked]
+- **Risks**: [What could go wrong]
+- **Mitigations**: [How to reduce risks]
+
+**Phase 2: [Name] (Timeline: [Dates])**
+- [Same structure as Phase 1]
+
+**Phase 3: [Name] (Timeline: [Dates])**
+- [Same structure as Phase 1]
+
+### Governance & Review
+
+**Decision Authority:**
+- **Steering Committee**: [Who makes go/no-go decisions] - Meets: [Frequency]
+- **Working Group**: [Who executes day-to-day] - Meets: [Frequency]
+- **Escalation Path**: [Issue → Working Group → Steering Committee → Executive]
+
+**Review Cadence:**
+- **Weekly**: Working group sync (30 min) - Review progress, blockers
+- **Biweekly**: Stakeholder update (1 hr) - Demos, metrics, ask for help
+- **Monthly**: Steering committee review (1 hr) - Go/no-go gates, course corrections
+- **Quarterly**: Retrospective (2 hr) - What's working, what to adjust
+
+**Communication Plan:**
+
+| Audience | What | When | Channel |
+|----------|------|------|---------|
+| All employees | High-level update | Monthly | All-hands, email |
+| Affected teams | Detailed changes | Weekly | Team meetings, Slack |
+| Leadership | Metrics, risks | Biweekly | Email, slides |
+| Stakeholders | Progress, asks | Monthly | Stakeholder meeting |
+
+### Success Metrics
+
+**Process Metrics:**
+- [ ] Migration timeline: [On track / X weeks ahead/behind]
+- [ ] Teams transitioned: [X / Y teams complete]
+- [ ] Interfaces defined: [X / Y contracts documented]
+
+**Outcome Metrics** (measure 3-6 months post-transition):
+- [ ] Deployment frequency: [Baseline] → [Current] (Target: [X]) | Lead time: [Baseline] → [Current] (Target: [X])
+- [ ] Team satisfaction: [Survey before] → [After] (Target: ≥7/10) | Cross-team dependencies: [Baseline] → [Current] (Target: -30%)
+- [ ] Incident response: [Baseline] → [Current] (Target: +50% faster)
+
+**Qualitative**: Teams feel ownership | Interfaces clear | Stakeholders know who to contact | Faster decisions | Less coordination overhead
+
+---
+
+## Quality Checklist
+
+Before finalizing, verify:
+
+**Stakeholder Mapping:**
+- [ ] All stakeholders identified (didn't miss any groups)
+- [ ] Power-interest assessed for each
+- [ ] Champions and blockers identified
+- [ ] RACI defined for key decisions with exactly one Accountable per decision
+- [ ] Engagement strategy per quadrant
+
+**Team Structure:**
+- [ ] Team boundaries align with desired architecture (Conway's Law)
+- [ ] Team sizes reasonable (5-9 people, 2-pizza rule)
+- [ ] Cognitive load per team manageable (1-3 domains)
+- [ ] Ownership clear (no shared ownership anti-patterns)
+- [ ] Team types appropriate (stream/platform/enabling/subsystem)
+
+**Interfaces:**
+- [ ] API contracts documented (endpoints, SLA, contact)
+- [ ] SLAs realistic and measurable
+- [ ] Handoff protocols clear (design→eng, eng→QA, etc.)
+- [ ] Decision rights explicit (DACI for each decision type)
+- [ ] Every interface has one clear owner
+
+**Maturity:**
+- [ ] Current state assessed with evidence (not aspirations)
+- [ ] Gaps identified between current and target
+- [ ] Action items specific, assigned, with deadlines
+- [ ] Benchmarks used where available (DORA, CMMC, etc.)
+
+**Transition:**
+- [ ] Migration path chosen (big bang, incremental, pilot)
+- [ ] Phases defined with success criteria
+- [ ] Governance structure established (steering, working group)
+- [ ] Review cadence set (weekly, monthly, quarterly)
+- [ ] Success metrics baselined and targets set
+- [ ] Communication plan covers all audiences
+
+**Overall:**
+- [ ] Assumptions documented explicitly
+- [ ] Risks identified with mitigations
+- [ ] Conway's Law alignment checked
+- [ ] Design survives "Would this work in practice?" test