RunsheetTeam Design

Team Topologies Interaction Modes

ComplexityMedium

TimeHalf day

ParticipantsTeam-Leads plus Architecture

FormatWorkshop

MaturityEmerging

Prerequisite

What needs to be finished first

Complete firstTeam API

Teams have clarity about own responsibilities and services, ideally documented in Team API form.

Without: Without self-understanding per team, interaction modes are chosen for unclear interfaces and agreements stay vague.

Preparation

What needs to be ready before start

Materials

Whiteboard or Miro board with heatmap template (team list vertically and horizontally, cells for interaction modes); definitions of three modes with examples; list of current interface problems; pens with three colors for modes.

People / roles

One facilitator with Team Topologies experience; team leads of all involved teams; architecture lead or engineering director as sponsor; scribe for agreements.

Pre-read

Team list with main responsibilities (Stream-Aligned, Platform, Enabling, Complicated-Subsystem); current interface relationships; known frictions or escalations; planned platform initiatives.

Time needed

Half day (4 h)

Setup

Heatmap with teams in rows and columns. Colors per mode: blue=Collaboration (intensive, temporary), green=X-as-a-Service (clearly defined service, durable), yellow=Facilitating (coaching, enabling). Definitions visible.

Core question

The one question this method answers

Which interaction mode fits per team pair, and how do we agree modes bindingly to reduce interface friction?

Flow

Marker: Phase

Step	Duration	Action	Hint
1Phase 1: Introduce modes with examples	20 min	Explain three modes. Collaboration: two teams work closely together temporarily (for example new feature, architecture change). X-as-a-Service: one team consumes clearly defined service of another. Facilitating: enabling team supports stream-aligned team through coaching, durably bounded.	If modes are unclear, participants choose wrong. Bring concrete own examples, not abstract theory.
2Phase 2: Map current interaction	60-90 min	Mark current state per team pair. Which mode runs today. If unclear, mark. Mark friction points with red note.	Honestly describe what runs, not what ideally should run. Mismatch between target and actual is common source of friction.
3Phase 3: Discuss target modes	60-90 min	Define target mode per team pair. Discuss rationale. For change between actual and target, think transition plan (for example Collaboration -> X-as-a-Service through service buildup).	Avoid mixed forms. Exactly one mode per pair. Anyone saying "sometimes Collaboration, sometimes Service" has not understood mode. Conscious choice is core.
4Phase 4: Agreements and heatmap	30-45 min	Complete heatmap with target modes. Document agreement per pair (what mode means concretely, which communication channels, SLA). Transition plan for changes.	Heatmap without agreements is diagram. Concrete agreement per pair with example workflow. Agreement should be 1-2 sentences, not abstract definition.

Artifact

What comes out at the end

Form

Heatmap with all team pairs and modes (colored); table list with pairs, mode, agreement, transition plan, owner. Linked with Team API pages of involved teams. Visible engineering-org overview.

Versioning / ownership

Re-run semiannually or on org change. Mode change with date and rationale. Make transition phases visible (for example "Q3: Collaboration, Q4: X-as-a-Service targeted"). Archive previous version.

Tool alternatives

Miro or FigJam with Interaction Modes template
Lucidchart with heatmap template
Confluence page with embedded matrix
Notion database with mode/agreement properties
Specialized tool such as Plandek with topology features

team-topologies-interaction-modes-working-template.md

Compact working template for Team Topologies Interaction Modes with context, input, output artifacts, and next step.

Team Topologies Interaction Modes Canvas

Context

What is this method used for?

Core question

Which question should be answered at the end?

Input

Which data, observations, or materials are available?

Working area

Area 1:
Area 2:
Area 3:
Relationships / patterns:

Output artifacts

Interaction heat map:
Agreements by pair:

Open questions

Next step

Owner, date, success signal.

Example output

Concrete filled scenario, fictional example

team-topologies-interaction-modes-beispiel.md

Concrete filled scenario, fictional example

Team Topologies Interaction Modes - Engineering org, 2026-05-18

Sponsor: @julia (CTO). Participants: 8 team leads, Architecture Lead.

Teams

Stream-Aligned: Product A, Product B, Product C
Platform: Identity, Data Platform, Infrastructure
Enabling: DevEx, Security Coaches
Complicated-Subsystem: AI Platform

Heatmap excerpt

Team pair	Current	Target	Agreement
Product A <-> Identity	Collaboration (chaotic)	X-as-a-Service	Identity provides Auth API with SLA, Product A consumes without direct contact.
Product A <-> DevEx	Facilitating	Facilitating	DevEx coach supports Product A with tooling migration, durable 0.5 FTE for 2 quarters.
Product B <-> Data Platform	Collaboration	Collaboration (Q3) -> X-as-a-Service (Q4)	Close collaboration for data pipeline buildup until Q3, self-service from Q4.
Product B <-> AI Platform	Collaboration	X-as-a-Service	AI Platform offers inference API, Product B integrates without direct model discussion.
Identity <-> Infrastructure	X-as-a-Service	X-as-a-Service	Infrastructure provides Kubernetes cluster with clear SLA.
Security Coaches <-> all	Facilitating	Facilitating	Security reviews on demand, max 2 days per team per quarter.

Previous friction points

Product A <-> Identity: every new feature required Slack DM discussions with Identity engineers (Collaboration without SLA). Solution: Auth API docs improved, SLA fixed, no direct engineer contact needed.
Product B <-> Data Platform: expectation of service availability, but platform still in build-up. Solution: transition plan with clear Q4 date for service mode.

Transition agreements

Q3 -> Q4: Product B <-> Data Platform switches to X-as-a-Service. Preconditions: self-service docs, API stability, SLA definition by Data Platform by end of Q3.

Diagram built, sits in wiki, nobody implements mode changes.

What to do

Owner and deadline per pair with mode change. Semiannual review cadence. Workshop ends with concrete action plan, not diagram alone.

Stop criteria

Done signals checkable in under a minute

Fewer than 4 teams, heatmap would be overhead.

Teams have no clear responsibilities, mode choice would be speculation.

Sponsor or engineering lead not present, agreements would be non-binding.

Org in transition (restructuring), heatmap would be outdated in 4 weeks.

Three modes not understood, workshop becomes method training instead of topology design.

No existing interface problems, workshop is academic without lever.

Finished the runsheet?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profile More methods