Team Topologies

• When a delivery organisation is fighting itself: too many hand-offs, unclear ownership, work queuing at the boundary between teams rather than inside them.
• When you are standing up a new digital product or platform function and want to design reporting lines and interfaces before habits calcify around the wrong ones.
• When repeated reorganisations haven't fixed a throughput problem, and you suspect the team boundaries themselves, not the people occupying them, are the real constraint.
• When engineering, product and infrastructure functions need a shared, precise vocabulary for who owns what and how they're meant to interact, rather than each team inventing its own.

And when it doesn't

• When the organisation has no software or digital-product delivery function at all. The four team types and the 'as-a-service' interaction language are native to that world and translate poorly, word for word, into a professional-services firm, a manufacturing operation or a purely relationship-driven business.
• When the presenting problem is really about individual capability or leadership behaviour rather than structure. Redesigning team boundaries won't fix a manager who won't delegate or a function that's simply under-resourced.
• As a one-off diagramming exercise. The model only earns its keep if someone owns the resulting topology afterwards and keeps adjusting it as the work changes; drawn once and filed away, it's just an org chart with new labels.
• When there isn't enough authority in the room to actually move reporting lines, budget or headcount. Without that, mapping team types produces a wishlist, not a plan.

Before starting, gather the inputs the analysis depends on:

• A current map of teams, their size, their reporting lines and what each one actually spends its time on
• A rough map of the value stream(s) or product lines the organisation delivers against
• Visibility of where work queues, waits or gets handed off between teams, ideally with real lead-time data rather than impressions
• Honest input from the teams themselves on where the friction actually sits, which is often different from what the org chart implies

1. 1

   Map the current teams and the flow of work

   Lay out every team involved in getting a piece of work from idea to customer, and trace where it queues, waits or gets handed off. Use real examples of recent work, not the idealised process.

2. 2

   Classify each team against the four types

   Test whether each team is genuinely stream-aligned, or whether it's secretly acting as an accidental platform or complicated-subsystem team without anyone having named it that way, or given it the support that role needs.

3. 3

   Name the interaction mode at each boundary

   For every hand-off between teams, decide deliberately whether it should run as collaboration, X-as-a-service or facilitation, rather than leaving it to default to whatever grew organically.

4. 4

   Apply the reverse Conway manoeuvre where needed

   Where the desired architecture or value stream doesn't match the current team shape, redesign the team boundaries first, on the expectation that the system and its communication patterns will follow.

5. 5

   Set a review cadence and an owner

   Treat the topology as a living design rather than a one-off chart. Fix a review point, quarterly is typical, and name someone accountable for re-testing whether the boundaries still fit the work.

A topology: a small, named set of team types and the interaction mode at each boundary between them, mapped against the value stream(s) the organisation actually delivers against, with an explicit statement of where the current structure needs to change and why.

• Start at the stream-aligned teams. If there aren't any, or if every team touches every part of the work, the current structure has no real topology yet, just a headcount chart.
• Check each interaction mode against reality, not intention. A boundary labelled 'X-as-a-service' that still needs a personal favour every time isn't actually operating that way.
• Treat a heavy concentration of complicated-subsystem or platform teams relative to stream-aligned teams as a signal, not a verdict. It may be justified by genuine complexity, or it may be inertia dressed up as necessity.

• Treating the exercise as a relabelling exercise: renaming an existing functional team 'platform' without giving it product management, a roadmap or an actual internal API changes nothing about how work actually flows.
• Applying the four-type taxonomy too literally in a non-tech business, importing labels like 'stream-aligned' and 'platform' as if they are universal categories rather than vocabulary built for software delivery.
• Using the reverse Conway manoeuvre as cover to avoid a harder cultural or leadership conversation. Restructuring teams is often easier to get approved than confronting a manager who won't delegate.
• Redrawing the org chart once and walking away. A topology needs an owner and a fixed review cadence, otherwise it drifts back into its old shape within a couple of quarters.
• Ignoring the cognitive load ceiling of a stream-aligned team, loading it with more scope than it can reasonably hold just because the new chart looks tidy on a slide.

• Skelton, M. and Pais, M. (2019) Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland, OR: IT Revolution Press. ↗
• Conway, M.E. (1968) 'How Do Committees Invent?', Datamation, April 1968. ↗
• LeRoy, J. and Simons, M. (2010) Cutter IT Journal, December 2010. Generally credited as the source of the term 'inverse Conway manoeuvre'. ↗
• Team Topologies, 'Key concepts and practices for applying a Team Topologies approach', teamtopologies.com (current maintained definitions of the four team types and three interaction modes). ↗

Pairs well with McKinsey 7S Framework·RACI Matrix·Bridges' Transition Model·Situational Leadership·Team Psychological Safety·compare side by side

Near neighbours (computed from shared tags)·Hoshin Kanri·ADKAR Model·Balanced Scorecard