Team Interaction Map Template (Team Topologies)
Team types, interaction modes, cognitive load, as-is and target team diagrams, findings and a dated evolution plan
使い方: Use it to see how the teams in one product area work together and how that should change. Fill the team register with self-assessed cognitive load first, then the interaction register as teams actually work today. The main pitfall is collaboration with no end date.
プレビュー
Team Interaction Map: [Organisation unit or product area]
Map of the teams in one product area: the type of each team, the mode of each interaction between teams, how much cognitive load each team carries, and how the interactions are planned to change over time. Team type and interaction mode names follow Team Topologies by Matthew Skelton and Manuel Pais (2nd edition, IT Revolution, 2025). Replace every
[bracketed]value and every row marked Example. Worked examples use the invented online grocery retailer from the Context Map template (architecture/context-map).
| Field | Value |
|---|---|
| Area | [Online grocery: basket to doorstep] |
| Map type | [As-is / To-be / Both] |
| Version | [0.1] |
| Status | [Draft / Agreed / Superseded] |
| Owner | [@head-of-engineering] |
| Contributors | [@team-leads], [@domain-architect] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Related documents | Context Map (architecture/context-map), Core Domain Chart (architecture/core-domain-chart), Team APIs (architecture/team-api) |
1. Purpose and scope
[Purpose statement. Example: The map covers the seven teams that build and run the path from basket to doorstep. It supports two decisions: how to staff the replacement of the legacy order management system, and whether the routing work needs its own team.]
2. Vocabulary
| Term | Kind | Meaning in this map |
|---|---|---|
| Stream-aligned team | Team type | Owns a flow of work for a product, service or user journey from idea to production |
| Platform team | Team type | Provides internal services that stream-aligned teams consume to move faster |
| Enabling team | Team type | Specialists who help other teams gain a capability, then step back |
| Complicated subsystem team | Team type | Owns a part that needs deep specialist knowledge most teams do not have |
| Collaboration | Interaction mode | Two teams work closely together for a defined period to discover something new |
| X-as-a-Service | Interaction mode | One team consumes what another provides, with little need for close contact |
| Facilitating | Interaction mode | One team coaches or helps another to remove an obstacle or learn a practice |
3. Team register
| ID | Team | Type | Bounded contexts or services owned | Size | Cognitive load (1-5) | Main load driver |
|---|---|---|---|---|---|---|
| T-01 | Example: Team Checkout | Stream-aligned | Basket and Checkout | 7 | 3 | Many upstream dependencies |
| T-02 | Example: Team Slots | Stream-aligned | Slot Booking | 6 | 3 | Capacity rules change every season |
| T-03 | Example: Team Fulfilment | Stream-aligned | Fulfilment | 8 | 5 | Owns picking and van routing logic and the legacy export adapter |
| T-04 | Example: Team Range | Stream-aligned | Catalogue | 5 | 2 | Stable domain |
| T-05 | Example: Team Payments | Complicated subsystem | Payments | 4 | 3 | Provider integration and refund rules |
| T-06 | Example: Team Platform | Platform | Delivery platform, legacy OMS | 6 | 4 | Platform product plus legacy OMS support |
| T-07 | Example: SRE Enablement | Enabling | None (coaching) | 3 | 2 | Coaching spread across several product areas |
| [T-NN] | [Team] | [Type] | [Contexts] | [People] | [1-5] | [Driver] |
4. Interaction register (as-is)
| ID | Team A | Team B | Mode | Direction | Purpose | Started | Planned end |
|---|---|---|---|---|---|---|---|
| TI-01 | Example: Team Checkout | Team Slots | Collaboration | Both ways | Design premium slot pricing in checkout | YYYY-MM-DD | YYYY-MM-DD |
| TI-02 | Example: Team Platform | Team Checkout | X-as-a-Service | Platform provides | Deployment pipeline and runtime | YYYY-MM-DD | Ongoing |
| TI-03 | Example: Team Platform | Team Fulfilment | X-as-a-Service | Platform provides | Runtime and nightly OMS export | YYYY-MM-DD | Ongoing |
| TI-04 | Example: Team Payments | Team Checkout | X-as-a-Service | Payments provides | Authorisation and refunds API | YYYY-MM-DD | Ongoing |
| TI-05 | Example: SRE Enablement | Team Fulfilment | Facilitating | Enablement helps | Introduce service level objectives and on-call | YYYY-MM-DD | YYYY-MM-DD |
| TI-06 | Example: Team Fulfilment | Team Checkout | Collaboration | Both ways | Shared substitution rules library | YYYY-MM-DD | None set |
| [TI-NN] | [Team] | [Team] | [Mode] | [Direction] | [Purpose] | YYYY-MM-DD | YYYY-MM-DD |
5. Interaction diagram (as-is)
Team Range (T-04) has no interaction in this map: it publishes the catalogue API that other teams consume without team-level contact, which is recorded in the context map instead.
6. Findings
| ID | Finding | Evidence | Risk |
|---|---|---|---|
| TF-01 | Example: Team Fulfilment is overloaded | T-03 load 5; owns picking, routing and the OMS adapter | Slower delivery on a core context; burnout |
| TF-02 | Example: Collaboration on substitution rules has no end date | TI-06 | Shared library becomes a permanent coupling |
| TF-03 | Example: Team Platform runs a product and a legacy system | T-06 | Platform roadmap slips whenever OMS has an incident |
| [TF-NN] | [Finding] | [Rows] | [Risk] |
7. Planned evolution
| ID | Change | From | To | Trigger or exit criterion | Owner | Target date |
|---|---|---|---|---|---|---|
| EVO-01 | Example: Create Team Routing to own van route optimisation | Part of T-03 | New complicated subsystem team | Two routing specialists hired | @head-of-engineering | YYYY-MM-DD |
| EVO-02 | Example: End substitution rules collaboration | TI-06 Collaboration | Fulfilment provides rules X-as-a-Service | Rules API v1 published, shared library retired | @fulfilment-lead | YYYY-MM-DD |
| EVO-03 | Example: End SRE facilitation for Fulfilment | TI-05 Facilitating | No interaction | Team runs its own on-call for two months without escalation | @sre-lead | YYYY-MM-DD |
| EVO-04 | Example: Move legacy OMS to a time-boxed migration squad | T-06 owns OMS | Squad inside Team Platform until OMS retired | Funding for OMS replacement approved | @platform-lead | YYYY-MM-DD |
| [EVO-NN] | [Change] | [Current] | [Target] | [Criterion] | [@owner] | YYYY-MM-DD |
The target map after EVO-01 to EVO-03 is shown below. Team Range and SRE Enablement are left out because neither has an interaction in this area once EVO-03 is complete; EVO-04 changes ownership inside Team Platform and does not add an interaction.
8. Review log
| Date | Reviewed by | Changes made | Next review |
|---|---|---|---|
| YYYY-MM-DD | Example: @head-of-engineering with team leads | EVO-03 completed; load of T-03 down from 5 to 4 | YYYY-MM-DD |
| YYYY-MM-DD | [Names] | [Changes] | YYYY-MM-DD |
References
- Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology for Fast Flow of Value, 2nd edition, IT Revolution, 23 September 2025 (first edition 2019). Book details: https://itrevolution.com/book/team-topologies/ ; key concepts summary: https://teamtopologies.com/key-concepts (both checked 2026-10-30).
- Related templates: Team API (
architecture/team-api), Context Map (architecture/context-map), Core Domain Chart (architecture/core-domain-chart), Internal Developer Platform Charter (architecture/internal-developer-platform-charter).
Standard and licence note
Team type and interaction mode names are taken from Team Topologies by Matthew Skelton and Manuel Pais (2nd edition, IT Revolution, 2025). The book is a commercial publication: this template uses its terms by name only, with one-line explanations written for this collection, and reproduces no text, figures or shapes from it. Obtain the book for the full method. Team Topologies is a trademark of its owners. All tables, examples and guidance are original. Template licence: MIT.
関連テンプレート
Business Capability Map and Heatmap Template
Capability modelling rules, L1 to L3 hierarchy, definitions catalogue, maturity and importance scoring, heatmap, value stream and app mapping
アーキテクチャC4 Architecture Document Template (C4 Model)
C4 model document with Mermaid C4 diagrams – context, containers, components, code, landscape, dynamic, deployment, element catalogues
アーキテクチャDDD Context Map Template
Map bounded contexts and their DDD relationships (ACL, OHS, conformist, shared kernel), team ties and evolution plan