the original statement
mel conway, 1968: "any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." it sounds like a piece of soft-org wisdom. it isn't. it's a physical constraint that has held up for fifty-seven years across every kind of software org.
teams that talk produce code that talks. teams that don't produce interfaces. the shape of the conversation is the shape of the architecture — and if you don't design for that, you'll get it anyway, probably in a shape you didn't choose.
forward: the default
the forward law is passive. you hire people, you put them into teams, those teams produce software. the software's module boundaries, release cycles, and apis will look like your team structure — give or take a quarter of refactoring — for as long as that team structure exists. you didn't decide the architecture; the org chart did.
most orgs live the forward law. it's why a reorg always produces an architectural rewrite six months later: the old structure's architecture becomes a prison for the new structure. no amount of engineering hygiene prevents this; it's emergent.
reverse: the manoeuvre
the reverse conway manoeuvre is what team topologies names the active use: design the team structure to get the architecture you want. you want three loosely-coupled services? start with three teams that don't need to sync every week. you want a shared platform? create a platform team before the first consumer ships. the teams come first, and the architecture follows because it has to.
try it
five conway decisions
each scenario is a real org dilemma. which move is truest to conway's law — forward or reverse?
a working test
when you're staring at a proposed org change (hiring plan, reorg, acquisition integration, team split), ask two questions:
- what architecture will this produce by default? draw the team graph. every team is a node, every regular meeting or dependency is an edge. that graph is the architecture you're about to ship, whether you meant to or not.
- is that the architecture we want? if yes, proceed. if no, change the team graph before the work starts — not the code after. this is the whole reverse conway move.
next: lesson 5 applies the four types, three modes, and Conway's law to a real fictional org. interactive topology on an actual problem.