management-team-topologyUse this skill when designing team structures: team topology, Conway's Law, cognitive load, stream-aligned teams, enabling teams, platform teams. This skill enforces: team type classification, cognitive load assessment, interaction mode selection, org design patterns. Do NOT use for: individual performance management, hiring process, sprint planning, agile …
Independent GitHub snapshot · Automated classification · Original documentation governs
Designs team structures aligned with stream-aligned, enabling, complicated-subsystem, and platform topologies using Conway's Law, cognitive load principles, and interaction modes to optimize delivery flow.
Team topology is the practice of organizing engineering teams around the systems they build, based on the observation that organizations design systems that mirror their communication structures (Conway's Law). The goal is to minimize cognitive load per team, maximize flow of value to customers, and create team boundaries that naturally produce the desired system architecture.
This skill implements the four fundamental team types from Team Topologies (Matthew Skelton and Manuel Pais): stream-aligned (default), enabling (capability building), complicated-subsystem (deep specialization), and platform (self-service infrastructure). It provides decision trees for team type assignment, cognitive load assessment frameworks, interaction mode selection guides, and transition plans for org restructuring.
Exact user phrases: team topology, team structure, Conway's Law, stream-aligned, cognitive load, enabling team, platform team, team types, org design, squad health.
Team topology design with team type assignments, interaction modes, cognitive load assessment, and org transition plan.
## Team Topology Design
### Teams
{n} teams | {n} stream-aligned | {n} enabling | {n} platform | {n} complicated-subsystem
### Interaction Modes
{collaboration}: {teams} | {X-as-a-service}: {teams} | {facilitating}: {teams}
### Cognitive Load
{team}: {intrinsic}/{extraneous}/{germane} = {total}
### Transition Plan
Phase 1: {changes} | Phase 2: {changes} | Phase 3: {changes}
No preamble. No postamble. No explanations.
7000 tokens
| Type | Purpose | Typical Size | Cognitive Load | Default |
|---|---|---|---|---|
| Stream-Aligned | Owns end-to-end value stream | 5-9 people | Moderate - high | Yes, default |
| Enabling | Builds capability in other teams | 3-5 people | Low - moderate | No |
| Complicated-Subsystem | Deep specialization on complex component | 3-6 people | High (deep) | No |
| Platform | Self-service infrastructure for other teams | 5-12 people | Moderate | No |
What kind of work does the team do?
├── End-to-end value delivery to customers
│ └── Stream-Aligned Team — default choice
│ └── Has the team clear ownership of a complete value stream?
│ ├── Yes → stream-aligned is correct
│ └── No → redefine team boundaries to own end-to-end flow
├── Complex component requiring deep expertise
│ └── Does the complexity justify dedicated specialists?
│ ├── Yes → Complicated-Subsystem Team
│ └── No → embed specialist in stream-aligned team
├── Building shared infrastructure for other teams
│ └── Platform Team — treat internal teams as customers
│ └── Is the platform self-service (API, docs, SLAs)?
│ ├── Yes → healthy platform team
│ └── No → add API, documentation, and self-service capabilities
└── Helping other teams build capability
└── Enabling Team — temporary, limited lifespan
└── Is there a clear exit criteria?
├── Yes → good, enabling teams should be temporary
└── No → define exit criteria to prevent permanent enabling team
Is this a one-time or ongoing need?
├── One-time
│ └── Facilitating — help team build capability, then leave
└── Ongoing
└── Is the interface stable and well-defined?
├── Yes → X-as-a-Service — clear contract, minimal coordination
└── No → Collaboration — work together on evolving shared boundary
Does the consuming team have skills to work independently?
├── Yes → X-as-a-Service — self-service APIs, documentation, SLAs
└── No → Facilitating — pair, coach, document, gradually withdraw
How frequently does the interface change?
├── Stable → X-as-a-Service — versioned API, semver, deprecation policy
├── Changing weekly → Collaboration — shared ownership, joint design sessions
└── Changing daily → Consider merging teams — boundary too unstable
Organizations design systems that mirror their communication structures.
- If teams are organized by layer (frontend, backend, DB), the system will have layer boundaries
- If teams are organized by feature (search, checkout, payments), the system will have feature boundaries
- The communication paths between teams will become the integration points between services
Signs of misalignment:
- Integration between two services requires 3+ teams to coordinate
- Single team owns service but deployment requires changes in 5 other services
- Frequent defects at service boundaries between specific teams
- Key architectural changes blocked by organizational dependencies
Reverse Conway maneuver:
1. Define target system architecture (bounded contexts, services, layers)
2. Define team boundaries that would naturally produce that architecture
3. Incrementally reorganize teams to match target
4. Verify: new communication paths align with architectural interfaces
Map the end-to-end value streams the organization delivers. Identify the flow of work from customer need to delivered value. Find where handoffs, delays, and dependencies slow delivery. Determine team boundaries based on value streams, not functions. Each stream should be small enough for one team to own end-to-end.
Classify each team into one of four types. Stream-aligned team owns an end-to-end value stream, works continuously, minimizes external dependencies. Enabling team helps stream-aligned teams build capability, provides coaching and tools, intervenes temporarily. Complicated-subsystem team owns a technically complex component requiring deep specialization. Platform team builds self-service APIs and infrastructure for other teams, treats internal teams as customers.
Measure each team's cognitive load: intrinsic (inherent domain complexity), extraneous (process overhead, coordination cost), germane (learning and improvement capacity). Target: total cognitive load should not exceed team capacity. If too high, split the value stream or create enabling/platform support. Add germane capacity explicitly — learning time, experimentation, improvement.
Define interaction modes between teams: collaboration (joint work on shared problem, time-limited, high-bandwidth), X-as-a-service (clear API/contract, minimal coordination, one team serves another), facilitating (helping team levels up another team, temporary). Limit collaboration mode — it is expensive. Prefer X-as-a-service for stable interfaces. Use facilitating for capability building.
Identify what changes incrementally. Use reverse Conway maneuver: change org structure first, then design the system to match. Plan transitions in phases (not big bang). Start with team type reassignment and cognitive load reduction. Add enabling teams before platform teams (build capability first). Measure squad health at each phase.
Every team should have a clear purpose statement and an internal API defining how other teams interact with it. Team API includes: purpose (one sentence describing what the team exists to do), ownership (what systems, services, or domains the team owns), interaction mode (how other teams should interact), inputs (what the team needs from other teams), outputs (what the team delivers to other teams), SLAs (response times, availability, quality targets for X-as-a-Service). Document team APIs in a shared registry visible to the entire organization.
Establish a baseline squad health check before any org changes. Use a simple 6-dimension survey: delivery (are we shipping value?), mission (do we understand our purpose?), fun (are we enjoying work?), health (are we sustainable?), learning (are we growing?), dependencies (are we blocked?). Score each dimension as red/yellow/green. Run quarterly to track impact of topology changes.
Apply the two-pizza rule: teams should be 5-9 people max. When a stream-aligned team exceeds 9 people, split the value stream into two smaller streams. When a platform team exceeds 12 people, split into sub-platforms or create a platform enabling team. Use the cognitive load assessment to determine optimal team size — some domains may need smaller teams due to high intrinsic complexity.
Team topology is not static. As the product and organization evolve, review the topology quarterly. Signs that topology needs to change: collaboration mode becomes permanent (should have been X-as-a-Service), enabling team has no exit date, cognitive load is critical for multiple sprints, same 3 teams attend every cross-team coordination meeting.
Component teams (teams organized by technical layer) create integration hell. Feature teams that do not own the full stack create handoffs. Too many platform teams create platform fragmentation. Permanent enabling teams become bottlenecks. Collaboration mode used everywhere creates meeting overload. Stream-aligned teams that do not own their deployment cause release delays.
| Load Type | Definition | Factors | Target |
|---|---|---|---|
| Intrinsic | Complexity inherent to domain and tech | Domain complexity, technical complexity | Match team expertise |
| Extraneous | Process overhead, coordination cost | External dependencies, meetings, deployment complexity | < 30% of team capacity |
| Germane | Capacity for learning and improvement | Experimentation time, spikes, skill building | Minimum 20% of team capacity |
| Level | Characteristics | Action |
|---|---|---|
| Manageable | 1-2 domains, few dependencies, clear interfaces | No action needed |
| Warning | Multiple domains, 3+ coordination points, unclear interfaces | Reduce extraneous load |
| Critical | New domain, 5+ dependencies, high process overhead | Split team or add support |
| Strategy | When to Use | Impact |
|---|---|---|
| Split stream | Stream covers too much scope | Reduces intrinsic load |
| Add enabling team | Team lacks skills for current domain | Reduces intrinsic + extraneous |
| Create platform | Common concerns not standardized | Reduces extraneous load |
| Simplify interface | High coordination cost between teams | Reduces extraneous load |
| Increase germane time | No improvement happening | Increases capacity long-term |
| Org Pattern | System Pattern | Good For |
|---|---|---|
| Single team | Monolith | Startups, simple domains |
| N stream-aligned teams | N microservices | Large products with clear domain boundaries |
| Platform team + stream teams | Platform + services | Shared infrastructure needs |
| Enabling team + stream teams | Capability building | Skill gaps, new technology adoption |
Teams organized by technical layer (UI, API, DB). Creates integration hell, handoffs, and blame culture. Fix: reorganize into stream-aligned teams that own end-to-end value.
Every team interaction is collaboration mode. Creates meeting overload, context switching, and slow decision-making. Fix: push interfaces toward X-as-a-Service. Collaboration should be the exception, not the norm.
Assigning complex domains without assessing team capacity. Fix: assess cognitive load before assigning team type and scope. Split streams if needed.
Enabling teams that never disband become bottlenecks and create dependency. Fix: enabling teams always have an exit criterion and a maximum lifespan (3-6 months).
Platform teams that require other teams to "talk to us" rather than providing self-service APIs. Fix: platform teams are measured by adoption, not feature output. Self-service is non-negotiable.
Restructuring all teams at once causes chaos, productivity loss, and attrition. Fix: incremental transitions in phases. Let teams stabilize between changes.
Copying another company's team structure without understanding context. Fix: design topology based on your value streams, cognitive load constraints, and team capabilities.
Teams without clear purpose statements cause confusion about ownership, overlapping responsibilities, and dropped work. Fix: every team documents its API including purpose, ownership, and interaction mode.
Designing architecture without considering org structure. Fix: architecture and org structure must co-evolve. Use reverse Conway maneuver.
Adding teams before the product-market fit is validated. Fix: start with stream-aligned teams. Add enabling and platform teams only when the pain is real.
| Approach | Strengths | Weaknesses |
|---|---|---|
| Team Topologies (this skill) | Evidence-based, clear types, cognitive load focus | Requires organizational buy-in |
| Spotify Model | Squad/tribe/guild, autonomy, alignment | Hard to scale, role confusion |
| Holacracy | Distributed authority, roles over people | Complex rules, hard adoption |
| Functional Org | Clear career paths, specialization | Silos, slow cross-team work |
| Matrix Management | Resource flexibility | Confused reporting, slow decisions |
| Squads (autonomous) | High ownership | Duplication, inconsistency |
## Team: {name}
- Type: {stream-aligned / enabling / complicated-subsystem / platform}
- Purpose: {one sentence describing what the team exists to do}
- Ownership: {systems, services, domains owned}
- Interaction Mode(s):
- With {team}: {collaboration / X-as-a-Service / facilitating}
- With {team}: {collaboration / X-as-a-Service / facilitating}
- Inputs: {what the team needs from other teams}
- Outputs: {what the team delivers to other teams}
- SLAs (for X-as-a-Service): {response times, availability targets}
- Communication Channel: {Slack channel, meeting cadence}
## Team: {name} | Date: {date}
### Intrinsic Load
- Domain complexity: {low/medium/high} — {evidence}
- Technical complexity: {low/medium/high} — {evidence}
### Extraneous Load
- External dependencies: {n} teams — {list}
- Meeting overhead: {n} hours/week
- Deployment complexity: {low/medium/high} — {evidence}
### Germane Capacity
- Learning time: {n} hours/week — {target: > 20% capacity}
- Experimentation: {n} hours/week
### Overall Assessment: {manageable / warning / critical}
### Recommended Actions: {list}
## Squad: {name} | Quarter: {Qn YYYY}
| Dimension | Score (R/Y/G) | Notes |
|-----------|---------------|-------|
| Delivery | {R/Y/G} | {evidence} |
| Mission | {R/Y/G} | {evidence} |
| Fun | {R/Y/G} | {evidence} |
| Health | {R/Y/G} | {evidence} |
| Learning | {R/Y/G} | {evidence} |
| Dependencies | {R/Y/G} | {evidence} |
Overall Score: {n} / 6 green
Trend: {improving / stable / declining}
### Phase 1 (Weeks 1-4): Foundation
- Reassign team types based on value streams
- Reduce extraneous cognitive load (simplify interfaces)
- Define team APIs for all teams
### Phase 2 (Weeks 5-12): Capability Building
- Create enabling team(s) for skill gaps
- Start platform team if needed
- Train teams on new interaction modes
### Phase 3 (Weeks 13-24): Stabilization
- Measure squad health baseline
- Adjust team boundaries based on cognitive load data
- Review and refine team APIs
- Phase out enabling teams as capability matures
When: Two teams co-own a shared problem with evolving boundaries
Example: Team A (checkout) and Team B (payment) building a new payment flow
Process:
- Joint design sessions (weekly)
- Shared slack channel (#checkout-payment)
- Paired development on integration points
- Shared sprint review for joint work
Duration: 2-4 sprints, then evaluate
Exit: Stable interface between services -> X-as-a-Service
Warning signs:
- Collaboration continues beyond 2 sprints without exit plan
- Both teams blocked when one is unavailable
- Cross-team meetings exceed 1 hour/week per person
When: One team provides stable capabilities to another via API/contract
Example: Platform team provides feature flag service to stream-aligned teams
Contract:
- API versioned and documented (OpenAPI spec)
- SLAs: uptime 99.9%, p99 latency < 100ms
- Deprecation policy: 6 months notice
- Self-service onboarding (docs, SDK, Terraform module)
Consuming team experience:
- Can adopt without talking to platform team
- Clear upgrade path with deprecation notices
- Dashboard for usage and limits
Platform team responsibilities:
- Maintain backward compatibility
- Monitor adoption and performance
- Provide migration guides for breaking changes
When: One team helps another build capability in a specific area
Example: Enabling (SRE) team helps stream-aligned team adopt observability
Process:
Week 1: Assessment — current state, gaps, skills audit
Week 2-3: Pairing — SRE pairs with dev team on implementing metrics
Week 4: Guided — dev team implements independently, SRE reviews
Week 5: Handoff — dev team owns, SRE available for questions
Week 6: Graduation — SRE steps away, dev team fully enabled
Outcome: Stream team can independently maintain observability
Exit criteria: Team passes capability assessment
| Anti-Pattern | Symptoms | Root Cause | Fix |
|---|---|---|---|
| Component teams | Integration hell, handoffs, blame culture | Organized by tech layer | Reorganize into stream-aligned teams |
| Collaboration everywhere | Meeting overload, context switching | No stable interfaces | Push toward X-as-a-Service |
| Permanent enabling teams | Bottleneck, dependency | No exit criteria | Max 3-6 month lifespan |
| Platform that doesn't self-serve | Team-to-team dependency | Poor API/ docs | Platform measured by adoption |
| Ignoring cognitive load | Burnout, churn, quality decline | Assigned without assessment | Assess before assigning type |
| Big bang reorg | Chaos, productivity loss, attrition | All-at-once change | Incremental transitions |
| Copying Spotify model | Org mismatch | Context-blind adoption | Design from value streams |
| No team API | Confusion, overlaps, dropped work | Missing purpose statement | Every team documents API |
| Premature scaling | Waste, fragmentation | Added before validation | Start with stream-aligned teams |
Duration: Half-day workshop
Participants: 2-3 teams, product managers, architects
Agenda:
1. Map customer journey (30 min) — identify touchpoints
2. Map internal handoffs (45 min) — identify where work moves between teams
3. Identify friction points (30 min) — delays, rework, context switches
4. Define ideal flow (30 min) — minimize handoffs, optimize for speed
5. Propose team boundaries (45 min) — align teams to value streams
6. Identify dependencies (30 min) — what interactions remain across teams
Quarterly activity:
1. List all team-to-team interactions
2. Classify each as Collaboration, X-as-a-Service, or Facilitating
3. Track total collaboration hours per person per week
4. Target: collaboration < 2 hours/person/week
5. For each collaboration > 2 hours: identify what's needed to move to X-as-a-Service
6. Track trend quarterly
For OKR alignment with team topology, hand off to management-okr-kpi. For agile process design, hand off to management-agile-scrum-kanban. For hiring to fill team gaps, hand off to management-hiring.
| Decision Point | Option A | Option B | Decision Criteria |
|---|---|---|---|
| Service ownership | Stream-aligned (vertical) | Component/Platform (horizontal) | Domain complexity, team size |
| Collaboration mode | X-as-a-Service (thin API) | X-as-a-Service + collaboration | Dependency stability, org maturity |
| Enabling teams | Temporary (adopt and disband) | Permanent (center of excellence) | Technology maturity, adoption stage |
`markdown
{one sentence describing team purpose}
`markdown
| Anti-Pattern | Symptom | Solution |
|---|---|---|
| Conway's Law ignored | Architecture mirrors org chart poorly | Design teams to produce desired architecture |
| Hero culture | Bus factor of 1, team dependent on individual | Rotate responsibilities, enforce pair work |
| Too many dependencies | Every team blocked by another | Identify and split bottlenecks, add platform team |
| Team as cost center | No ownership, no accountability | Define clear mission and measurable outcomes |
| Re-org every quarter | Never reaching Tuckman performing stage | Allow 6-12 months for team stabilization |