Module 2: Conway's Law

6. The inverse Conway maneuver

Next →

Overview

By the end of this lesson you'll have in your hands the craft's master move, the one that turns Conway's Law from a curse you suffer into a tool you use. It's called the Inverse Conway Maneuver, and the idea is as simple as it is powerful: if the system copies the structure of the organization, then to obtain the architecture you want, design the organization that would produce it. Instead of drawing three independent services and praying the teams respect the boundaries (which lesson 1 taught us erode), you form three independent teams, and the independent services come out almost on their own —because Conway's force, which before misaligned you, now pushes in the direction you want—. It's about stopping swimming against the current and using it as an engine. You'll apply the maneuver over lesson 5's diagnosis —the checkout that concentrates half of the friction by crossing four teams— and measure the result: restructuring the teams (creating a team that owns the entire checkout flow, turning the platform into a service) lowers the system's total friction from 12 to 5, 58% less, without touching the code first.

This matters because it inverts the sequence almost everyone tries to change an architecture with —and explains why almost everyone fails—. The instinct is: first I redesign the code (extract the service, separate the modules), and then, maybe, I adjust the teams. Conway guarantees that sequence reverts: if you reorganize the code but the teams keep sharing and coordinating like before, the code gradually returns to reflecting the real communication, and in a few months you're the same. The inverse maneuver flips the sequence: first the organization, then —and almost on its own— the architecture. You change who owns what and who talks to whom, and the code starts flowing toward the new shape because now the communication structure backs it. It's not that the code rewrites itself magically; it's that every refactor you do holds, because the organization stopped pushing against it. The maneuver is the recognition that the mold rules: change the mold and the concrete will take its shape; re-sculpt the concrete without changing the mold and it will return to the old shape.

Connection with the module: this lesson is the first of the two cures, and the one that gives its name to the module's central twist. Lesson 5 delivered the precise diagnosis (checkout = 6 of 12 friction pairs); this one cures it and measures the cure. It reuses exactly the same model —the same modules, the same dependencies— and only changes the organization, to isolate that the improvement comes from restructuring teams, not from rewriting code. It's the practical application of everything before: Conway's Law (lesson 2) says the system copies the organization, so —inverse maneuver— changing the organization changes the system; the coordination cost (lesson 4) says why reducing crossings is worth it; the friction per module (lesson 5) says where to apply the maneuver. Lesson 7 (team topologies) will give you the vocabulary to design the target organization with precision; this one gives you the principle and the measurement of the before-and-after.

To change a river's course, don't push the water

Think of it this way. A river comes down a slope and, on reaching the valley, makes a sharp curve that floods a field every rainy season. You want the water to pass straight, without the curve. You have two ways to try it.

The first, the naive one: push the water. You put sandbags, divert the flow by hand, dig a little channel to guide the current where you want. It works... for a few days. As soon as it rains hard, the water returns to its usual curve, knocks down the sandbags, and re-floods the field. You're fighting the water every season, forever, and you always lose —because the water doesn't follow your sandbags, it follows the shape of the terrain—. The course (the curve) is determined by the geography, not by your one-off efforts.

The second, the one that works: change the terrain. Instead of pushing the water, you excavate a new, straight course, and block the old one with an embankment. Now the water passes straight not because you're pushing it, but because the terrain carries it there naturally. You don't have to do anything every season; the river flows straight on its own, because you changed the shape that determines its course. A big job once, instead of a small fight forever.

The code is the water; the organization is the terrain. Redesigning the code without changing the teams is pushing the water with sandbags: the code returns to its old shape as soon as you stop pushing, because it follows the terrain of the communication, not your refactors. The inverse Conway maneuver is changing the terrain: you reorganize the teams (excavate the new course) and the code flows toward the architecture you want, on its own, because now the communication structure carries it there. It's more work at once —reorganizing teams isn't trivial— but it's a job that holds, instead of a fight that repeats every season. This lesson measures how much changing the terrain straightens the river.

Worked example: the inverse maneuver, measured

We'll take lesson 5's diagnosis —the system's total friction is 12, and checkout contributes 6— and apply the inverse maneuver to it. The target organization is designed on purpose with two moves:

  1. A stream-aligned team owning the entire checkout flow. Instead of orders and payments fighting over checkout (two owners, six friction pairs), we create a checkout team that owns the purchase flow end to end —checkout, cart, order processing—. A single owner where there were two.
  2. The platform as a service. auth and notifications stop being things anyone edits and become platform services with stable contracts: the other modules consume them without coordinating every change. Depending on auth no longer puts platform in the room.

And we measure the total friction before and after. Notice the model: the dependencies that cross toward a platform service (as_a_service) no longer put that team in the room, because they're consumed by contract, not by co-change.

# The inverse Conway maneuver, simulated: we change the ORGANIZATION
# to OBTAIN the architecture we want, and measure the friction before/after.
from itertools import combinations

deps = {
    "search":             ["product_catalog"],
    "cart":               ["product_catalog"],
    "checkout":           ["cart", "payment_processing", "shipping_labels",
                           "notifications", "order_processing"],
    "order_processing":   ["shipping_labels", "auth"],
    "payment_processing": ["invoicing", "auth"],
    "invoicing":          ["notifications"],
    "shipping_labels":    ["delivery_tracking"],
}
modules = ["product_catalog", "search", "cart", "order_processing", "checkout",
           "payment_processing", "invoicing", "shipping_labels",
           "delivery_tracking", "auth", "notifications"]

def total_friction(owners, as_a_service):
    """Sum of C(k,2) over all modules. Dependencies toward a platform
    service (as_a_service) do NOT put that team in the room:
    they're consumed by a stable contract, not by co-change."""
    total = 0
    for m in modules:
        room = set(owners[m])
        for d in deps.get(m, []):
            if d not in as_a_service:
                room |= owners[d]
        total += len(list(combinations(room, 2)))
    return total

# BEFORE: 5 squads by domain, checkout co-owned by orders and payments,
# and everything is co-changed (coupled monolith, no platform services).
before_owners = {
    "product_catalog": {"catalog"}, "search": {"catalog"},
    "cart": {"orders"}, "order_processing": {"orders"},
    "checkout": {"orders", "payments"},
    "payment_processing": {"payments"}, "invoicing": {"payments"},
    "shipping_labels": {"shipping"}, "delivery_tracking": {"shipping"},
    "auth": {"platform"}, "notifications": {"platform"},
}
before_service = set()   # nothing is a service: everything is co-changed

# AFTER: inverse maneuver. (1) a stream-aligned 'checkout' team that owns
# the full flow (cart + order_processing + checkout), a single owner;
# (2) auth and notifications become platform services (stable contract).
after_owners = {
    "product_catalog": {"catalog"}, "search": {"catalog"},
    "cart": {"checkout"}, "order_processing": {"checkout"},
    "checkout": {"checkout"},
    "payment_processing": {"payments"}, "invoicing": {"payments"},
    "shipping_labels": {"shipping"}, "delivery_tracking": {"shipping"},
    "auth": {"platform"}, "notifications": {"platform"},
}
after_service = {"auth", "notifications"}   # platform as a service

fb = total_friction(before_owners, before_service)
fa = total_friction(after_owners, after_service)

def checkout_pairs(owners, as_a_service):
    room = set(owners["checkout"])
    for d in deps["checkout"]:
        if d not in as_a_service:
            room |= owners[d]
    return len(list(combinations(room, 2)))

print(f"{'scenario':<38}{'#checkout owners':>18}{'total friction':>16}")
print(f"{'BEFORE (5 squads, shared checkout)':<38}"
      f"{len(before_owners['checkout']):>18}{fb:>16}")
print(f"{'AFTER  (inverse Conway maneuver)':<38}"
      f"{len(after_owners['checkout']):>18}{fa:>16}")
print()
print(f"checkout friction : {checkout_pairs(before_owners, before_service)}"
      f" -> {checkout_pairs(after_owners, after_service)} pairs")
print(f"total friction    : {fb} -> {fa}"
      f"  (down {(1-fa/fb)*100:.0f}%)")
print("We didn't touch the code first: we moved the TEAMS, and the friction fell.")

What to expect. Running it:

scenario                                #checkout owners  total friction
BEFORE (5 squads, shared checkout)                     2              12
AFTER  (inverse Conway maneuver)                       1               5

checkout friction : 6 -> 3 pairs
total friction    : 12 -> 5  (down 58%)
We didn't touch the code first: we moved the TEAMS, and the friction fell.

Stop at the numbers, because they're the module's thesis made into a result.

The total friction fell from 12 to 5 —58%— without touching the code. The same module map, the same dependencies, byte for byte identical. The only thing that changed was the organization: a single owner for the checkout flow, and the platform turned into a service. And with that single change, more than half of the system's coordination friction disappeared. This is the inverse maneuver in action: we didn't redesign the system, we redesigned the organization, and the system —measured by its friction— improved as if we'd redesigned it. We changed the terrain, and the river straightened.

Checkout dropped from 6 to 3 pairs, and from 2 owners to 1. The module that concentrated half the friction calmed by half. Notice where the improvement came from, because it has two distinct sources: (1) giving it a single owner (#owners: 2 → 1) eliminates the co-ownership friction —there are no longer two teams fighting over it—; (2) turning notifications into a platform service takes platform out of the checkout room —you no longer have to coordinate with platform for every checkout change—. What remains (3 pairs) is checkout's genuine coordination with payments (charging) and with shipping (shipment): those are real dependencies that can't be wished away —checkout really does need to charge and ship—. The maneuver doesn't take the friction to zero (that would be dishonest); it takes it to its irreducible minimum —the coordination the business really requires—, removing the artificial friction of the bad organization.

Here's the lesson made into a number: first the organization, then the architecture. We didn't touch the code —the last line of the output says so—, and even so the friction fell 58%. Why? Because the friction didn't live in the code, it lived in the organization that owned it. Changing the terrain of the communication (who owns what, what's consumed as a service) changed the cost of operating the system without moving a line. And most important for your career: this improvement holds. Since now a single team owns checkout, the refactor that team does to properly separate charging from the order won't erode, because there's no second team pushing cross dependencies against it. The code will flow toward the clean shape because the organization, at last, backs it. We excavated the new course; now the water runs on its own.

An honest nuance, because the maneuver has its fine print. The model treats "turning into a service" as a switch —auth and notifications go from co-change to stable contract overnight—, and in reality that's work: defining the contract, versioning it, hardening it so there really is no coordination needed for every change. The inverse maneuver enables that work (the new organization makes it worth it and makes it hold), but doesn't make it free or instant. Likewise, moving the checkout team to own three modules that were previously in two squads implies reassigning people, transferring knowledge, and enduring a few months of transition. The 58% is the destination, not day one. What the number proves isn't that the reorganization is free, but that it's the right lever: the same effort invested in reorganizing the organization yields an improvement that holds, while invested only in rewriting code it yields an improvement that erodes.

Deep dive: when the maneuver works, when it's unnecessary surgery

The inverse maneuver is powerful, and like every powerful tool, misused it does harm. Reorganizing teams is one of the most expensive and disruptive interventions that exist —it moves people, breaks relationships, costs months of productivity during the transition—. Applying it when it's not needed is major surgery for a scratch. Three criteria to know when it's worth it.

First: the maneuver is for architectures you want to change, not for the ones that already work. If your organization and your architecture are already aligned —the modules have single owners, the cross-team friction is low—, reorganizing buys nothing and does destroy the knowledge and relationships that make the teams productive. The maneuver is justified when there's a measured and painful misalignment (like Mercado's 58% of avoidable friction) and a clear target architecture toward which to move. Without a clear target, reorganizing is just shaking the org chart and hoping for luck —the anti-pattern of "perpetual reorganizations" that leave everyone dizzy and the architecture the same—.

Second: the maneuver designs the organization from the desired architecture, not the other way around. The correct order is: (1) decide what architecture you want (independent services for catalog, checkout, payments, etc.); (2) design the organization that would produce it (one team per service, with the system's boundaries matching the teams' boundaries); (3) reorganize toward that organization; (4) let the code flow toward the architecture. The mistake is reorganizing first "because it was due" and seeing what architecture comes out —that's letting the organizational accident dictate the system, exactly what Mercado suffered—. The inverse maneuver is deliberate: you choose the architecture, and from it you derive the organization.

Third: the maneuver doesn't eliminate necessary coordination, only artificial coordination. We saw checkout's friction drop from 6 to 3, not to 0. That 3 is the real coordination —checkout needs to talk to payments and shipping because it really charges and ships—. A common mistake is to expect the maneuver to take all the friction to zero and get frustrated when it doesn't, or worse, to force artificial boundaries to eliminate coordination the business really requires (splitting checkout from payments when charging is an essential part of checkout). The well-done maneuver recognizes the irreducible coordination and lets it flow through the cheapest possible channel (a stable service contract, not a shared kitchen), instead of pretending to abolish it. There are dependencies that are the essence of the business; those aren't organized to eliminate, they're organized to cost the minimum.

The synthesis: the inverse maneuver is the mature recognition that the architect doesn't draw systems, they design the organizational conditions for the right system to emerge. It's the opposite of the ivory-tower architect who delivers a diagram and leaves (the anti-pattern of module 1). The architect who understands Conway knows their diagram is worth nothing if the organization can't sustain it, so their true intervention is on the organization —and that intervention, well measured and well directed, moves the system more than any refactor—.

Common mistakes

Reorganizing the code before the organization (of inverted sequence). What happens: the team extracts a service from the monolith, celebrates the separation... and in six months the service is as coupled to the monolith as before, because the same teams keep sharing it. Why it happens: rewriting code feels like tangible progress; reorganizing teams feels political and out of reach. How to spot it: if you separate modules in the code but don't change who owns them or who coordinates with whom, you're pushing the water with sandbags. How to fix it: invert the sequence —first the organization (excavate the course), then the code flows—; the inverse maneuver exists precisely for this.

Reorganizing without a target architecture (of blind reorganization). What happens: the company "reorganizes to improve" every six months, moving teams without a clear map of what architecture it wants, and the only constant is the dizziness —the architecture stays as tangled as ever, only now with new confused people—. Why it happens: reorganizing is used as a signal of action without the work of deciding where to. How to spot it: if you can't draw the target architecture your reorganization should produce, you're shaking the org chart with no direction. How to fix it: decide the desired architecture first, derive the organization from it, and only then reorganize —the maneuver is deliberate, not a ritual—.

Using the maneuver where it's not needed (of unnecessary surgery). What happens: an architect reads about the inverse maneuver and reorganizes teams that already worked well and were aligned, destroying relationships and knowledge for an improvement that didn't exist. Why it happens: the tool is so attractive that it's applied without measuring whether there's a problem it solves. How to spot it: if you reorganize without being able to show a measured and painful misalignment (high cross-team friction), you're operating on a healthy patient. How to fix it: measure first (lesson 5); the maneuver is justified only when there's significant avoidable friction and a clear target architecture —if the friction is already low, leave the team alone—.

Exercises

Exercise 1 — Design the organization from the architecture. Mercado decides it wants payments to be a truly independent service —that the payments team can change and deploy charging without coordinating with anyone—. According to the inverse maneuver, what organizational changes would be needed to produce that architecture? Think about ownership and which dependencies would have to become services.

See solution

For payments to be a truly independent service (change and deploy without coordinating), the inverse maneuver requires designing the organization that produces it:

  1. Single and complete owner of the payment domain. The payments team must own payment_processing and invoicing in their entirety —which it almost already has—, without any other team getting its hands into them. No co-owned payment module.

  2. Take payments out of the checkout co-ownership. Today payments co-owns checkout (that's why checkout crosses four teams). For payments to be independent, checkout must belong to another team (the maneuver's checkout team), and that team must consume payments as a service —call a stable charging API—, not edit the payment module. That way payments stops sharing code with the checkout flow.

  3. Stabilize payments' dependencies toward other teams. payment_processing depends on auth (platform). For payments to deploy without coordinating, that dependency must be toward a platform service with a stable contract (auth-as-a-service), not toward something platform changes and forces payments to adapt to.

With those three changes, the communication payments needs to operate becomes internal (within its own team) or through stable contracts (which don't require coordinating every change). And then —inverse maneuver— the payments code naturally separates into an independent service, because the organization already treats it as one. Notice the pattern: we don't draw "payments is a microservice" and wait; we design the organization (single owner, checkout as consumer, platform as service) that produces that microservice.

Exercise 2 — The refactor that erodes. A team, without changing the organization, dedicates a quarter to cleanly separating the checkout module into two submodules: one for the order (for orders) and one for the payment (for payments). When they finish, the code is impeccably separated. Predict, using Conway's Law, what will happen in the following six months and why. What should they have done differently?

See solution

What will happen: the impeccably separated code will re-couple in the following months. Since orders and payments keep co-owning checkout (the organization didn't change), the two teams will keep having to coordinate over that area. And every time they coordinate under pressure —an urgent bug, a feature with a deadline—, they'll put in the fastest shortcut: a direct call from the order submodule to the payment one, a "temporary" shared piece of data, a "just for now" cross dependency. In six months, the two "clean" submodules will be as intertwined as the original checkout. It's pushing the water with sandbags: the refactor erodes because the terrain of the communication (two teams sharing) didn't change, and the code flows back toward the shape that terrain dictates.

What they should have done differently: apply the inverse maneuver before or together with the refactor. Instead of separating the code and leaving two owners, they should have first given checkout a single owner —a team that owns the full flow—. With a single owner, the code separation holds, because there's no second team pushing cross dependencies against it: the single owning team can maintain whatever internal boundary suits it, and no one from outside erodes it. The module's rule: reorganizing the code without reorganizing the teams reverts; reorganizing the teams makes the code reorganize —and stay— on its own. The refactor quarter wasn't useless, but it was the second step executed as if it were the first.

Exercise 3 — Maneuver or scalpel too far? For each situation, decide whether the inverse maneuver is justified or would be unnecessary surgery, and why. (a) A system where 55% of the dependencies cross teams and there are three co-owned modules causing constant delays. (b) A system where each team owns its modules, the cross-team friction is low, but the CTO read about microservices and wants to reorganize "to modernize". (c) A five-person startup in one team with a monolith that works well.

See solution

  • (a) Justified. There's a measured and painful misalignment (55% cross-team, three co-owned modules, constant delays) and a clear direction of improvement (give them single owners, align boundaries). This is the textbook case of the inverse maneuver: reorganizing toward a target architecture with a clearly broken current architecture. It's worth the cost of the reorganization because the avoidable friction is high.

  • (b) Unnecessary surgery. The system is already aligned —each team owns its modules, low cross-team friction—. Reorganizing here buys nothing (there's no avoidable friction to reduce) and does destroy the relationships and knowledge that make the teams productive. The motive ("the CTO read about microservices", "modernize") isn't a measured misalignment, it's a trend. Operating on a healthy patient. The right answer: don't reorganize; if anything, measure first, and since the friction is low, leave the team alone.

  • (c) Unnecessary surgery (and over-engineering). Five people in one team with a working monolith is the right Conwayan architecture for that size (lesson 3): one team, one monolith, zero boundaries to coordinate. Applying the inverse maneuver to split into microservices here would create boundaries the organization doesn't need, pure cost with no benefit. The maneuver applies when the organization has already grown enough to justify boundaries; at five, it hasn't. Leave the monolith.

The lesson: the inverse maneuver is justified by a measured misalignment plus a clear target architecture, not by trend or reflex. Only (a) meets the two conditions.

Summary and next step

In this lesson you learned the module's master move: the inverse Conway maneuver —to obtain the architecture you want, design the organization that would produce it—. With the river and the course you saw that pushing the water (redesigning the code) is a fight that repeats and is lost every season, while changing the terrain (reorganizing the teams) straightens the river on its own and forever. And you measured it by executing: applying the maneuver to Mercado's checkout —single owner for the purchase flow, platform as a service— lowered the system's total friction from 12 to 5 (–58%) and checkout's from 6 to 3, without touching the code first; what remained is the irreducible coordination (checkout really needs to charge and ship), not the artificial one of the bad organization. You understood that the correct sequence is organization first, architecture after (and almost on its own); that the maneuver is justified only with a measured misalignment and a clear target architecture; and that its virtue is that the improvement holds because the organization stops pushing against it.

Before moving on you should be able to: apply the inverse maneuver —derive the organization that would produce a desired architecture—; measure the before-and-after of a reorganization's friction; explain why reorganizing the code without the organization erodes; and distinguish when the maneuver is justified from when it's unnecessary surgery.

What follows is the vocabulary to design the target organization with precision, instead of by eye. The inverse maneuver told you what to do (redesign the organization); the team topologies of lesson 7 tell you how: the four team types —stream-aligned (owner of a value flow), platform (provides capabilities as a service), enabling (helps others improve), and complicated-subsystem (encapsulates what requires deep expertise)— and the three interaction modes, with their communication cost measured. You'll see that the "checkout team owning the full flow" we designed here has a name (stream-aligned) and that "the platform as a service" is a pattern (platform + x-as-a-service). It's going from improvising the organization to designing it with a catalog of proven pieces.

Resources

  • Skelton & Pais — Team Topologies, on the Inverse Conway Maneuver — the book that popularized the maneuver (the term predates the book and is attributed to ThoughtWorks); it explains in detail how to design the organization from the desired architecture, the heart of this lesson.
  • Martin Fowler — "Conway's Law" — the section on the inverse maneuver ("if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins"), the phrase that sums up why you change the organization first.
  • ThoughtWorks Technology Radar — "Inverse Conway Maneuver" — the technical entry that treats the maneuver as an engineering technique with its warnings (when to apply it and when not), useful for the "maneuver or scalpel too far" judgment.
← Previous5. The modules that cross team boundariesNext →7. Team topologies