# 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`).

<!--
Guidance: How to use this template
- This map shows the whole area; each team's own interface lives in its
  Team API (`architecture/team-api`). Fill the Team APIs first or in the
  same workshop, then draw this map from them.
- Record interactions as they are today, not as the org chart says. Ask
  each pair of teams separately and compare the answers; disagreement is
  a finding.
- Every interaction mode should have a purpose and, for collaboration, an
  end date. Collaboration that never ends is a sign that a boundary is
  wrong.
- Review the map every [quarter] and after any re-organisation.
-->

| 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

<!-- Guidance: Say which teams are in scope and which decision the map supports: a re-organisation, a new platform, a team split, a migration. Pitfall: mapping the whole company at once; stay with the teams that work on one value stream or product area. -->

[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

<!-- Guidance: Keep this table so readers who have not read the book can use the map. The names are the book's; the one-line explanations are this template's own wording. -->

| 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

<!-- Guidance: One row per team in scope. Cognitive load is a self-assessment by the team on a 1 (light) to 5 (overloaded) scale; record the main reason. Link the bounded contexts each team owns so the map lines up with the context map. -->

| 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)

<!-- Guidance: One row per pair of teams that interact. Record the mode, its purpose and how long it should last. Missing or unclear purpose is a finding. A pair can have only one primary mode at a time. -->

| 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)

<!-- Guidance: Draw the teams from section 3 and the interactions from section 4, nothing else. Use solid two-way arrows for collaboration, solid one-way arrows from provider to consumer for X-as-a-Service, and dotted arrows from helper to helped team for facilitating. -->

```mermaid
flowchart LR
  CHK["Team Checkout (stream-aligned)"]
  SLOT["Team Slots (stream-aligned)"]
  FUL["Team Fulfilment (stream-aligned)"]
  RNG["Team Range (stream-aligned)"]
  PAY["Team Payments (complicated subsystem)"]
  PLT["Team Platform (platform)"]
  SRE["SRE Enablement (enabling)"]
  CHK <-->|"TI-01 Collaboration"| SLOT
  PLT -->|"TI-02 X-as-a-Service"| CHK
  PLT -->|"TI-03 X-as-a-Service"| FUL
  PAY -->|"TI-04 X-as-a-Service"| CHK
  SRE -.->|"TI-05 Facilitating"| FUL
  FUL <-->|"TI-06 Collaboration"| CHK
```

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

<!-- Guidance: Read the map for warning signs: an overloaded team, collaboration without an end date, a platform team whose consumers still need close contact, an enabling team that has become a permanent dependency, a complicated subsystem team without a real specialist need. -->

| 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

<!-- Guidance: Describe the target map as a set of dated changes. Each change names the interaction or team that changes, the new mode or type, and the trigger that ends the current mode. Typical moves: collaboration ending in X-as-a-Service once an API is stable, facilitating ending when the team is self-sufficient, a new complicated subsystem team taking specialist load off a stream-aligned team. -->

| 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.

```mermaid
flowchart LR
  CHK["Team Checkout (stream-aligned)"]
  SLOT["Team Slots (stream-aligned)"]
  FUL["Team Fulfilment (stream-aligned)"]
  ROUTE["Team Routing (complicated subsystem)"]
  PAY["Team Payments (complicated subsystem)"]
  PLT["Team Platform (platform)"]
  PLT -->|"X-as-a-Service"| CHK
  PLT -->|"X-as-a-Service"| FUL
  PAY -->|"X-as-a-Service"| CHK
  FUL -->|"X-as-a-Service: substitution rules"| CHK
  ROUTE -->|"X-as-a-Service: route plans"| FUL
  CHK <-->|"Collaboration until slot pricing ships"| SLOT
```

## 8. Review log

<!-- Guidance: Record each review briefly, so the map shows its own history and teams can see whether planned changes happened. -->

| 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

<!-- Guidance: Point to the book for the full explanation of team types and interaction modes, and to the related templates for each team's detail. -->

- 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.