What is Conway's law?
Engineering culture and software practice
Conway's law states that any organisation which designs a system produces a design whose structure copies the organisation's own communication structure. The computer scientist Melvin Conway set it out in 1968; Fred Brooks named it in 1975. In plain terms, software ends up shaped like the teams that built it. The inverse Conway manoeuvre turns the observation into a lever: shape the teams first to get the architecture you want.
What this means
Conway's law is an observation about the link between how people are organised and what they build. When a group sets out to design something, the parts of the finished thing tend to line up with the parts of the group, and the joins between those parts tend to line up with the places where people had to talk to each other. If two teams rarely speak, the two pieces of software they own will have a clumsy join. If one team owns a whole capability, that capability tends to be coherent.
The reason it has a name is that the pattern is quiet and persistent. Nobody decides that the company's software should have three separate login screens; it happens because three separate groups each built their own. The law names a force that operates whether or not anyone intends it, which is exactly why it is worth knowing about.
The useful twist is that the force can be steered. If a leader knows that structure follows communication, they can arrange teams and ownership deliberately so that the architecture they want becomes the path of least resistance. That deliberate use is what people mean by the inverse Conway manoeuvre.
Why it matters
For any organisation that buys, builds or depends on software, Conway's law explains a great deal of otherwise baffling friction. A reorganisation that looks purely administrative on the org chart will, months later, show up as new seams in the product. A decision to split work across two suppliers will show up as a brittle handover between two systems. The shape of who owns what is not a neutral background detail; it is a design decision in disguise.
It matters for the monolith-versus-microservices question that vendors love to raise. Splitting one big system into many small services only works if the teams are also split so that each owns a service end to end. Keep one shared team editing everything and the "services" will stay tangled, because the communication structure has not changed. The architecture keeps drifting back to the shape of the org chart.
It matters for suppliers and contracts. The boundaries you draw in a statement of work become the boundaries in the delivered system. If a contract splits the front end from the data, expect a join there, with all the coordination cost that implies.
It matters for AI adoption too. The shape of who owns an AI workflow, who owns the data it touches, and who signs off its output will show up in what actually gets built. If responsibility for an AI assistant is scattered across three departments that rarely meet, the result will feel scattered to the people using it.
How it works
Where the term came from
Melvin Conway submitted a paper called "How Do Committees Invent?" to the Harvard Business Review in 1967. It was rejected on the grounds that he had not proved his thesis, and the IT magazine Datamation published it in April 1968. Conway's central sentence was that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Fred Brooks quoted the idea in The Mythical Man-Month (Addison-Wesley, 1975) and gave it the name Conway's law, and the name stuck. There is a minor historical wrinkle worth stating honestly: a contemporary, George Mealy, proposed a similar naming in a 1968 symposium paper, so Conway did not name the law after himself.
For a long time this was folklore backed by intuition rather than evidence. That changed with empirical work. MacCormack, Baldwin and Rusnak tested what they called the mirroring hypothesis, first in a Harvard Business School working paper in 2008 and then in the journal Research Policy in 2012. Comparing products that did the same job but were built by very differently organised groups, they reported: "We find strong evidence to support the mirroring hypothesis," finding that the product developed by the loosely-coupled organisation was significantly more modular than the product from the tightly-coupled organisation. Separately, Cataldo, Herbsleb and Carley studied what they called socio-technical congruence and reported in their 2008 ESEM paper that when developers' coordination patterns were congruent with their coordination needs, the resolution time of modification requests was, on average, reduced by 32 percent.
The mechanism: communication is the hidden blueprint
The engine underneath the law is ordinary human communication cost. People inside a team share context, sit in the same meetings and can settle a design question in a corridor. People in different teams have to schedule, explain and negotiate. Because the cheap conversations happen inside teams and the expensive ones happen across them, the clean, well-considered parts of a system form inside team boundaries and the awkward compromises form at the boundaries between teams. The system, in effect, is a frozen record of who found it easy to talk to whom.
How it shows up in real work
It shows up as products with visible seams: two modules that duplicate each other because two teams built them in parallel, or a report that has to be stitched together by hand because no single team owns the whole flow. It shows up in org charts, where a new reporting line quietly predicts a new interface in the code. It shows up in supplier contracts, where the division of labour becomes the division of the software. And it shows up in data, where ownership boundaries become barriers to sharing.
How experienced teams handle it: the inverse Conway manoeuvre
The deliberate response was named by Jonny LeRoy and Matt Simons of ThoughtWorks around 2010, popularised through ThoughtWorks's technology writing, and carried to a management audience by Matthew Skelton and Manuel Pais in Team Topologies (2019). The idea is to decide the architecture you want, then arrange teams so their natural communication produces it. In practice that demands a few unglamorous things: stable teams that persist long enough to own something, clear ownership of each capability, and interfaces in the software that match the boundaries between teams. It is not a magic move. It requires the will to change reporting lines, not just diagrams.
Examples
A mid-sized professional services firm engages three different IT suppliers over five years, one for the client portal, one for billing and one for case management. Nobody ever decides that staff should log in three times, yet that is what happens, because each supplier built its own front door. The three login screens are Conway's law made visible: the seams in the software sit exactly where the boundaries between suppliers sat.
A charity has a fundraising team and a services team that report to different directors and rarely meet. Each commissions its own database. Two years on, nobody can answer a simple question about whether donors also use the charity's services, because the two systems were never designed to speak, mirroring the fact that the two teams never did either. A leader who understood the law would have put one cross-functional group in charge of the supporter journey before any software was chosen.
A retailer with a software team of eight decides to reorganise from two skill-based teams (one front end, one back end) into two capability teams (one owning checkout, one owning search). Within about six months, the codebase grows a clean new boundary between checkout and search and the old front-end-to-back-end handover fades. The teams reshaped the software without touching a line of architecture documentation, simply by changing who talked to whom.
Common misunderstandings
Some people treat Conway's law as a criticism of a particular company, as if messy software were a sign of uniquely bad management. It is not. It is a structural tendency that applies everywhere, including to well-run organisations. The point is not to feel guilty but to notice the force and use it.
A second misunderstanding is that the law is an iron law of nature that always holds exactly. The honest position is that it is a strong tendency with real empirical support, not a guarantee. Small, closely knit organisations where everyone talks to everyone may show it only weakly, and a determined team can cut across its own boundaries when it has to.
A third confusion is with Brooks' law. Conway's law and Brooks' law both trace to Fred Brooks's book, but they are different claims. Brooks' law is about staffing and schedules, warning that adding people to a late software project makes it later. Conway's law is not about schedules at all; rather than a claim about headcount and delivery dates, it is a claim about how team structure shapes system structure. Do not treat one as a version of the other.
A fourth error is believing the inverse Conway manoeuvre is just redrawing boxes on an org chart. Renaming teams without changing who actually communicates changes nothing, because the law follows real communication, not titles.
Finally, some assume the law only concerns software. Conway himself defined systems broadly, and the pattern applies to processes, documents and organisations as much as to code.
Risks and boundaries
The law is often overstated. Because the memorable version sounds absolute, people invoke it to explain every problem, when sometimes a system is simply badly built for ordinary reasons unrelated to team structure. Treating it as destiny can also become an excuse to avoid fixing code: blaming the org chart is easier than doing the work.
The evidence supports a tendency, not an identity. MacCormack and colleagues found strong support in a particular natural experiment comparing commercial and open-source products; that is meaningful, but it is not a universal proof that every product mirrors its makers perfectly. There is live debate about how far the mirroring holds when organisations deliberately design against it, and about whether tightly coordinated modern tooling weakens the effect.
The inverse manoeuvre has its own boundary. Reorganising teams is disruptive and slow, and a business should not restructure its people purely to chase an architectural diagram. The manoeuvre is a tool for large, deliberate changes, not a reason to reshuffle staff every quarter.
What to do next
Before any significant build, buy or reorganisation, ask what shape you want the result to have, and then check whether your team and supplier boundaries match that shape. If you want one seamless customer experience, put one accountable group in charge of it end to end rather than splitting it across departments that rarely meet.
When you split work across suppliers or draw contract boundaries, treat those lines as future joins in the system. Draw them where you can tolerate a seam, and keep the interfaces between them explicit and few.
Give teams enough stability and clear enough ownership to be responsible for a whole capability. Frequent reshuffling prevents any team from owning anything long enough for a coherent design to form.
For AI work, decide early who owns each workflow, its data and its sign-off. Scattered ownership produces a scattered result; a single accountable owner tends to produce something coherent.
Use reorganisation as a deliberate architectural tool only for large, considered changes, and expect the software to take months to grow into its new shape rather than changing overnight.
FAQs
Who first stated Conway's law and when?
Melvin Conway set out the idea in his 1968 Datamation paper "How Do Committees Invent?". Fred Brooks named it Conway's law when he cited it in The Mythical Man-Month in 1975.
Is there evidence that it is actually true?
Yes, up to a point. MacCormack, Baldwin and Rusnak reported strong support for the mirroring hypothesis in Research Policy in 2012, and related work on socio-technical congruence found measurable coordination benefits. It is best treated as a strong tendency rather than a certainty.
What is the inverse Conway manoeuvre?
It is the deliberate practice of choosing the architecture you want and then arranging teams so their communication naturally produces it. It was named by ThoughtWorks consultants around 2010 and popularised by the book Team Topologies.
How is Conway's law different from Brooks' law?
Brooks' law is about schedules and staffing, warning that adding people to a late project makes it later. Conway's law is about how team structure shapes system structure. They come from the same author but make different claims.
Why does my company's software have several separate login screens?
Usually because several teams or suppliers each built their own part with its own front door. The seams in the software mirror the boundaries between the groups that built it, which is Conway's law in action.
Does the law apply to AI projects?
Yes. The way ownership of an AI workflow, its data and its sign-off is distributed across the organisation tends to show up in how coherent or fragmented the finished workflow feels.
Can I avoid Conway's law entirely?
Not really, but you can work with it. Rather than fighting the tendency, arrange your teams and ownership so that the design you want is the one the structure naturally produces.