diegosouzapw Team Topologies Skill
When to Use This Skill
Use this skill when:
- Team Topologies tasks - Working on four fundamental team types and interaction modes from team topologies
- Planning or design - Need guidance on Team Topologies approaches
- Best practices - Want to follow established patterns and standards
Overview
Design team structures using the four fundamental team types from Team Topologies.
MANDATORY: Documentation-First Approach
Before applying Team Topologies:
- Invoke
docs-managementskill for team design patterns - Verify Team Topologies concepts via MCP servers (perplexity)
- Base guidance on Skelton & Pais methodology
Four Fundamental Team Types
Team Topologies Model:
┌─────────────────────────────────────────────────────────────────┐
│ STREAM-ALIGNED TEAMS │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Feature │ │ Feature │ │ Feature │ │
│ │ Team A │ │ Team B │ │ Team C │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌────────────────┴────────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ PLATFORM │ │ ENABLING │ │
│ │ TEAM │ │ TEAM │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ │
│ │ COMPLICATED │ │
│ │ SUBSYSTEM TEAM │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Stream-Aligned Teams
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 Teams
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 Teams
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 Teams
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
Team Type Selection Guide
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 Sizing
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
Team Evolution
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
Assessment Template
# 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]
Analysis
Stream-Aligned Teams
- Count: [N]
- Percentage: [%]
- Issues: [List]
Platform Teams
- Count: [N]
- Percentage: [%]
- Issues: [List]
Enabling Teams
- Count: [N]
- Percentage: [%]
- Issues: [List]
Complicated Subsystem Teams
- Count: [N]
- Percentage: [%]
- Issues: [List]
Recommendations
Team Type Changes
| Team | Current | Recommended | Rationale |
|---|---|---|---|
| [Name] | [Type] | [Type] | [Why] |
New Teams Needed
| Team | Type | Purpose |
|---|---|---|
| [Name] | [Type] | [Why] |
Teams to Merge/Split
| Action | Teams | Rationale |
|---|---|---|
| [Split/Merge] | [Names] | [Why] |
Implementation Roadmap
- [Phase 1 actions]
- [Phase 2 actions]
Workflow
When applying Team Topologies:
- Map Current State: Inventory existing teams
- Classify Types: Identify current team types
- Assess Gaps: Compare to target distribution
- Identify Issues: Dependencies, cognitive load, blockers
- Design Target: Optimal team structure
- Plan Evolution: How to get from current to target
- Execute Gradually: Evolutionary change, not big bang
References
For detailed guidance:
Last Updated: 2025-12-26