Use when the user asks to "design team structure", "apply Team Topologies", "optimize team boundaries", "reduce cognitive load", "map team interaction modes", or mentions Team Topologies, Conway's Law, stream-aligned teams, platform teams, enabling teams, cognitive load, team interaction patterns.
TL;DR: Designs optimal team structures using Team Topologies framework (stream-aligned, platform, enabling, complicated-subsystem). Considers Conway's Law, cognitive load, and interaction modes (collaboration, X-as-a-Service, facilitating) to create teams that minimize coordination overhead and maximize delivery flow.
Conway's Law es inevitable: la estructura del equipo se refleja en la arquitectura del producto. Team Topologies trabaja CON Conway's Law, no contra ella. El principio fundamental es minimizar la carga cognitiva de cada equipo: un equipo que intenta abarcar demasiados dominios será lento e inconsistente.
# Full team topology design
/pm:team-topology-design $ARGUMENTS="--teams 12 --architecture system-map.md"
# Cognitive load assessment only
/pm:team-topology-design --type cognitive-load --teams team-inventory.md
# Interaction mode design
/pm:team-topology-design --type interaction-modes --topology current-topology.md
Parameters:
| Parameter | Required | Description |
|---|---|---|
$ARGUMENTS | Yes | Team count and system architecture |
--type | No | full (default), cognitive-load, interaction-modes, evolution |
--teams | No | Number of teams or path to team inventory |
--architecture | No | Path to system architecture map |
{TIPO_PROYECTO} variants:
**/value_stream* to find existing value stream analysis [PLAN]Good example — Intentional team topology:
| Attribute | Value |
|---|---|
| Team types | 6 stream-aligned, 2 platform, 1 enabling, 1 complicated-subsystem |
| Cognitive load | Assessed per team, all within sustainable range |
| Interaction modes | 15 team pairs with explicit modes defined |
| Platform services | 3 internal services identified for platform treatment |
| Evolution path | 12-month topology evolution plan |
| Flow metrics | Lead time and deployment frequency per team |
Bad example — Renamed existing structure: Existing functional teams (backend, frontend, QA) relabeled as "stream-aligned" without changing boundaries, responsibilities, or interaction patterns. Team Topologies is not a naming exercise — it requires actual boundary optimization based on cognitive load and value stream alignment.
| Resource | When to Read | Location |
|---|---|---|
| Body of Knowledge | Team Topologies book and patterns | references/body-of-knowledge.md |
| State of the Art | Modern team design research | references/state-of-the-art.md |
| Knowledge Graph | Team topology in resource planning | references/knowledge-graph.mmd |
| Use Case Prompts | Topology design scenarios | prompts/use-case-prompts.md |
| Metaprompts | Custom topology patterns | prompts/metaprompts.md |
| Sample Output | Reference topology design | examples/sample-output.md |
Quantify and evaluate the cognitive load each team carries by scoring domain complexity, technology stack diversity, operational toil, and inter-team coupling. When a team exceeds sustainable thresholds, recommend specific load-shedding strategies such as domain splitting, platform extraction, or operational transfer — ensuring no team is set up for failure by carrying more than it can reason about effectively.
| Team | Domain Complexity | Tech Diversity | Ops Burden | Dependencies | Composite Load | Status | Recommended Action |
|---|---|---|---|---|---|---|---|
| Team-Alpha | 4.2/5 | 5 stacks | 35% capacity | 4 blocking | 82% | Red | Split payment domain; extract shared DB |
Systematically compare team boundaries against system architecture boundaries to detect Conway's Law violations. When team structure and architecture diverge — a single team owning components that should be independent, or multiple teams forced to coordinate on a single component — the result is accidental coupling, slow delivery, and architecture erosion. This agent surfaces those misalignments and recommends structural corrections.
| Component/Service | Current Owner(s) | Misalignment Type | Impact Score | Symptoms | Recommended Fix |
|---|---|---|---|---|---|
| payment-gateway | Team-A (70%), Team-B (30%) | Split Ownership | High | 40% of PRs require cross-team review; 3 deployment conflicts/month | Transfer full ownership to Team-A; extract Team-B's functionality into separate service |
| user-service + notification-service + audit-service | Team-C (100%) | Monolithic Ownership | Medium | Cognitive overload (3 unrelated domains); 2-week lead time | Split Team-C; assign notification + audit to new enabling team |
Define the appropriate interaction mode for every team pair that must work together, selecting from collaboration, X-as-a-Service, or facilitating. Critically, design the evolution path for each interaction — collaboration is expensive and must be time-boxed, facilitating must have exit criteria, and X-as-a-Service requires mature contracts. Without deliberate interaction design, teams default to ad-hoc collaboration that never ends.
| Team A | Team B | Current Mode | Target Mode | Transition Trigger | Timebox | Evolution Plan |
|---|---|---|---|---|---|---|
| Checkout | Payments | Collaboration | X-as-a-Service | Payment API v2 stable + 2 sprints zero defects | 6 weeks | Joint discovery → contract definition → consumer-driven testing → handoff |
| Platform | Mobile | X-as-a-Service | X-as-a-Service (mature) | N/A — already stable | Ongoing | Quarterly SLA review + self-service portal enhancement |
| SRE | Data Team | Facilitating | Self-sufficient | Data Team completes 3 incident responses solo | 8 weeks | Runbook transfer → shadowed on-call → solo on-call → exit |
Analyze each team's mission, deliverables, consumers, and interaction patterns to assign the correct Team Topologies type. Misclassified teams lead to mismatched expectations — a platform team treated as stream-aligned will be pulled into feature work, while a stream-aligned team forced into platform duties will bottleneck delivery. Accurate classification is the foundation for healthy interaction design.
| Team | Assigned Type | Justification | Primary Consumers | Confidence | Transition Needed |
|---|---|---|---|---|---|
| Team-Alpha | Stream-Aligned | Owns checkout flow end-to-end, delivers to paying customers | End users (B2C) | High | None — already operating correctly |
| Team-Platform-Core | Platform | Provides CI/CD, observability, and IaC as self-service | 6 stream-aligned teams | High | Formalize service catalog |