# Team Topologies — Walkthrough

## Before We Begin

**Diagnostic:** Conway's Law says organizations design systems that mirror their communication structure. In practice: if you have 3 siloed teams, what kind of architecture do you usually get? Why is that—and what would need to change to get something different?

**Checkpoint:** You can explain the link between org structure and system design, and why "reorg to match architecture" often fails without behavior change.

---

## Step 1: Map Your Org to Team Types

<!-- hint:diagram mermaid-type="classDiagram" topic="Team types: stream-aligned, platform, enabling, complicated-subsystem" -->

**Task:** List the teams in your organization (or a subset). For each, classify: stream-aligned, platform, enabling, or complicated-subsystem. If it doesn't fit, note the gap. Are there teams that *should* exist but don't?

**Question:** Where are the mismatches? What would need to change for the structure to better support flow?

**Checkpoint:** Every current team is classified; at least one gap or mismatch identified.

---

## Step 2: Identify Interaction Modes

<!-- hint:buttons type="single" prompt="When should two teams use X-as-a-Service instead of collaboration?" options="When discovering a new domain,When the consumer needs ongoing support,When the provider has a stable API,When both teams are learning" -->

**Task:** Pick 2–3 pairs of teams that work together. For each pair, identify the current interaction mode (collaboration, X-as-a-Service, facilitating). Is it the *right* mode for the context? If not, what would better support flow?

**Question:** Are you overusing collaboration (everyone needs to talk to everyone)? Or underusing it where discovery is needed?

**Checkpoint:** Interaction modes mapped; at least one recommendation for change.

---

## Step 3: Assess Cognitive Load

**Task:** Pick one stream-aligned team you know well. Estimate their cognitive load across intrinsic (domain complexity), extraneous (tooling, process, ambiguity), and germane (learning) dimensions. What's one change that would reduce extraneous load?

**Question:** What happens when cognitive load is too high? What are the warning signs?

**Checkpoint:** Load assessed; one concrete reduction identified.

---

## Step 4: Define a Team API

<!-- hint:list style="cards" -->
<!-- hint:card type="concept" title="A team API is what the team provides, how to use it, and what to expect—documented for consumers" -->

**Task:** If you have (or imagine) a platform team, define its "team API": what it provides, how consumers use it, SLA expectations, and support model. Write it as a one-pager a stream-aligned team could read.

**Question:** What makes a team API useful vs. ignored? How do you keep it current?

**Checkpoint:** Team API documented; consumable by a stream-aligned team.

---

## Step 5: Plan an Evolution

**Task:** Your org is growing. Today: 2 stream-aligned teams, no platform. In 6 months you'll have 5 stream-aligned teams. Draft a team topology evolution: when do you add a platform team? When might you need enabling? What triggers the change?

**Question:** What's the cost of adding structure too early? Too late?

**Checkpoint:** Evolution plan with triggers and team additions.

---

## Step 6: Avoid Inverse Conway Pitfalls

<!-- hint:celebrate -->

**Task:** Identify one place where your org (or a past org) reorganized to "match" architecture but didn't change behavior. What stayed the same? What would have been needed (incentives, APIs, culture) to make the reorg stick?

**Question:** Why do we often get the org chart right but the behavior wrong?

**Checkpoint:** One example of reorg-without-behavior-change; lessons for next time.