Four fundamental team types and interaction modes from Team Topologies
Applies Team Topologies principles to design optimal team structures using the four fundamental team types. Triggers when you need to organize teams, reduce dependencies, or plan team evolution based on business capabilities and cognitive load.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install team-design@melodic-softwareThis skill is limited to using the following tools:
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