Team Topology Patterns

Most delivery pain is not a tooling problem. It is a team-design problem: unclear ownership, endless handoffs, and platforms that try to be everything. Team topology patterns give you a shared language for who does what, how teams interact, and how to protect cognitive load so people can ship.

You do not need a reorg to start. You need honest maps of streams of change, forced collaboration, and platform seams. Rename last. Change interaction modes first.

The four team types

Use these as roles in the delivery system, not as prestige labels. A team can shift type as the product and org mature, but it should not pretend to be three types at once.

• Stream-aligned: aligned to a flow of change for a user or business domain. Owns outcomes end to end where possible.
• Platform: provides internal products that reduce cognitive load for stream teams (APIs, paved roads, self-service).
• Enabling: helps stream teams acquire missing capabilities (coaching, spikes, temporary pairing), then steps back.
• Complicated-subsystem: owns a hard specialty (ML core, billing engine, real-time media) so others do not drown in it.

Three interaction modes

Team type is incomplete without interaction mode. The same two teams can succeed or fail depending on how they are allowed to talk.

1. Collaboration: work closely for a defined period to discover a boundary or shape a new capability. High bandwidth, high cost. Time-box it.
2. X-as-a-Service: one team provides a clear service with docs, SLOs, and a support path. Low collaboration cost once the interface is good.
3. Facilitating: an enabling team helps another team learn or adopt a practice without taking permanent ownership of the work.

If everything is Collaboration forever, you do not have a platform. You have a meeting schedule.

Patterns that work in practice

• Thinnest viable platform: the smallest set of paved roads that removes repeated pain. Grow from usage, not from a multi-year vision deck.
• Stream first: default new work to a stream-aligned team with a clear customer or domain, not to a horizontal layer team.
• Enabling with an exit: every enabling engagement has a success criteria and an end date, or it becomes a permanent crutch.
• Complicated-subsystem isolation: put rare expertise behind a stable interface so product teams do not all relearn the same hard thing.
• Reverse Conway carefully: change team boundaries when architecture and ownership repeatedly fight each other, not as a status project.

Anti-patterns to kill early

1. Platform as ticket factory: every request is a ticket, no self-service, no product thinking.
2. Pseudo stream teams that cannot ship without three approvals from other groups.
3. Enabling teams that never leave and quietly become owners of everything they touch.
4. One giant team labeled platform that is really five unrelated jobs.
5. Reorg theater: new names, same handoffs, same cognitive load.

How to set a team: size, mission, and the two-pizza rule

Team setup is product design for humans. Before you argue process, decide mission, boundaries, and size. The Amazon two-pizza heuristic (a team small enough to feed with two pizzas) is not about food. It is about communication cost: as headcount grows, coordination paths explode and ownership gets fuzzy.

• Mission: one sentence for the stream of value you own.
• Boundaries: systems, customers, and decisions you own vs consume as X-as-a-Service.
• Size: prefer small stream teams (often about 5-9 engineers) where everyone can know the work.
• Two-pizza test: if the team cannot share context without permanent meetings and status brokers, it is too large or mis-scoped.
• Composition: mix seniority; avoid a team of only juniors or only specialists with no delivery glue.
• Interfaces: name collaboration vs X-as-a-Service edges with neighboring teams on day one.

1. Write mission + non-goals on one page.
2. List owned streams/services and explicit non-owned items.
3. Count coordination load: how many teams must say yes to ship.
4. If size grows past healthy cognitive load, split by stream or extract a platform/enabling edge, do not just add managers as duct tape.
5. Publish working agreements: reviews, on-call, communication channels, decision rights.

A lead's operating checklist

As a team lead, you may not redraw the whole org. You can still make topology explicit for your area and negotiate better interfaces.

1. Map value streams and who must change code for each flow.
2. List top five cross-team dependencies by pain and frequency.
3. For each dependency, name the intended interaction mode (and the mode you actually use).
4. Write platform or service expectations: docs, SLOs, support hours, deprecation rules.
5. Protect stream teams from load spikes: freeze drive-by work, fund enabling help, or split a complicated subsystem.
6. Review topology quarterly with incidents, lead time, and team health, not only headcount plans.