Module 2: Conway's Law

4. The cost of coordination

Next →

Overview

By the end of this lesson you'll understand the economic engine that makes Conway's Law have such expensive consequences, and why "make small teams" isn't a soft management-handbook piece of advice but a conclusion that comes out of a formula. The formula is one of the simplest and most underrated of the craft: the number of one-to-one communication channels between n people is n(n-1)/2. What makes it important isn't the formula but its shape: it grows quadratically, not linearly. Doubling the team doesn't double the coordination —it multiplies it by four—. You'll execute this formula and see the cost explode: 2 people need 1 channel, 5 need 10, 10 need 45, and 50 people need 1225 possible communication channels. That quadratic growth is the mathematical reason a large team drowns in its own coordination, and why splitting the people into small teams —with the same number of people— lowers the coordination cost by a huge factor.

This matters because it connects the three pieces of the module into a single causal chain. Conway says the system copies the communication structure (lesson 2). The monolith reflects the single team that birthed it (lesson 3). But why doesn't the organization simply stay a big team, thereby avoiding all boundaries and their friction? Because coordination within a big team grows quadratically until it becomes unsustainable, and at some point it's cheaper to pay the cost of the boundaries (splitting into teams) than the cost of internal coordination (staying as one). The formula n(n-1)/2 is what fixes that point. It's also what justifies why the team topologies (lesson 7) insist on small teams —"two-pizza" sized—: it's not a trend, it's that above a certain size the coordination cost devours the capacity to build. And it's what explains why cross-team coordination is the tax Conway charges: every boundary you cross adds expensive channels, and the architect who understands this formula designs to minimize them.

Connection with the module: this lesson is the quantitative why. Lessons 2 and 3 showed that the organization shapes the system and that growing without splitting into teams misaligns; this one explains why growing that way is economically unsustainable —coordination explodes—. The formula you execute here is what gives force to everything that follows: the friction of the crossed module (lesson 5) is expensive because each pair of teams that must coordinate is a costly channel; the inverse maneuver (lesson 6) is worth it because it reduces cross-team channels; and the team topologies (lesson 7) prescribe small teams because n(n-1)/2 punishes big ones. If lesson 3 said "the one-team monolith breaks when split into five", this one says "and you can't avoid it by staying a giant team, because that costs even more".

The dinner that becomes impossible to coordinate

Think of it this way, with something we've all lived. You arrange to have dinner with one friend. Coordinating is trivial: one message, "8 at the usual place?", "sure", and done. A single communication channel, a single agreement.

Now the dinner is with four friends, five total counting you. Suddenly there's coordination among everyone: you with each one, and each one with the others, because someone proposes a different place, another can't at 8, another is vegetarian and the menu has to be checked. The channels aren't one anymore: among five people there are ten possible pairs that can be agreeing —you-Ana, you-Beto, you-Carla, you-Dani, Ana-Beto, Ana-Carla, and so on—. The dinner still gets organized, but the WhatsApp group already has a hundred messages.

Now imagine the dinner with fifty people. Coordinating "by messages among everyone" is simply impossible: there are 1225 pairs that could be discussing the place, the time, and the menu, and if you let everyone talk to everyone, nothing ever gets decided —the group becomes a chaos of a thousand voices—. What do you do in real life when you organize an event of fifty? You don't let everyone coordinate with everyone. You name an organizer, divide into tables, delegate. You impose a structure that reduces the channels: instead of 1225 conversations, there's one organizer who talks to five table leads, and each lead coordinates their table of ten. The structure isn't bureaucracy; it's the only way fifty people can do something without drowning in coordination.

A software team is exactly that dinner. Two engineers coordinate with a message. Five already need meetings. Fifty in a single team, "everyone coordinating with everyone", is the chaos of the fifty-person dinner —no one decides anything, all day is synchronization—. And the solution is the same: impose structure, divide into teams, delegate. Splitting fifty people into five teams of ten is like splitting the dinner into five tables: within each table the coordination is manageable, and between tables only a few representatives coordinate. This lesson is measuring, with the formula, exactly how much is saved by doing it —and why not doing it is mathematically unsustainable—.

Worked example: how coordination explodes

We'll execute the formula n(n-1)/2 to see the explosion with our own eyes, and then compare two organizations with the same people: 25 people in a single big team, against 25 people in five teams of five. The question the number answers is the module's: why split into small teams, if it's the same people?

# The cost of coordination: communication channels grow
# like n(n-1)/2 -- quadratically, not linearly.

def communication_paths(n):
    """How many one-to-one channels there are among n people."""
    return n * (n - 1) // 2

print("How the coordination cost explodes with team size:")
print(f"{'people (n)':>13}{'channels n(n-1)/2':>20}")
for n in [2, 3, 5, 8, 10, 15, 20, 30, 50]:
    print(f"{n:>13}{communication_paths(n):>20}")

print()
# The same headcount, two different organizations.
head = 25
one_big = communication_paths(head)                 # 1 team of 25
five_small = 5 * communication_paths(5)             # 5 teams of 5 (internal channels)
inter_team = communication_paths(5)                 # channels between the 5 teams (worst case)
print(f"25 people in ONE single team    : {one_big} channels")
print(f"25 people in 5 teams of 5       : {five_small} internal channels"
      f" + {inter_team} inter-team = {five_small + inter_team}")
print()
factor = one_big / (five_small + inter_team)
print(f"Splitting into small teams lowers the channels from {one_big} to {five_small + inter_team}")
print(f"-- a factor of {factor:.1f}x less coordination, with the SAME people.")

What to expect. Running it:

How the coordination cost explodes with team size:
   people (n)   channels n(n-1)/2
            2                   1
            3                   3
            5                  10
            8                  28
           10                  45
           15                 105
           20                 190
           30                 435
           50                1225

25 people in ONE single team    : 300 channels
25 people in 5 teams of 5       : 50 internal channels + 10 inter-team = 60

Splitting into small teams lowers the channels from 300 to 60
-- a factor of 5.0x less coordination, with the SAME people.

Stop at the first table, because its shape is the whole lesson. Notice how the numbers grow: from 2 to 3 people (one more) the channels go from 1 to 3; from 10 to 20 people (double) they go from 45 to 190 —more than four times, not double—; from 25 to 50 (double) they go from 300 to 1225 —again four times—. That's the hallmark of quadratic growth: every time you double the team, you quadruple the coordination. Adding person number 50 to a team doesn't add "a little" coordination; it adds 49 new channels at once (the ones that person has with each of the other 49). That's why a big team doesn't get slow gradually: it gets slow in an accelerating way, and there comes a point where people spend more time in synchronization meetings than writing code. The table shows you the cliff: 50 people "coordinating among everyone" are 1225 possible conversations, a simply ungovernable number.

Now the comparison that answers the module's question, and it's emphatic. Take 25 people. In a single big team, that's 25×24/2 = 300 possible communication channels —a team of 25 is already well inside the drowning zone—. Take exactly the same 25 people and split them into five teams of five. Within each team there are 5×4/2 = 10 channels, so across five teams that's 50. Between the five teams, in the worst case everyone coordinates with everyone, that's 5×4/2 = 10 more inter-team channels. Total: 60 channels, against the 300 of the single team. The same people, the same work, and the coordination went down by a factor of 5.

Here's the module's lesson made into a number: structure isn't bureaucracy, it's coordination reduction. Splitting into teams doesn't add overhead —it removes it—. The 300 channels of the giant team were the real overhead; the 60 channels of the five teams are what's left when you impose a structure that prevents everyone from coordinating with everyone. And notice where the saving comes from: from most of the coordination becoming internal to each small team (cheap, people who sit together) and only a little bit staying between teams (10 channels, the boundaries). This is the exact trade lesson 3 anticipated: at a certain scale, paying the cost of the boundaries (10 inter-team channels) comes out much cheaper than paying the cost of the internal coordination of a giant team (300 channels). The formula just fixed where it's worth splitting.

An honest nuance, because the model simplifies. n(n-1)/2 counts the possible channels, not the ones actually used: in a team of 25, not everyone talks to everyone all the time. The number is a ceiling, not an exact measurement of the time lost. But the ceiling matters for two reasons: first, because it marks the potential for chaos —the more possible channels, the harder it is for information not to get lost or contradicted—; second, because the quadratic shape holds regardless of what fraction of channels is really used —if in a team of 10 40% of the channels are used and in one of 20 also 40%, the one of 20 still has four times more real coordination—. The model doesn't say "you'll lose exactly 300 hours"; it says "coordination grows quadratically, so big teams drown and splitting them helps a lot", and that's robust.

Deep dive: Conway's tax and the two-pizza size

The formula n(n-1)/2 doesn't just explain why small teams win; it also explains the central concept of team topologies —which we'll see in full in lesson 7—: a team's cognitive load and why it must be kept bounded.

First, Conway's tax. Each cross-team dependency of your system (the eight you measured in Mercado) is an inter-team communication channel that has to exist for the system to work. And inter-team channels are the most expensive of all: it's not people who sit together, it's two teams with different contexts, different priorities, sometimes different bosses, that have to synchronize. If within a team a channel costs "a message", between teams it costs "a meeting, a ticket, a priority negotiation". That's why cross-team coordination is the tax Conway charges for every boundary your architecture crosses —and that's why the architect who understands this formula designs to minimize cross-team dependencies: not for elegance, but because each one is an expensive channel that slows two teams—. Reducing Mercado's cross-team dependencies from 8 to 4 isn't cosmetic; it's cutting in half the coordination tax the system charges the organization every day.

Second, the two-pizza size. Amazon popularized the rule that a team shouldn't be bigger than what two pizzas feed —about 5 to 8 people—. Now you have the mathematical reason: look at the table. A team of 8 has 28 channels (manageable); one of 15 has 105 (already hurts); one of 20 has 190 (drowning). The jump from 8 to 15 people almost quadruples the coordination. The two-pizza rule isn't corporate folklore; it's keeping n in the zone where n(n-1)/2 is still a governable number. Skelton & Pais formalize it as cognitive load: a team can only hold a certain amount of system and a certain amount of coordination in its head, and going past that makes it slow and error-prone —not for lack of talent, but for excess of channels—. The design consequence is twofold: teams must be small (to bound the internal coordination) and the pieces of system they own must be bounded (to bound the load they carry). A small team owning an enormous system drowns just the same, on the side of the code's cognitive load.

The synthesis, which ties the module together: the ideal organization per Conway isn't "a big team that avoids boundaries" (it drowns in internal coordination, 300 channels) nor "very many tiny teams that fragment everything" (they drown in coordination between teams, too many expensive boundaries). It's an intermediate point: teams small enough that internal coordination is cheap, few enough that the boundaries between them are manageable, and with the boundaries placed where the system has its natural seams —so the cross-team dependencies, the expensive tax, are the minimum—. Finding that point is the art lessons 6 and 7 turn into a method.

Common mistakes

Believing coordination grows linearly (of misleading intuition). What happens: a manager thinks "the team is slow, I add three people and it moves faster", and the team gets slower —the classic of The Mythical Man-Month: adding people to a late project makes it later—. Why it happens: intuition says the work gets divided (linear), but the coordination multiplies (quadratic); the three new people add three pairs of hands and dozens of communication channels. How to spot it: if every time you grow the team the velocity per person drops, you're paying the quadratic tax. How to fix it: instead of fattening a team, split it —add a new team, not one more person to the giant—; the table shows why five teams of five beat one of twenty-five.

Splitting into too many tiny teams (of over-fragmentation). What happens: to "reduce the size of the teams", someone creates fifteen teams of two people, and now the internal coordination of each team is trivial but the coordination between the fifteen teams is a hell —too many boundaries, too many expensive inter-team channels—. Why it happens: only the internal cost is optimized and it's ignored that boundaries also cost. How to spot it: if your teams are so small that every feature needs to coordinate among five of them, you over-fragmented. How to fix it: remember the goal is to minimize the total coordination (internal + between teams), not just the internal one; the optimal point is small but not tiny teams, with boundaries aligned to the system so the crossings are few.

Ignoring that badly-placed boundaries multiply the inter-team cost (of wrong boundaries). What happens: they split into five teams, but the boundaries cut the system where they shouldn't have, so almost every feature crosses several teams —like in Mercado, with checkout crossing four—. The result: few channels within each team but very many inter-team, Conway's tax at its maximum. Why it happens: the size of the teams is chosen (small, good) but not where the boundaries go (bad). How to spot it: a high proportion of cross-team dependencies (Mercado: 61.5%) means badly-placed boundaries. How to fix it: small teams aren't enough; the boundaries must match the natural seams of the system, so the expensive coordination (inter-team) is the minimum —exactly what the inverse maneuver (lesson 6) designs on purpose—.

Exercises

Exercise 1 — Compute the break-even. Use the formula n(n-1)/2. (a) How many channels does a team of 12 have? (b) If that team of 12 is split into two teams of 6, how many internal channels are there in total, and how many inter-team (worst case, the two teams coordinating)? (c) How much was saved?

See solution
  • (a) Team of 12: 12×11/2 = 66 channels.
  • (b) Two teams of 6: each has 6×5/2 = 15 internal channels, so 2×15 = 30 internal in total. Between the two teams, in the worst case, 2×1/2 = 1 inter-team channel (two teams → a single pair). Total: 30 + 1 = 31 channels.
  • (c) Saving: from 66 to 31 channels, a little over half. Factor ≈ 66/31 ≈ 2.1x.

The lesson: even splitting a medium team (12) into two lowers the coordination to less than half. And notice the inter-team coordination (1 channel) is tiny compared to the internal saving —that's why splitting almost always wins, as long as the boundaries are well placed—. The bigger the original team, the more dramatic the saving (splitting 50 into 5 saved a factor of 5x; splitting 12 into 2 saves 2.1x), because the quadratic term punishes bigger teams more.

Exercise 2 — The manager who adds instead of splitting. A team of 10 people is behind. The manager proposes hiring 5 more to reach 15 "and thus move 50% faster". Using the formula, explain why they'll probably move less, not more, and what they should have proposed.

See solution

Why it moves less: the communication channels go from 10×9/2 = 45 (team of 10) to 15×14/2 = 105 (team of 15). The coordination didn't grow 50% (like the headcount), it grew 133% —from 45 to 105—. Besides, the 5 new people need onboarding, which consumes time from the 10 existing ones. In the short term, the team dedicates so much extra time to coordinating and to incorporating people that the net capacity to build drops. It's the Mythical Man-Month: adding people to a late project makes it later, because coordination grows faster than capacity.

What they should have proposed: instead of fattening the team from 10 to 15, create a second team. Split the work into two areas with a clean boundary, form a team of ~5-8 for the new one, and keep the original bounded. That way the internal coordination of each team stays manageable (8×7/2 = 28 and 7×6/2 = 21 instead of a single 105), and only the cost of one inter-team boundary is paid. The rule: when a team is slow because of size, don't add people —split it—. And the condition: the boundary between the two teams has to match a natural seam of the system, or the saving gets eaten by the cross-team coordination tax (exercise 3).

Exercise 3 — Good boundaries against bad boundaries. Two companies split 20 people into 4 teams of 5. Company A places the boundaries where the system has natural seams, and it ends up with 3 cross-team dependencies. Company B places the boundaries haphazardly, and it ends up with 15 cross-team dependencies. Both have the same internal coordination. Which moves faster and why? What does this say about "make small teams" as an isolated piece of advice?

See solution

Internal coordination (same in both): 4 teams of 5 → 4 × (5×4/2) = 4×10 = 40 internal channels. Identical.

Inter-team coordination (the difference): company A has 3 cross-team dependencies, so ~3 expensive inter-team channels. Company B has 15, so ~15 expensive inter-team channels —five times more—. Remembering that an inter-team channel is much more expensive than an internal one (two teams with different contexts, not people who sit together), company B pays an enormous coordination tax that A doesn't pay.

Which moves faster: company A, by far. It has the same internal coordination but a fraction of the inter-team tax. Company B, despite having "small teams" (5 people, the right size), drowns because almost everything it does crosses boundaries and requires coordinating between teams.

What it says about "make small teams": that it's an incomplete piece of advice. Small size only optimizes the internal coordination. But the tax that really hurts at scale is the inter-team coordination, and that depends on where you place the boundaries, not on the size of the teams. "Small teams with wrong boundaries" (company B) can be worse than "slightly bigger teams with right boundaries". That's why the module doesn't stop at "make small teams": lessons 5, 6, and 7 are about where the boundaries go —aligning them with the system's seams so the cross-team dependencies, the expensive tax, are the minimum—. The size is the easy half; the placement of the boundaries is the half that makes or breaks.

Summary and next step

In this lesson you met the economic engine of Conway's Law: coordination grows quadratically, according to n(n-1)/2. With the dinner that goes from one friend to fifty you saw that above a certain size "everyone coordinating with everyone" is impossible, and that the solution is to impose structure —divide into tables, delegate—. And you measured it by executing: the table that shows the explosion (2→1, 10→45, 50→1225), and the comparison that answers the module's question —25 people in one team are 300 channels; the same 25 in five teams of five are 60, a factor of 5x less coordination with the same people—. You understood that structure isn't overhead but coordination reduction, that cross-team coordination is the expensive tax Conway charges for every boundary, that the two-pizza rule is n(n-1)/2 applied, and that "small teams" is only half the advice —the other half is where the boundaries go—.

Before moving on you should be able to: compute the communication channels of a team and explain why they grow quadratically; argue with numbers why splitting a big team lowers the coordination (and why adding people to it raises it); distinguish the internal coordination cost from the inter-team one; and explain why badly-placed boundaries multiply the expensive tax even if the teams are small.

What follows is applying all this to Mercado's concrete disease. In lesson 5 you'll measure the friction of the module that crosses two teams —checkout, which orders and payments fight over—. You'll see that when a single module forces four teams to coordinate simultaneously, that module concentrates a huge portion of the whole system's Conway tax. With this lesson's formula in hand, you'll understand why that friction is so expensive —each pair of teams that must be in the room is an inter-team channel of the most costly kind— and you'll be able to point out, with a number, which module is the one that most slows Mercado.

Resources

← Previous3. The monolith is your first org chartNext →5. The modules that cross team boundaries