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-management skill 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

Dependency Map

[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