1. Module introduction: you ship your org chart

Overview

By the end of this lesson you'll understand the most underrated law of the craft, the one that explains why so many "perfect" redesigns fail without anyone knowing why: a system's structure is a copy of the communication structure of the organization that builds it. Melvin Conway formulated it in 1968 and that's why it's called Conway's Law, but in the hallways it's said shorter and more brutally: you ship your org chart. No matter how pretty your diagram is; the software that comes out at the end has the shape of how the teams that wrote it communicate. If two teams barely talk, the seam between their two pieces of the system will be fragile and it'll be right there, in the silence between them. If one team does everything, the system will be a single ball with no internal seams. It's not a tendency or a superstition: it's a force as reliable as organizational gravity, and this entire module is about learning to see it, measure it, and —most importantly— use it in your favor.

This matters because it relocates the architect's greatest leverage. In module 1 we saw that the architect isn't the one who draws the diagram and leaves; it's the one who enables, communicates, and makes expensive decisions reversible. Conway's Law puts numbers on why: if the system copies the organization, then the diagram isn't the lever —the organization is—. You can draw three independent services until your hand hurts, but if you hand them to two teams that share everything and step on each other daily, you won't get three independent services: you'll get a distributed monolith, which is the worst of both worlds —the complexity of the network without the independence of the services—. The real communication structure always beats the desired diagram. That's why the architect who understands Conway stops fighting the org chart and starts treating it as what it is: the first architecture decision, and the hardest to reverse.

Connection with the module: this lesson is the map, not the territory. Here you don't measure anything in depth yet; you understand why the six lessons that follow go in the order they go. First the statement and its measurement: lesson 2 formulates the law and measures the mirror org↔code over Mercado. Then the origin of almost every monolith: lesson 3 shows why Mercado's monolith reflects the single team that birthed it, and what happens when the organization grows but the code doesn't. Then the economic mechanism that explains it: lesson 4 executes n(n-1)/2 and demonstrates why coordination explodes and small teams win. With that you can already diagnose the disease: lesson 5 measures the friction of the module that crosses two teams —Mercado's checkout—. And the last two give you the cure: lesson 6 is the inverse Conway maneuver (change the organization to obtain the architecture), and lesson 7 is Skelton & Pais's team topologies —the four team types and the three interaction modes—. Lesson 8, the project, puts you to redesigning Mercado's organization for a new capability with your own hands.

A bridge built by two crews that don't talk

Think of it this way. A construction company has to build a bridge across a wide river. The bridge is one, but the work is split between two crews: the north one starts from the north bank, the south one from the south bank, and they're supposed to meet in the middle. Both crews are excellent. The problem is they work in separate camps, kilometers apart, with different bosses, and coordinate by emails that sometimes get answered and sometimes don't. Each interprets the blueprints its own way. The north one uses a certain steel thickness; the south one, another. The north one leaves the bolts on the left; the south one expects them on the right.

Where will the bridge's weak point be? It's no mystery. It'll be exactly in the center, at the seam where the two crews meet —right where their communication was poorest—. All the length one crew built alone will be fine, because there the right hand knew what the left was doing. But at the seam, where two organizations that barely talked had to fit their work together, is where the millimeters that don't match appear, the steel of different thicknesses, the bolts that don't align. The bridge's seam falls where the organization that built it was divided. Not because the crews were bad, but because a physical seam is the reflection of a communication seam.

Software works exactly the same. Every time two teams have to fit two pieces of the system together, there —in that integration, in that contract, in that format one produces and another consumes— is where the integration bugs appear, the assumptions that don't match, the field one sent as text and another expected as a number. And that friction point falls precisely where the organization was divided. If you want to know where a system will fail before it's built, don't look at the technical diagram: look at the org chart, and find the places where two teams that don't talk well will have to fit their work together. There's your fragile seam. That's Conway's Law, and that's why it's so useful: it lets you predict the shape of the system by looking at the shape of the organization.

The case: Mercado and its five squads

Let's come down from the bridge to software. Throughout this guide we accompany Mercado, the ecosystem's marketplace. But it's no longer just a system: it's a system and its organization. Today Mercado has five squads:

• catalog — the product catalog and search.
• orders — the cart, order processing, and checkout.
• payments — charging and invoicing.
• shipping — shipping labels and delivery tracking.
• platform — the cross-cutting capabilities: authentication, notifications, the shared infrastructure.

It wasn't always five. In 2019, Mercado was a single team of seven people that wrote a monolith —everything in one codebase, one deployment—. It worked wonderfully while they were few. But the business grew, they hired, and at some point they split the people into five squads by domain. What they did not split was the code: the monolith is still a monolith, and now five squads try to own it in pieces, stepping on each other at the seams. The most painful symptom is checkout: a module orders considers its own but that payments touches all the time, because checkout is where the order and the charge embrace. Every change to checkout needs both squads to agree. It's slow, it's fragile, and no one quite understands why —until you see the blame isn't on the people, it's on the structure—.

Throughout the module we'll measure all this in Mercado, not assert it. But before measuring anything, let's see Conway's Law in its purest form: the ability to predict the architecture by looking at the organization. Look closely, because this little piece of code condenses the whole module.

# Conway in one line: give me how your organization communicates
# and I'll tell you where your system's seams will fall.
# Both graphs are THE SAME graph.

# How Mercado's squads communicate today (who coordinates with whom):
org_comm = [
    ("orders", "catalog"),
    ("orders", "payments"),
    ("orders", "shipping"),
    ("orders", "platform"),
    ("payments", "platform"),
]

n_squads = 5
print(f"Squads in Mercado: {n_squads}")
print(f"Active communication channels between squads: {len(org_comm)}")
print()
print("Conway predicts: the system will have ONE seam (interface between modules)")
print("per communication channel. The seams will fall EXACTLY here:")
for a, b in org_comm:
    print(f"  interface  {a}  <-->  {b}")
print()
print(f"Predicted seams in the system: {len(org_comm)}")
print("The communication org chart and the module map are the same drawing.")

What to expect. Running it:

Squads in Mercado: 5
Active communication channels between squads: 5

Conway predicts: the system will have ONE seam (interface between modules)
per communication channel. The seams will fall EXACTLY here:
  interface  orders  <-->  catalog
  interface  orders  <-->  payments
  interface  orders  <-->  shipping
  interface  orders  <-->  platform
  interface  payments  <-->  platform

Predicted seams in the system: 5
The communication org chart and the module map are the same drawing.

Stop at the last line, because it's the whole law in one sentence. We ran no technical analysis of the system; we only looked at how the five squads communicate and with that we predicted where the system will have its interfaces between modules. Each communication channel between two squads will materialize as a seam in the code —an API, a contract, a shared format—, and those seams will fall exactly where the channels are. The communication org chart and the module map are not two similar drawings: they're the same drawing. That's why Conway is so powerful as a prediction tool: it lets you read the future shape of the system in the present shape of the organization, before writing a line.

Now, notice something this teaser already hints at and that will be the module's thread: orders is at the center of almost everything —it talks to catalog, payments, shipping, and platform—. Four of the five channels pass through orders. That's no coincidence: it's because checkout, which lives in orders, is the point where the entire purchase flow comes together. A module that needs to talk to four different teams is a module that will accumulate friction, and in lesson 5 we'll measure exactly how much. For now, keep the intuition: the organization's topology is already telling you where the system will hurt.

The map of the six lessons

The six lessons that follow go in this order for a reason: each one assembles the piece the next one needs.

Lesson	What it gives you	Why it goes here
2	The statement of the law and the measurement of the mirror org↔code	You can't use Conway until you state it precisely and measure it, not just cite it
3	Why the monolith reflects the single team that birthed it	It's the most common case of Conway in real life, and explains where Mercado's pain comes from
4	The coordination cost: n(n-1)/2, executed	It's the economic reason Conway operates and small teams win
5	The friction of the module that crosses two teams, measured	It's the diagnosis: exactly where Conway charges its tax in Mercado
6	The inverse Conway maneuver	It's the cure: change the organization to obtain the architecture you want
7	The team topologies (the 4 types, the 3 modes)	It's the vocabulary to design the organization on purpose, not by accident

The arc is: first you learn to see and measure the law (2), then you understand where the typical monolith comes from (3) and why coordination costs so much (4), then you diagnose the concrete friction (5), and at the end you apply the two cure tools: the inverse maneuver (6) and the topology vocabulary to design the organization on purpose (7). Lesson 8 —the project— puts it all together over a new Mercado capability we haven't seen, so you confirm you learned the method and didn't memorize the case.

What this module does NOT touch

It's worth marking the frontier from now, because there are neighboring topics that seem to belong here and belong elsewhere.

What an architect does in general was module 1. There we saw the role —facilitator, not dictator; the one who makes expensive decisions reversible—. This module concentrates on a single dimension of that role: the dynamic between the organization and the architecture. When here we say "the architect restructures the teams", we take for granted why the architect has that responsibility (that was M1) and focus on how the team structure shapes the system.

Communicating architecture with diagrams is module 3. In this module we'll draw organizations and dependencies with simple diagrams and executed tables, but how an architecture is communicated to different audiences —the C4 model (Context/Container/Component/Code), the diagram for the VP against the diagram for the dev— is module 3. Here the diagrams are to understand the org↔system dynamic, not to communicate it to a stakeholder; that's another skill and it comes later.

The detailed restructuring of people (management) is out of scope. We'll talk about moving teams, creating a new squad, changing who owns what. But how that change is executed with the people —the 1:1s, the performance reviews, the politics of who gets told the news and how— is people management, and it's not this guide's. Here we work the org↔architecture dynamic: what form of organization produces what form of system, and how to choose the form you want. The human how of getting there is a sibling craft that leans on this one, but we don't cover it.

Common mistakes

Believing Conway is a funny anecdote and not a law (of underestimation). What happens: someone hears "you ship your org chart", laughs, repeats it in a talk, and keeps designing as if the organization didn't exist —draws the ideal architecture and delivers it expecting it to happen—. Why it happens: Conway sounds like an office joke, not a physical constraint, so it's treated as color and not as engineering. How to spot it: if your architecture plan doesn't mention even once how the teams are organized, you're ignoring half the problem. How to fix it: it's the whole module —start treating the org chart as the first architecture decision, not as an external fact—.

Fighting the org chart instead of using it (of stubbornness). What happens: the architect sees the organization is going to produce an architecture they don't like, and instead of changing the organization, they insist on the diagram and get frustrated when the system comes out with the shape of the teams and not the diagram's. Why it happens: changing a diagram feels within reach; changing teams feels outside their authority. How to spot it: if you catch yourself repeating "but the design says these services are independent" while the system clearly isn't, you're fighting Conway. How to fix it: the inverse maneuver (lesson 6) —if you want independent services, form independent teams; Conway's force stops being your enemy and becomes your tool—.

Confusing the diagram with the real architecture (of illusion). What happens: the team has a beautiful diagram of separate boxes and swears "that's how the system is designed", when in practice everything touches everything because the teams share and step on each other. The diagram describes the organization they wish they had, not the one they produce. Why it happens: the diagram is aspirational and no one confronts it against the real communication structure. How to spot it: compare the diagram with who-really-talks-to-whom; if they don't match, the diagram lies and the system will have the shape of the communication, not the drawing's. How to fix it: measure the mirror (lesson 2) —the real architecture is the one the organization can sustain, not the one the diagram promises—.

Exercises

Exercise 1 — Predict the seam. A company has a frontend team in one city and a backend team in another, in different time zones, coordinating by tickets. Without knowing anything technical about the product, where does Conway's Law predict the most fragile point of the system will be, and why? What form of architecture is it almost inevitable they'll produce?

See solution

The fragile seam will fall exactly at the contract between the frontend and the backend —the API that connects them—, because that's where two organizations that communicate poorly meet (different time zones, coordination by tickets, zero fluid conversation). It's the center of the bridge between the two crews.

The almost inevitable architecture: a frontend and a backend strongly separated by an API that becomes a battlefield —changes one asks for and the other takes weeks to deliver, misunderstandings about the data format, features that get stuck because they require coordinating both sides and the coordination is expensive—. They won't produce, for example, vertical end-to-end features (a team that does its little bit of frontend and backend), because for that both sides would have to be in the same team. The organization (frontend / backend) imposes the architecture (layers separated by a tense API). If what were wanted were independent end-to-end features, you'd have to reorganize into vertical teams —which is, exactly, the inverse maneuver of lesson 6—.

Exercise 2 — The diagram that lies. A startup's architect presents a diagram of three "totally independent" microservices. You investigate and discover the three are maintained by the same four people, who sit together, share a database, and deploy everything at the same time. What will that organization produce, no matter what the diagram says? Why is the diagram aspirational and not descriptive?

See solution

That organization —four people together, shared database, joint deployment— will produce a monolith, even though the diagram says "microservices". By Conway, the communication structure (one group that communicates constantly and shares everything) is copied into the system's structure (one coupled thing). Three "services" that share a database and deploy together aren't independent: they're a monolith split into three folders. As soon as one needs to change the database schema, the other two find out and there's coordination needed —that is, they're coupled, which is exactly what a microservice shouldn't be—.

The diagram is aspirational: it describes the architecture the architect would like to have, not the one their organization can sustain. For those three services to be truly independent, you'd need three teams that can work and deploy without coordinating —and with four people together that doesn't exist—. The lesson: the diagram describes an intention; the organization describes the reality. When they clash, the organization wins. Before drawing microservices, ask whether the organization has the communication structure microservices need; if not, either you change the organization, or the diagram is fiction.

Exercise 3 — Lever or drawing? An architect wants Mercado's checkout to stop being a bottleneck between orders and payments. They propose two paths: (a) redesign the checkout module in the code to better separate the order part from the payment part; (b) reorganize the teams so a single team owns the entire checkout flow. According to Conway's Law, which of the two is more likely to work durably, and why does the other tend to revert?

See solution

The more durable one is (b), reorganize the teams. According to Conway, the shape of the code tends to converge to the shape of the communication. If two teams (orders and payments) keep sharing checkout, any separation you make in the code (a) will erode over time: since the two teams still have to coordinate over that area, they'll reintroduce cross dependencies, "temporary" shortcuts, and in a few months the module will be as tangled as before. The communication structure didn't change, so the code structure returns to reflecting it.

By contrast, if a single team owns the entire checkout flow (b), the communication about checkout becomes internal to that team —cheap, constant, with no boundaries to cross—, and the code naturally organizes around that single owner. The separation holds because the organization backs it. This doesn't mean (a) is useless: redesigning the code helps. But redesigning the code without redesigning the teams is fighting the current —over and over, forever—. The module's rule: reorganizing the code without reorganizing the teams reverts; reorganizing the teams makes the code reorganize itself. That is, exactly, the inverse Conway maneuver of lesson 6.

Summary and next step

In this lesson you met the thesis that holds up the module: you ship your org chart —the system's structure copies the communication structure of the organization that builds it—. With the two-crew bridge you saw that the fragile seam falls where the organization was divided, not where the design put it. You met Mercado and its five squads, and its concrete pain: a monolith born from a single team and today fought over by five, with checkout as the point of greatest friction between orders and payments. And with the executed teaser you saw the law in its purest form: given how the squads communicate, you predict where the system's seams will fall —the communication org chart and the module map are the same drawing—.

Before moving on you should be able to: state Conway's Law in your own words and explain why a system's seam falls where the organization is divided; recognize an aspirational diagram (the one that promises an architecture the organization can't sustain); and distinguish the real lever (reorganizing teams) from the drawing (redesigning the diagram and expecting it to happen).

What follows is stating the law precisely and —what makes it a tool and not a phrase— measuring it. In lesson 2 you'll meet Melvin Conway's original formulation (1968), you'll understand why it operates (the design inherits the shape of the communication, not by magic but by mechanics), and you'll build the measurement of the mirror over Mercado: take the map of who owns which module and what each module depends on, classify each dependency as intra-team (cheap) or cross-team (expensive), and compute how aligned the organization and the code are. It's the step from "I sense the system resembles the organization" to "I know exactly how much, and where it doesn't resemble is the friction".

Resources

• Melvin Conway — "How Do Committees Invent?" (1968) — the original paper where the law is born, written by Conway himself and available free on his site. Short and surprisingly readable; the exact phrase is "organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations". The source of the whole module.
• Skelton & Pais — Team Topologies — the book that turned Conway into a discipline of organizational design; it introduces the inverse maneuver and the four team types we'll see in lessons 6 and 7. The site has a free summary of the concepts.
• Martin Fowler — "Conway's Law" — Fowler's essay that explains the law and the inverse maneuver in two clear pages, with the classic example of the two-pass compiler written by two teams. The best starting point in English to understand why the law matters.