Stats
Actions
Tags
From team-design
Guides team structure design using Team Topologies' four fundamental team types: stream-aligned, platform, enabling, and complicated subsystem teams.
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-design:team-topologiesThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when:
Use this skill when:
Design team structures using the four fundamental team types from Team Topologies.
Before applying Team Topologies:
docs-management skill for team design patternsTeam Topologies Model:
┌─────────────────────────────────────────────────────────────────┐
│ STREAM-ALIGNED TEAMS │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Feature │ │ Feature │ │ Feature │ │
│ │ Team A │ │ Team B │ │ Team C │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌────────────────┴────────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ PLATFORM │ │ ENABLING │ │
│ │ TEAM │ │ TEAM │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ COMPLICATED │ │
│ │ SUBSYSTEM TEAM │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
STREAM-ALIGNED TEAM
Purpose: Primary value delivery, end-to-end ownership
Characteristics:
• Aligned to a single business stream
• Cross-functional (dev, test, ops, UX)
• End-to-end responsibility
• Close to the customer
• Majority of teams should be this type
Responsibilities:
• Own a portion of the value stream
• Deliver features to production
• Respond to customer feedback
• Own operational aspects
• Continuously improve their flow
Examples:
• Checkout Team (e-commerce)
• Mobile App Team
• Customer Onboarding Team
• Payments Team
Anti-patterns:
✗ Depends on many other teams
✗ Blocked frequently
✗ No production ownership
✗ Unclear customer/user
PLATFORM TEAM
Purpose: Reduce cognitive load for stream-aligned teams
Characteristics:
• Treat platform as product
• Internal customers are other teams
• Self-service is the goal
• APIs and documentation focused
• Enable fast flow of stream-aligned teams
Responsibilities:
• Build internal developer platform
• Provide self-service capabilities
• Maintain stability and reliability
• Document and support platform
• Gather feedback from consuming teams
Examples:
• Infrastructure Platform Team
• Developer Experience Team
• Data Platform Team
• Security Platform Team
Platform Thinkables:
┌─────────────────────────────────────────┐
│ PLATFORM LAYERS │
├─────────────────────────────────────────┤
│ Developer Experience │
│ (CLI, portal, templates, docs) │
├─────────────────────────────────────────┤
│ Runtime Platform │
│ (containers, serverless, databases) │
├─────────────────────────────────────────┤
│ Infrastructure │
│ (cloud, networking, security) │
└─────────────────────────────────────────┘
ENABLING TEAM
Purpose: Help stream-aligned teams overcome obstacles
Characteristics:
• Specialists in a particular area
• Temporary engagement model
• Knowledge transfer focus
• Research and evaluate options
• Not doing the work FOR teams
Responsibilities:
• Identify capability gaps
• Research solutions
• Coach and mentor teams
• Help teams adopt new practices
• Measure improvement
Examples:
• DevOps Enablement Team
• Architecture Advisory Team
• Quality Engineering Team
• Agile Coaching Team
Engagement Model:
┌─────────────┐ ┌─────────────┐
│ Enabling │────►│ Stream │
│ Team │ │ Team │
└─────────────┘ └─────────────┘
│
▼
[Time-boxed engagement]
│
▼
[Transfer knowledge & leave]
Anti-patterns:
✗ Permanent dependency created
✗ Doing work instead of enabling
✗ No knowledge transfer
✗ No clear exit criteria
COMPLICATED SUBSYSTEM TEAM
Purpose: Handle complex technical domains
Characteristics:
• Specialists in a complex area
• Reduce cognitive load on others
• Domain requires rare expertise
• Well-defined interfaces
• Relatively rare team type
When to Create:
• Math-heavy algorithms
• Legacy system specialists
• Specialized hardware integration
• Complex regulatory domains
• AI/ML model specialists
Examples:
• Video Codec Team
• Machine Learning Platform Team
• Financial Calculations Team
• Cryptography Team
Warning Signs You Don't Need One:
✗ Creating to "own" technology
✗ Architecture astronaut syndrome
✗ Avoiding sharing knowledge
✗ Politics rather than complexity
Decision Matrix:
┌─────────────────────────────────────────────────────────────┐
│ Question │ Points To │
├─────────────────────────────────────────────────────────────┤
│ Aligned to business capability? │ Stream-aligned │
│ Enables other teams? │ Platform or Enabling │
│ Creates self-service products? │ Platform │
│ Transfers knowledge then leaves? │ Enabling │
│ Requires rare specialist skills? │ Complicated Subsystem │
│ Has internal "customers"? │ Platform │
│ Has external customers? │ Stream-aligned │
└─────────────────────────────────────────────────────────────┘
Target Distribution:
• 80%+ Stream-aligned
• 10-15% Platform
• 5-10% Enabling
• <5% Complicated Subsystem
Team Size Guidelines:
DUNBAR'S NUMBER AND TEAMS:
• 5-9 people per team (ideal)
• 15 max for loose-knit team
• Trust erodes beyond these limits
TWO-PIZZA RULE:
• If can't feed with two pizzas, too big
• Optimizes for communication
COGNITIVE LOAD PRINCIPLE:
• Team must be able to understand their domain
• Too big = too much to know
• Too small = too much per person
ANTI-PATTERNS:
✗ Teams of 1-2 (bus factor, isolation)
✗ Teams of 20+ (communication overhead)
✗ Frequent team changes
How Teams Evolve:
TEAM CREATION:
1. Start with mission/purpose
2. Identify required skills
3. Define boundaries
4. Establish interaction modes
TEAM GROWTH:
1. Add capabilities gradually
2. Watch cognitive load
3. Consider splitting when >9 people
TEAM SPLITTING:
1. Identify natural seams
2. Ensure each has clear purpose
3. Define new interaction modes
4. Plan transition period
TEAM MERGING (Rare):
1. Only when strong synergies
2. Watch for culture clashes
3. Clear combined purpose needed
# Team Topology Assessment: [Organization/Product]
## Current State
### Team Inventory
| Team | Current Type | Size | Dependencies | Issues |
|------|--------------|------|--------------|--------|
| [Name] | [Type] | [N] | [List] | [Problems] |
### Dependency Map
```text
[ASCII dependency diagram]
| Team | Current | Recommended | Rationale |
|---|---|---|---|
| [Name] | [Type] | [Type] | [Why] |
| Team | Type | Purpose |
|---|---|---|
| [Name] | [Type] | [Why] |
| Action | Teams | Rationale |
|---|---|---|
| [Split/Merge] | [Names] | [Why] |
When applying Team Topologies:
For detailed guidance:
Last Updated: 2025-12-26
npx claudepluginhub melodic-software/claude-code-plugins --plugin team-designGuides organizational design using Team Topologies: four team types (stream-aligned, platform, enabling, complicated subsystem), interaction modes, cognitive load, Inverse Conway Maneuver. For aligning teams with architecture.
Designs team topology using Team Topologies principles. Supports design, analyze, and evolve modes for organizational design, restructuring, or team evolution.
Assesses team structure against Team Topologies, evaluating cognitive load, interaction modes, Conway's Law alignment, and fracture planes for optimized software delivery.