From thinking-frameworks-skills
Maps stakeholder influence networks, designs team structures via Conway's Law, defines interface contracts (APIs/SLAs/decision rights), assesses maturity (DORA/CMMC). For org design, restructures, stakeholder mapping.
npx claudepluginhub lyndonkl/claude --plugin thinking-frameworks-skillsThis skill uses the workspace's default tool permissions.
1. [Workflow](#workflow)
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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.
| 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 |
Identify: Champions (advocates), Blockers (resistors), Bridges (connectors), Gatekeepers (control access) Map: Who influences whom? Formal vs informal power, trust relationships, communication patterns
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
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)
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
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)
| 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% |
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
Template: Capability Name | Current Level (1-5 with evidence) | Target Level | Gap | Action Items
Pattern 1: Functional → Product Teams (Spotify Model)
Pattern 2: Platform Team Extraction
Pattern 3: Embedded vs Centralized Specialists
Pattern 4: Conway's Law Alignment
Pattern 5: Team Topologies (4 Fundamental Types)
Conway's Law is inevitable:
Team size limits:
Cognitive load per team:
Interface ownership clarity:
Avoid matrix hell:
Stakeholder fatigue:
Maturity assessment realism:
Resources:
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