30
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill lyndonkl/claude --skill stakeholders-org-design- SKILL.md12.1 KB
Overview
This skill helps design organizational structure and stakeholder maps to align teams with system architecture and change initiatives. It provides pragmatic templates for team topologies, stakeholder power-interest mapping, team interface contracts (APIs, SLAs, decision rights), and capability maturity assessment. Use it to reduce handoffs, clarify ownership, and plan realistic transitions with governance.
How this skill works
The skill guides you through a five-step workflow: map stakeholders and influence, define team boundaries and topology, specify team interfaces and contracts, assess capability maturity with standard models, and create a transition plan with governance. It inspects stakeholder power and interest, team-to-architecture alignment (Conway's Law), interface ownership and SLAs, and maturity evidence (DORA, CMM, custom rubrics). Outputs include stakeholder matrices, RACI/DACI assignments, interface specs, maturity gaps, and actionable migration steps.
When to use it
- Planning an org restructure (functional → product teams, platform extraction)
- Running a change initiative that needs a stakeholder map and engagement plan
- Defining team interfaces: APIs, SLAs, handoff protocols, decision rights
- Assessing capability maturity using DORA, CMMC, CMM or custom rubrics
- Applying Conway's Law to align team boundaries with desired architecture
Best practices
- Map stakeholders by power-interest and focus engagement where it matters most
- Design teams to mirror desired system boundaries to avoid architecture drift
- Make every interface have one clear owner, SLA, and escalation path
- Use evidence-based maturity scoring; avoid grading on aspiration alone
- Limit team cognitive load and size (2-pizza rule; avoid >12 without substructure)
Example use cases
- Extract a platform team when multiple product teams duplicate infrastructure work and define self-service APIs + SLA
- Convert functional silos into stream-aligned product squads with platform and enabling teams to speed delivery
- Create a stakeholder map for a security rollout identifying champions, blockers, and communication cadence
- Build team interface contracts for an authentication service: endpoints, schema, uptime SLA, owner and runbook
- Assess DevOps maturity with DORA metrics and produce a prioritized action plan to reduce MTTR and lead time
FAQ
Choose embedded when close collaboration is essential and the domain is critical to product flow; choose centralized for deep expertise and consistency. Consider a hybrid: central CoE for standards plus embedded practitioners for day-to-day work.
What evidence should I use for maturity assessments?
Use concrete metrics (deployment frequency, lead time, MTTR, change failure rate), documented processes, runbooks, SLAs, and observed behaviors. Prefer objective artifacts over opinions.