Team 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
 

 
## 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
 
1. [Phase 1 actions]
2. [Phase 2 actions]
 
## Workflow
 
When applying Team Topologies:
 
1. **Map Current State**: Inventory existing teams
2. **Classify Types**: Identify current team types
3. **Assess Gaps**: Compare to target distribution
4. **Identify Issues**: Dependencies, cognitive load, blockers
5. **Design Target**: Optimal team structure
6. **Plan Evolution**: How to get from current to target
7. **Execute Gradually**: Evolutionary change, not big bang
 
## References
 
For detailed guidance:
 
---
 
**Last Updated:** 2025-12-26