Stakeholders Org Design

Stakeholders & Organizational Design

Table of Contents

1. Purpose
2. When to Use
3. What Is It
4. Workflow
5. Stakeholder Mapping
6. Team Interface Contracts
7. Capability Maturity
8. Common Patterns
9. Guardrails
10. 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 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. For complex org design with Conway's Law → Study resources/methodology.md.

Step 3: Specify team interfaces and contracts

Define APIs, SLAs, handoff protocols, decision rights between teams. See Team Interface Contracts for contract patterns.

Step 4: Assess capability maturity

Evaluate current state using maturity models (DORA, CMMC, custom). See 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. Minimum standard: Average score ≥ 3.5.

Stakeholder Mapping

Power-Interest Matrix

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)