Skip to content

Team Topology Review Workshop

Facilitated design workshop — instantiates Organization–Artifact Topology Alignment

A facilitated session where the group generates and compares candidate team-boundary designs against the architecture it intends to build, before committing to any reorganization.

Choosing how to draw team boundaries is usually done by a manager alone with an org chart — and then the artifact inherits whatever communication structure that choice implied. Team Topology Review Workshop replaces that with a deliberate, collaborative session whose defining move is to generate several team designs and compare them against the architecture the group actually wants to build. It is generative, not executive: the workshop's product is an option set — this many teams, split this way, with these dependencies — each scored against the intended architecture and the cognitive load it would impose, so a reorganization is a considered choice among laid-out alternatives rather than a reflex. It decides nothing by itself; it makes the alternatives and their consequences visible so whoever does decide, decides well.

Example

A robotics startup building an autonomous warehouse forklift intends a system with clean perception / planning / control boundaries, but it has outgrown its single "robotics" team and must split. Rather than let a VP carve the org unilaterally, the leads run a topology workshop. They first make the target explicit: the desired architecture is three loosely-coupled subsystems plus a shared hardware-abstraction layer. Then they generate options: (a) one large team still owning everything (rejected — it re-creates today's bottleneck); (b) three stream-aligned teams mirroring perception, planning, and control, plus a small platform team for the hardware layer; © a matrix of feature teams cutting across all three (rejected — it would smear ownership and guarantee the very coupling they want to avoid). Comparing (b) against the intended architecture and each team's cognitive load, option (b) wins because its team boundaries and the intended module boundaries line up — the communication structure the org is about to create is the one that will induce the architecture they want. The workshop hands off a chosen design and the reasoning behind it; it does not itself reassign anyone.

How it works

The distinctive move is facilitated divergence then comparison against intent:

  • Make the target explicit. State the desired architecture up front — the module boundaries the group is trying to build — so team designs are judged against a real reference, not aesthetics.
  • Generate genuine alternatives. Produce several distinct team-boundary options, including deliberately different ones, rather than polishing a single foregone answer.
  • Compare on alignment and load. Score each option by how well its team boundaries would induce the intended architecture and how much cognitive load each team would carry, surfacing the trade-offs for the decider.

Tuning parameters

  • Participant range — who is in the room. Too narrow and the workshop reproduces one manager's view; too broad and it stalls, so it is tuned toward the people who own the affected boundaries.
  • Divergence pressure — how hard the facilitation pushes for genuinely different options versus variations on a favourite. Low pressure quietly collapses the workshop into rubber-stamping a decision already made.
  • Evaluation criteria weight — how much architecture alignment counts versus cognitive load, delivery speed, or headcount reality. The weighting silently determines the winner.
  • Time-box — a single session versus an iterated series. Longer allows real exploration; shorter forces convergence but risks a shallow option set.
  • Decision coupling — whether the workshop only recommends or is empowered to decide. Kept advisory, it stays a design tool; made decisional, it turns into a governance body.

When it helps, and when it misleads

Its strength is that it treats team boundaries as a design problem with alternatives rather than an administrative given, and it does so before the reorg, when changing course is still free. It is the natural front end to an inverse-Conway maneuver: deliberately shaping the communication structure so that the architecture you want emerges, instead of letting an inherited org dictate the design.[1]

It misleads when the divergence is theatre — a workshop convened to launder a decision already made, generating throwaway "alternatives" around a predetermined answer. It can also over-index on architecture alignment and ignore whether the org can actually staff the pretty design, or treat its recommendation as a mandate and bulldoze past the people who must live in the new structure. The discipline is to require genuinely distinct options, to make the evaluation weighting explicit rather than smuggled, and to keep the workshop a source of designs and reasoning that a real decision — and a real feasibility check — then acts on.

How it implements the components

The workshop realizes the design-generation face of the archetype — producing and weighing team-boundary options against intent, not enacting them:

  • team_topology_design_option_set — its primary product: the set of candidate team-boundary designs, each with its trade-offs made explicit.
  • desired_architecture_intent — it makes the target architecture explicit and uses it as the reference every option is scored against.

It does not enact the chosen design as an architecture-shaping maneuver — that is Inverse Conway Design Intervention — nor does it redraw ownership or test operability; those are Ownership Boundary Refactor and Pre-Refactor Operating-Model Check. It also derives its target from, rather than authoring, Bounded Context or Domain Boundary Review.

References

[1] The inverse Conway maneuver deliberately shapes teams so that their communication structure induces the architecture you want, rather than letting an existing organization dictate the design. The workshop's option set is the menu such a maneuver chooses from. ↩