Conway: You Ship Your Org Chart
Why Melvin Conway’s fifty-seven-year-old observation means your AI transformation will produce exactly the system your current team structure is capable of producing, and nothing else.
In 1967, a computer scientist named Melvin Conway submitted a paper called “How Do Committees Invent?” to the Harvard Business Review. They rejected it on the grounds that he had not proved his thesis. He sent it to Datamation instead, which published it in 1968. Fred Brooks cited it in The Mythical Man-Month and called the central idea “Conway’s Law.” The name stuck. The idea is simple, empirically validated, and almost universally ignored in practice. It is probably the best known ‘law’ in the technology architecture profession.
The big idea: any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.
If three teams build a compiler, you get a three-pass compiler. If four departments own the customer journey, the customer experiences four handoffs. If your AI platform team sits in a different reporting line from the teams that are supposed to use it, the platform will be designed around what the platform team finds interesting, not around what the users need. This is not a management failure. It is a structural inevitability. Conway showed that the very act of organising a design team means that certain design decisions have already been made, explicitly or otherwise. The class of designs available to you is constrained by the communication paths that exist. Designs that require communication across paths that do not exist cannot emerge.
1. The Homomorphism: Why This Is Not a Metaphor
Conway’s original paper described the relationship between organisational structure and system structure as a homomorphism: a structure-preserving mapping. This is precise language from mathematics, not a loose analogy. The communication graph of the organisation maps onto the module graph of the system. Where teams must coordinate, system components will have interfaces. Where teams do not communicate, system components will not integrate. Where communication is expensive (across time zones, across reporting lines, across organisational boundaries), interfaces will be thick, formal, and slow. Where communication is cheap (within a team, across a shared desk, in the same Slack channel), interfaces will be thin, informal, and fast.
The practical consequence is that you cannot design a system architecture without simultaneously designing (or inheriting) an organisational architecture. And the reverse is equally true: every organisational restructuring is an architectural decision, whether anyone treats it as one or not.
This is where Conway meets the rest of the series. Simon argued that organisations are nearly decomposable systems: tightly coupled within modules, loosely coupled between them. Conway shows where the module boundaries come from. They come from the communication boundaries in the organisation. Evans argued that bounded contexts, the boundaries within which a domain model is consistent, are the critical architectural decision. Conway shows that those boundaries will mirror team boundaries unless you deliberately design otherwise. Beer’s Viable System Model requires each operational unit to be autonomous, with coordination mechanisms (System 2) preventing autonomous units from shaking the system apart. Conway shows the mechanism by which this happens: the interfaces between teams become the interfaces between system components. If coordination is absent, integration is absent. If coordination is overbearing, coupling is tight and autonomy is crushed.
2. The Design Decision You Already Made
Conway’s most underappreciated insight is not the law itself but what follows from it. The initial stages of any design effort, he observed, are concerned more with structuring the design activity than with the system itself. The very act of assigning teams to tasks determines which designs are possible and which are not. You have made your most consequential architectural decisions before anyone writes a line of code or draws a system diagram.
Consider a common pattern. An enterprise creates an “AI Platform Team” and several “Business Unit AI Teams.” The platform team reports to the CTO. The business unit teams report to their respective business leads. The communication path between them runs through two separate reporting lines that converge, if they converge at all, at an executive committee. Conway’s Law predicts the outcome with mechanical precision: the platform team will build a platform that reflects its own priorities, the business teams will build solutions that reflect theirs, and the interface between them will be exactly as clumsy as the communication path that connects them. No amount of governance, no number of steering committees, no weekly alignment meetings will override the structural reality. The communication structure is the design.
Bourdieu would recognise what is happening. The habitus of the platform team, the embodied dispositions, technical preferences, and professional identities formed through years of infrastructure work, generates a particular kind of system. The habitus of the business team generates another. These are not failures of communication. They are the structural reproduction of professional identity through system design. The org chart is not just a reporting structure. It is a description of which designs can exist.
3. The Reverse Conway Manoeuvre: Designing Your Way Out
If the law is a constraint, it is also a tool. The reverse Conway manoeuvre, popularised by Skelton and Pais in Team Topologies, says: define the architecture you want, then design the team structure that will produce it. Do not accept the architecture your current structure generates. Redesign the structure to generate the architecture you need.
This sounds simple. It is extraordinarily difficult, because it requires treating team design as architecture work and reorganisation as refactoring. Most organisations treat team structure as an HR concern and system architecture as an engineering concern. Conway’s Law says they are the same concern. Every team boundary is a system boundary. Every reporting line is a coupling decision. Every matrix structure is an integration pattern. If you would not accept accidental coupling in your code, you should not accept accidental coupling in your organisation.
Boyd’s destruction and creation applies here directly. To adopt the reverse Conway manoeuvre, you must first destroy the assumption that organisational design and technical design are separate disciplines. The mental model that keeps them apart, one the province of “the business,” the other the province of “technology,” is precisely the kind of closed orientation that Boyd showed leads to strategic failure. The organisation that treats reorganisation as an HR initiative and architecture as an engineering initiative has ensured that neither can succeed, because each is constrained by the other.
4. Cognitive Load: The Hidden Constraint
Skelton and Pais extend Conway with a concept that every engineer has experienced and few organisations measure: cognitive load. Every team has a finite capacity for the complexity it can handle. When a team is responsible for too many things, for too many services, too many integrations, too many domains, everything degrades. Not because the people are incompetent, but because the human capacity for holding complexity in working memory is bounded. Simon would call this a consequence of bounded rationality applied to team design. The team satisfices, not because it lacks ambition, but because its cognitive budget is exhausted.
The implication for AI is direct. Adding AI capabilities to a team that is already at cognitive capacity does not produce AI adoption. It produces overload. The team will either ignore the new capability, implement it superficially, or burn out trying to absorb it alongside everything else. Taleb would recognise this as fragility: the system is already at its stress limit, and the additional load becomes the stressor that breaks it. Via negativa applies: instead of adding AI to an overloaded team, remove something from the team’s scope to create the cognitive space for AI to be learned and used.
5. What AI Changes About Conway’s Law
Conway’s Law assumes that systems are designed by humans communicating with other humans. AI changes the communication structure. An engineer working with an AI coding assistant has, in effect, a new team member whose communication bandwidth is unlimited but whose understanding of organisational context is zero. The AI does not know which team owns which service. It does not know the unwritten rules about which databases are off-limits. It does not know the political history that explains why the billing system was never integrated with the customer system. It will happily generate code that crosses every organisational boundary the human developer has spent years learning to respect.
This means AI can either reinforce Conway’s Law or disrupt it. If AI tools are deployed within existing team boundaries, they will accelerate the production of the architecture those boundaries generate: faster delivery of the same structural pattern. If AI tools are deployed in ways that enable communication across boundaries that previously did not exist, such as generating integration code between systems owned by different teams, or producing documentation that makes one team’s domain model accessible to another, they can create new communication paths and therefore new design possibilities.
But here is the catch. Those new communication paths are virtual. They exist in the code the AI generates, not in the organisational relationships between the people who must maintain that code. Conway’s Law does not say systems mirror how people should communicate. It says systems mirror how people do communicate. AI-generated integrations that cross team boundaries without corresponding human relationships will become the seams where the system fails: the code nobody owns, the interface nobody maintains, the integration that works until it does not and no one knows how to fix it.
Ackoff would diagnose this as doing the wrong thing righter. Using AI to generate cross-boundary integrations without redesigning the team structure is solving a coordination problem with technology when the actual problem is organisational. The mess persists because the interactions between teams have not been addressed; you have merely papered over them with generated code.
6. The Org Chart as Architecture Document
The practical implication is uncomfortable but unavoidable: your org chart is your most important architecture document. Not your system diagram. Not your domain model. Not your API catalogue. Your org chart. Because your org chart determines which communication paths exist, which determines which designs are possible, which determines which systems get built.
If you want a different system, you need a different org chart. Not a different strategy document. Not a different governance framework. A different communication structure that makes the design you want structurally possible.
Beer’s POSIWID applies with full force: the purpose of your organisational structure is what it produces. If it produces siloed AI implementations that do not integrate, that is its purpose. If it produces a platform nobody uses, that is its purpose. If it produces an architecture that mirrors five reporting lines and three geographies, that is its purpose. You can write any strategy you like. Conway’s Law says you will ship your org chart.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Draw your AI architecture from your org chart, not your design documents.
Take the teams involved in your AI transformation. Draw their actual communication paths: who talks to whom, how often, through what channels, across what reporting lines. Now draw your target AI architecture. Overlay them. Where the architecture requires integration between components whose owning teams have no regular communication path, mark those interfaces in red. Those are the interfaces that will fail, not because of technology, but because of Conway’s Law. For each red interface, you have a choice: redesign the team structure to create the communication path, or redesign the architecture to respect the team structure. What you cannot do is leave both unchanged and expect the system to work.
Further Reading
Melvin Conway: How Do Committees Invent? - The original paper. Forty-five paragraphs, with the thesis in the third-last one. Conway himself notes this with amusement. Read it for the homomorphism argument and the observation that organising the design team is itself a design decision. Freely available on Conway’s website.
Matthew Skelton and Manuel Pais: Team Topologies: Organizing Business and Technology Teams for Fast Flow - The practical application of Conway’s Law to modern software delivery. The four team types, the three interaction modes, cognitive load as the primary constraint, and the reverse Conway manoeuvre. The most directly useful book for anyone reorganising teams around AI.
Fred Brooks: The Mythical Man-Month: Essays on Software Engineering - The book that named Conway’s Law. Brooks’s own contribution, that adding people to a late project makes it later, is itself a consequence of Conway’s observation: more people means more communication paths, which means more complex system structure.
Ruth Malan and Dana Bredemeyer: Conway’s Law - A rigorous analysis of the implications for enterprise architecture. The argument that architecture and organisational design must be treated as a single discipline.
Disclaimer
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.