Module 2: Conway's Law

7. Team topologies

Next →

Overview

By the end of this lesson you'll have the vocabulary to design an organization on purpose, instead of improvising it. Lesson 6's inverse maneuver told you what to do —redesign the organization to obtain the architecture you want—, but you did it by eye: "a team owning the checkout flow", "the platform as a service". Skelton & Pais, in their book Team Topologies, took those intuitions and turned them into a catalog of proven pieces. There are four team types —and only four worth having— and three interaction modes between them. The "checkout" team you designed has a name: stream-aligned (aligned to a value flow). "The platform as a service" is a pattern: a platform team that offers capabilities in x-as-a-service mode. You'll learn the four types, the three modes, and —what makes the vocabulary useful— the communication cost of each mode, measured: the same map of who-needs-whom can cost a coordination load of 15 or of 6, depending on the mode you choose for each relationship.

This matters because the vocabulary is what separates designing from improvising. Without it, every architect reinvents the organization from scratch, makes the same known mistakes, and can't communicate their design ("we need a team... that acts as a bridge... that helps the others but not permanently"). With it, you say "a temporary enabling team" and everyone understands. But the deepest value isn't naming, it's choosing the right interaction mode —and there's the number of this lesson—. Two teams that need each other can relate in three ways with very different costs: collaboration (they co-design together, high bandwidth, expensive), x-as-a-service (one consumes what the other provides, low bandwidth, cheap), or facilitating (one helps the other improve, temporary). The expensive mistake is treating everything as collaboration —having all the teams co-designing with everyone, drowning in meetings—. The art, measured, is reserving the expensive mode (collaboration) for where it's really needed and turning everything else into x-as-a-service. The same organization, depending on the modes you choose, flows or gets stuck.

Connection with the module: this lesson is the close of the cure arc and the culmination of the vocabulary. The whole module built toward here: Conway's Law (lesson 2) says the system copies the organization; the coordination cost (lesson 4) says why the communication modes matter so much; the friction per module (lesson 5) diagnoses; the inverse maneuver (lesson 6) reorganizes. This lesson gives the catalog of pieces with which that reorganization is done with precision: the four team types are the blocks, the three modes are how they connect, and the cost of each mode is the criterion for choosing. The stream-aligned + platform team you designed in lesson 6 becomes, here, a named and measured pattern. It's the bridge to the project (lesson 8), where you'll redesign the organization of a new Mercado capability using this catalog, and to module 3, where you'll communicate these designs to stakeholders.

The four roles on a construction site

Think of it this way. On a large, well-organized construction site, not everyone does everything. There are four types of crew, each with a clear role, and that clarity is what makes the site flow instead of being chaos.

There are the construction crews —the ones that actually raise the building, floor by floor—. Each owns a complete tower, from the foundations to the roof: they build their tower end to end and answer for it. They're the heart of the site; everything else exists so they flow. There are the shared-service providers —the concrete plant, the material warehouse, the central crane—: they don't build any tower, but they provide all the crews with what they need, so that each crew asks for concrete and receives it without having to set up its own plant. A service, consumed by all, that takes heavy work off their shoulders. There are the consulting specialists —the expert structural engineer who arrives when a crew needs to solve a complicated calculation, teaches them how, and leaves—: they don't stay permanently, they help the crew learn to do it on its own and then move on to another. And there are the complicated-subsystem crews —the ones who install the elevator or the high-voltage electrical system, things that require such deep specialization that it makes no sense for each construction crew to learn them—: they encapsulate a specific complexity so the others don't have to carry it.

Four roles: those who build the flow (the towers), those who provide a service (concrete, materials), those who enable temporarily (the consultant), and those who encapsulate the complicated (the elevator). A site where these roles are clear flows: each crew knows what's theirs, whom to ask for a service, and whom to call for the complicated. A site where everyone does everything and everyone consults with everyone is a chaos of people tripping over each other. The team topologies are exactly these four roles, applied to software teams: stream-aligned (the construction crews), platform (the service providers), enabling (the consultants), and complicated-subsystem (the elevator ones). This lesson defines them and measures how expensive each way of relating is.

The four team types and the three interaction modes

Before the executed example, the catalog. Skelton & Pais argue that almost any effective software organization is assembled with only four team types:

  • Stream-aligned (aligned to a value flow). It's the default team, the one that should be the majority. It owns a value flow end to end —a product, a feature, a user journey— and can deliver it without depending on others for the essential. Lesson 6's checkout team is stream-aligned: owner of the full purchase flow. Mercado's squads (catalog, orders, etc.) should be stream-aligned, and their pain comes precisely from not fully being it (they share checkout).

  • Platform. Provides capabilities as an internal service so stream-aligned teams don't have to build them each. Authentication, notifications, infrastructure, deployment: things everyone needs and no one should reinvent. The key: the platform offers this as a service with a stable contract, not by getting into each team's work. Mercado's platform (auth, notifications) is —or should be— a platform team.

  • Enabling. Helps stream-aligned teams overcome an obstacle or acquire a new capability —a testing practice, a technology, an architecture technique—, and does so temporarily: it arrives, teaches, and leaves when the team already knows how to do it alone. It's the site's consultant. It doesn't own any module; its product is that other teams improve. Its interaction is, by design, transient.

  • Complicated-subsystem. Encapsulates a part of the system that requires expertise so deep that it makes no sense for each stream-aligned team to carry it: a risk/fraud engine, a recommendation algorithm, a video codec, a math solver. It exists to take that cognitive load off the others. In Mercado, a fraud detection engine in payments would be a complicated-subsystem.

And those teams relate in only three interaction modes, each with a different communication cost:

  • Collaboration. Two teams work together, side by side, on a shared problem, for a time. It's high bandwidth —lots of communication, lots of synchronization— and therefore expensive. It's used to explore new territory or solve something neither of the two can solve alone. It's valuable but costly; it should be the exception, not the rule.

  • X-as-a-service (something-as-a-service). One team consumes what another provides, through a stable interface, with minimal communication. The consumer doesn't need to know how it works inside; it just uses the contract. It's low bandwidth —cheap— and it's how most teams should relate to the platform and to the complicated subsystems.

  • Facilitating. One team (typically enabling) helps another improve, temporarily. Medium bandwidth and —key— transient: it exists to end. When the helped team has learned, the interaction dissolves.

The design principle that ties it all: minimize the high-bandwidth modes. Collaboration is valuable but expensive; if your whole organization collaborates with everything, it drowns in coordination (lesson 4's n(n-1)/2, at its maximum). The goal is to reserve collaboration for the few boundaries where co-designing is really needed, and turn everything else into x-as-a-service —stable contracts that don't require coordinating every change—. We'll measure exactly how much that saves.

Worked example: the communication cost of each mode

We'll put a cost on each mode and measure two ways of organizing the same relationships. We give weight 3 to collaboration (expensive, high bandwidth), 1 to x-as-a-service (cheap), and 2 to facilitating (medium, temporary). We have a fixed map of who-needs-whom in Mercado, and we evaluate it under two arrangements: one where everything is collaboration (the default when no one designed the interactions) and another where the platform and the complicated subsystem are consumed as a service, and the enabling team only facilitates.

# Team topologies: each interaction mode has a different communication
# cost. We measure it over Mercado's teams.

# The 4 team types (Skelton & Pais).
teams = {
    "checkout":      "stream-aligned",
    "catalog":       "stream-aligned",
    "fulfillment":   "stream-aligned",
    "platform":      "platform",
    "payments-risk": "complicated-subsystem",
    "enabling":      "enabling",
}

# Communication weight per interaction mode:
# collaboration = high bandwidth, expensive, temporary (two teams co-design).
# x-as-a-service = low bandwidth, stable (one consumes, the other provides).
# facilitating  = medium, temporary (an enabling team helps another improve).
WEIGHT = {"collaboration": 3, "x-as-a-service": 1, "facilitating": 2}

# Who needs whom.
interactions = [
    ("checkout",    "platform"),
    ("catalog",     "platform"),
    ("fulfillment", "platform"),
    ("checkout",    "payments-risk"),
    ("enabling",    "checkout"),
]

def load(mode_of):
    total = 0
    print(f"{'interaction':<30}{'mode':<18}{'weight':>7}")
    for a, b in interactions:
        mode = mode_of(a, b)
        w = WEIGHT[mode]
        total += w
        print(f"{a+' -> '+b:<30}{mode:<18}{w:>7}")
    print(f"{'TOTAL LOAD':<48}{total:>7}")
    return total

# Arrangement 1: everything by collaboration (the default when no one designed the limits).
print("=== Arrangement A: everything is collaboration ===")
load_a = load(lambda a, b: "collaboration")

print()
# Arrangement 2: the platform and the complicated subsystem are consumed as a service;
# the enabling team only facilitates (temporarily).
print("=== Arrangement B: platform/complicated as-a-service, enabling facilitates ===")
def mode_b(a, b):
    if b == "platform":
        return "x-as-a-service"
    if b == "payments-risk":
        return "x-as-a-service"
    if a == "enabling":
        return "facilitating"
    return "collaboration"
load_b = load(mode_b)

print()
print(f"Communication load: {load_a} -> {load_b}  (down {(1-load_b/load_a)*100:.0f}%)")
print("The same map of who-needs-whom; different MODE of interacting.")

What to expect. Running it:

=== Arrangement A: everything is collaboration ===
interaction                   mode              weight
checkout -> platform          collaboration         3
catalog -> platform           collaboration         3
fulfillment -> platform       collaboration         3
checkout -> payments-risk     collaboration         3
enabling -> checkout          collaboration         3
TOTAL LOAD                                         15

=== Arrangement B: platform/complicated as-a-service, enabling facilitates ===
interaction                   mode              weight
checkout -> platform          x-as-a-service        1
catalog -> platform           x-as-a-service        1
fulfillment -> platform       x-as-a-service        1
checkout -> payments-risk     x-as-a-service        1
enabling -> checkout          facilitating          2
TOTAL LOAD                                          6

Communication load: 15 -> 6  (down 60%)
The same map of who-needs-whom; different MODE of interacting.

Stop at the two arrangements, because they're the same organization with two radically different costs.

The map of needs is identical; only the mode changes. Notice: the five interactions are the same in both arrangements —checkout needs platform, catalog needs platform, and so on—. We didn't add or remove any relationship. The only thing that changed is how they relate: in A everything is collaboration (co-designing side by side), in B the relationships with the platform and the complicated subsystem are x-as-a-service (consuming a stable service) and the enabling one is facilitating (temporary help). Same who-needs-whom, different mode, and the communication load drops from 15 to 6 —60% less—.

The default is the most expensive. Arrangement A —everything collaboration— isn't a straw man; it's what happens by default when no one designs the interactions. If you don't define how the teams relate, they end up collaborating on everything: meetings of everyone with everyone, each team getting into the others' work, because "we need to coordinate". That default costs 15. Arrangement B didn't eliminate any need; it chose the cheap mode where the cheap mode sufficed —consume the platform as a service instead of co-designing it, use the fraud engine as a service instead of getting into its guts—. The lesson: the saving doesn't come from the teams needing each other less, it comes from them relating in the cheapest way their need allows.

Collaboration is reserved, not distributed. In arrangement B no interaction remains in collaboration mode —all of them could become x-as-a-service or facilitating—. In a real organization some would remain: the boundaries where two teams really have to co-design something new (for example, if checkout and payments-risk were inventing together a payment flow neither understands yet). The point isn't to eliminate collaboration —it's valuable where it's needed— but to reserve it for those few boundaries and not leave it as the default mode of everything. Every relationship you can lower from collaboration to x-as-a-service is weight 3 that becomes weight 1: the greatest communication leverage an architect has.

Here's the lesson made into a number, and it closes the module: the team structure matters, but the interaction mode matters just as much. You can have the four team types perfectly defined and still drown if everyone collaborates with everyone (arrangement A, load 15). Organizational design doesn't end at "who is which team"; it includes "how each pair relates", and that second decision —the mode— is what this example measures. A platform team that insists on co-designing with every team that consumes it (collaboration) is a platform team that failed at its purpose: its reason for existing is to offer a stable service (x-as-a-service) so the others flow without coordinating it. The mode is where the design is won or lost.

An honest nuance about the weights. The numbers 3/1/2 are ordinals that reflect the relative bandwidth of each mode, not a measurement of hours —collaboration costs more than x-as-a-service, and that's what's robust; that it's exactly triple is an estimate—. The model's value isn't in the exact "15" or "6", but in the comparison: the same map of needs costs 2.5 times more if you solve everything with collaboration than if you choose the cheap mode where it fits. And that proportion holds regardless of the exact weights, because collaboration is always more expensive than consuming a service. The number gives you the direction and magnitude of the saving; it doesn't promise a figure of hours.

Deep dive: why only four types, and the "team API"

You might ask: why exactly four team types? Wouldn't there be infinite ways to organize? Skelton & Pais's argument is that most organizations have too many poorly-defined team types —"project" teams, "maintenance" teams, "integration" teams, "release" teams, various committees— and that almost all of those are either unnecessary or fit into one of the four fundamental ones. Reducing the catalog to four isn't an arbitrary limitation; it's a discipline of simplicity: every team should be able to say which of the four types it's in, and if it can't, its purpose is probably confused. The four types cover the four legitimate reasons for a team to exist: delivering a value flow (stream-aligned), providing a common capability (platform), enabling others (enabling), or encapsulating deep complexity (complicated-subsystem). A team that's none of those four is a team whose purpose should be questioned.

The concept that makes all this operable is the "team API" —the idea that each team exposes an interface toward the others, just like a software module—. A team's team API includes: what it provides (the code, the services, the APIs others consume), how you ask it for something (a ticket? a pull request? a chat channel?), how stable what it offers is, and how it communicates its roadmap. A platform team with a good team API is one where asking for a capability is as simple as reading a doc and calling an endpoint —zero need to coordinate with the team's people—. A team with a bad team API is one where to use its stuff you have to schedule a meeting, explain your case, wait—; that is, a team that forces collaboration when it should offer x-as-a-service. Designing the team API is designing the interaction mode: a good stable API enables the cheap mode (x-as-a-service); a poor or unstable API forces the expensive mode (collaboration). That's why a platform team's work isn't just to build capabilities, but to package them with an API so good that no one has to talk to them to use them.

This connects with the entire thread of the module. Conway's Law says the software's interfaces copy the teams' communication channels. The team API is the deliberate version of that: instead of letting the software's interfaces emerge from the accident of who-talks-to-whom, you design the communication channels on purpose (the team APIs, the interaction modes) to produce the software interfaces you want. It's the inverse Conway maneuver taken to its finest form: you don't just choose who owns what (lesson 6), but how each pair of teams communicates (the mode) and what each one exposes (the team API). The result is an organization where expensive communication is minimized and localized, and by Conway, a system with clean interfaces and few expensive dependencies. The vocabulary of team topologies is, at bottom, the manual for operating Conway's force with a surgeon's precision instead of by eye.

Common mistakes

Treating everything as collaboration (of the expensive default mode). What happens: no one defines the interaction modes, so all the teams end up co-designing with everyone —endless meetings, each team getting into the others' work, the feeling that "everything has to be coordinated"—. Why it happens: collaboration is the mode that emerges on its own when you design nothing; sitting down to work together seems natural and responsible. How to spot it: if your calendar is full of inter-team meetings and you feel you can't move forward without synchronizing with three teams, you're in arrangement A (load 15). How to fix it: ask for each relationship "do we really have to co-design this, or is it enough for one to consume a service from the other?"; turn into x-as-a-service everything you can, and reserve collaboration for the few boundaries that really demand it.

A platform team that collaborates instead of serving (of the failed platform). What happens: the platform team, instead of offering capabilities as a self-service, gets involved in the work of each team that consumes it —schedules meetings, "helps integrate", reviews every use—. Instead of removing load, it adds it, and becomes a bottleneck everything passes through. Why it happens: "giving good support" is confused with "getting into everything", and a team API that allows self-service is missing. How to spot it: if to use the platform you have to talk to the platform team every time, it's not a platform, it's a bottleneck. How to fix it: invest in the team API —documentation, stable contracts, self-service— so that consuming the platform is x-as-a-service (read and call) and not collaboration (meet and coordinate).

An enabling team that becomes permanent (of facilitation that doesn't end). What happens: an enabling team arrives to help another adopt a practice, but instead of teaching and withdrawing, it stays —does the work for the team instead of enabling it to do it alone—, and becomes a permanent dependency. Why it happens: it's faster to do it yourself than to teach, and it suits the helped team for the enabling to keep carrying the work. How to spot it: if an enabling team has been "helping" the same team with the same thing for a year, it stopped enabling and started making them dependent. How to fix it: the facilitating mode is temporary by design; set an exit date and measure success by whether the helped team was left capable of doing it alone, not by how much work the enabling did.

Exercises

Exercise 1 — Classify the teams. For each team, say which team topology type it is and why. (a) A team that builds and operates the complete "search for and buy a product" journey. (b) A team that maintains the CI/CD system and the deployment environments everyone uses. (c) A team of two machine learning experts that maintains the recommendation engine. (d) A group that for three months helps the squads adopt automated testing and then dissolves.

See solution
  • (a) Stream-aligned. It owns a value flow end to end (the search-and-buy journey) and delivers it complete. It's the default type and the one that should be the majority. Its product is directly value for the user.
  • (b) Platform. It provides a common capability (CI/CD, environments) as a service all teams consume, so none has to set up its own pipeline. Its success is measured by how easy it is for the others to use the platform without coordinating.
  • (c) Complicated-subsystem. It encapsulates a part that requires deep and scarce expertise (machine learning) that makes no sense for each stream-aligned team to learn. It exists to take that cognitive load off the others; the stream-aligned ones consume the recommendation engine without understanding its guts.
  • (d) Enabling. It helps other teams acquire a new capability (automated testing) and does so temporarily —it dissolves at three months—. Its product isn't code but that other teams improve; its mode is facilitating and its nature is transient.

The discipline: each team fits into one of the four. If a team doesn't clearly fit into any, its purpose is confused and should be questioned.

Exercise 2 — Choose the right mode. For each pair of teams that need each other, say which interaction mode (collaboration, x-as-a-service, facilitating) is the correct one and why. (a) A stream-aligned that needs authentication, and the platform team that provides it. (b) Two stream-aligned that are inventing together a new payment flow neither understands yet. (c) A stream-aligned that wants to learn to do chaos engineering, and an enabling team expert in it.

See solution

  • (a) X-as-a-service. The platform team provides authentication as a stable service; the stream-aligned consumes it by calling an API, with no need to co-design or coordinate with the platform team on each use. It's the cheap mode and it's exactly what a platform exists for. If this relationship were collaboration (meeting each time to use auth), the platform would have failed at its purpose.

  • (b) Collaboration. Here the expensive mode is justified: they're inventing something new neither understands yet, so they need to co-design side by side, with high bandwidth, exploring together. It's exactly the situation collaboration is valuable for —unknown territory that requires both heads at once—. That said: it must be temporary; when the payment flow is understood and stable, the relationship should drop to x-as-a-service (one exposes the payment as a service and the other consumes it).

  • (c) Facilitating. The enabling team helps temporarily the stream-aligned acquire the chaos engineering capability: it teaches, accompanies, and withdraws when the team already knows how to do it alone. It's not collaboration (they don't co-design a shared product) nor x-as-a-service (the enabling doesn't provide a permanent service); it's transient enablement. The success signal: that the stream-aligned is left capable of doing chaos engineering without the enabling.

The rule: x-as-a-service by default (cheap), collaboration only to invent something new together (expensive, temporary), facilitating to transfer a capability (temporary).

Exercise 3 — Redesign an expensive arrangement. In a company, the platform team collaborates (collaboration mode) with each of the four stream-aligned teams that consume it, because "that way it gives them better support". With the example's weights (collaboration=3, x-as-a-service=1), compute the load of those four relationships as they are, and how much it would drop if the platform team offered its capabilities as a service. What would it have to build to achieve the change?

See solution

Current load: four stream-aligned → platform relationships, all in collaboration mode (weight 3): 4 × 3 = 12.

Load if they were x-as-a-service (weight 1): 4 × 1 = 4.

Saving: from 12 to 4, a 67% less communication load, just by changing the mode of those four relationships. And the saving scales: each new team that consumes the platform adds weight 3 in collaboration but only weight 1 in x-as-a-service, so the more teams, the bigger the difference. A platform team that collaborates doesn't scale; one that serves does.

What the platform team would have to build to achieve the change: a good team API that enables self-service. Concretely: (1) clear documentation of what capabilities it offers and how to use them; (2) stable and versioned contracts/APIs, so teams consume without fear of it changing under their feet; (3) a self-service mechanism (portal, CLI, endpoints) to request/use capabilities without scheduling a meeting; (4) asynchronous support channels for questions, instead of getting involved in every integration. With that, using the platform goes from "meet and coordinate" (collaboration, expensive) to "read and call" (x-as-a-service, cheap). The moral: a platform team's reason for existing is to offer a service so good that no one has to talk to them to use it —"giving better support" by collaborating on everything is, paradoxically, a sign that the platform isn't doing its job—.

Summary and next step

In this lesson you acquired the vocabulary to design an organization on purpose. With the four roles on the construction site you saw Skelton & Pais's four team types: stream-aligned (owner of a value flow, the default type), platform (provides capabilities as a service), enabling (enables others, temporarily), and complicated-subsystem (encapsulates what requires deep expertise). And the three interaction modes: collaboration (expensive, to invent together), x-as-a-service (cheap, to consume a service), and facilitating (temporary, to transfer a capability). You measured it by executing: the same map of who-needs-whom in Mercado costs a communication load of 15 if everything is collaboration (the default when no one designs) and of 6 if you choose the cheap mode where it fits —60% less, without changing any need, only the mode—. You understood that organizational design doesn't end at "who is which team" but at "how each pair relates", that a platform team exists to offer x-as-a-service (not to collaborate on everything), and that the team API is what enables the cheap mode.

Before moving on you should be able to: classify teams into the four types and know which should be the majority; choose the right interaction mode for a pair of teams according to their need; explain why minimizing collaboration reduces the communication load; and recognize the anti-patterns (everything collaboration, the platform that gets into everything, the enabling that doesn't end).

What follows is putting the whole module together with your own hands. In lesson 8 —the project— you'll redesign Mercado's organization for a new capability we haven't seen in the lessons: the launch of reviews + recommendations, which a single growth squad receives whole. You'll produce the module's three artifacts: the org↔architecture map of the initial proposal, the executed measurement of its friction and its per-team load, and the inverse maneuver that fixes it using the team topologies catalog you just learned —separating the stream-aligned reviews team from the machine learning complicated-subsystem—. It's the proof that you learned to design the organization, not just diagnose it.

Resources

← Previous6. The inverse Conway maneuverNext →8. Project: redesign Mercado's organization for a new capability