Conway's Law: Your System Copies Your Org Chart, and Your Client's

Here is a hypothetical example. Two teams build one product. One owns orders, the other owns invoices, and their managers meet every Tuesday to agree what passes between them. Now look at the interface between their two services. Changes travel in one scheduled batch instead of as they happen. The fields were fixed in advance, like an agenda. And there is a free-text field called notes that carries whatever did not fit: the any-other-business item, now in the API.

Nobody designed it that way. The interface is a copy of the meeting. Melvin Conway explained why in 1968, and his explanation matters as much to the people who sign contracts as to the people who draw diagrams.

What Conway wrote in 1968

Conway's paper, "How Do Committees Invent?", appeared in Datamation in April 1968. Its thesis is that organisations which design systems are "constrained to produce designs which are copies of the communication structures of these organizations" (Conway, 1968). Harvard Business Review had turned the paper down first because, as Conway recalls on his site, he had not proved his thesis. Fred Brooks later called it Conway's law in The Mythical Man-Month, and the name stuck.

The argument is short. If two parts of a system talk to each other, the groups that built them must have agreed on an interface. Where two groups never talk, their parts do not connect. Draw the organisation and the system as graphs and you get much the same shape twice.

Why the org chart in particular? Conway's answer was arithmetic. The number of possible communication paths in an organisation is roughly half the square of its headcount, so even a modest organisation has to restrict who talks to whom. Where those limits follow the lines of command, he wrote, "the communication structure of an organization will resemble its administrative structure." The org chart becomes the design.

His examples are hard to forget. A contract research organisation had eight people to write a COBOL compiler and an ALGOL compiler. Five went to COBOL and three to ALGOL. The COBOL compiler ran in five phases, and the ALGOL compiler in three. In another case, two military services were told to develop a common weapon system: "After great effort they produced a copy of their organization chart."

Your client's org chart is part of the requirements

The same law runs through every integration with a large client, and it is the part easiest to leave out of a quote. A ministry, a bank or a hospital group is not one customer. It is several departments, and each has its own system, its own data and its own approvals. Say finance holds the customer record one way, operations another, and IT owns the gateway both of them sit behind. Integrating with that client means integrating with each department in turn.

So the integration takes the client's shape: one adapter per department, one data mapping per definition of "customer", one approval path per owner, each moving at the pace of its own meeting calendar. The schedule follows the slowest approval, and the architecture follows the org chart, whether or not anyone drew it that way. Having worked on government-scale systems from pre-sale to handoff, I would put it simply: the client's organisation chart belongs in the requirements.

The technical defence is to keep that shape at the edge of your system. Eric Evans's name for the pattern is an anticorruption layer: a translation layer that lets your system use another one "in terms of your own domain model" (Evans, 2015). He notes that translation turns defensive when "control or communication is not adequate" between the two sides, which is an organisational condition written into a design pattern. With one such layer per department, a reorganisation at the client changes an adapter, not your core model.

The commercial side follows. If the price is fixed before anyone has mapped the departments, someone has agreed to carry that uncertainty without pricing it, which is the question behind Fixed Price or Time and Materials: each contract type decides who carries it.

A reorganisation is an architecture decision

The law also runs inside your own company. Conway wrote that "the very act of organizing a design team means that certain design decisions have already been made" (Conway, 1968). Split a team in two and, sooner or later, expect two services with an interface between them. Merge two teams and the line between their services starts to blur. A reorganisation is announced as a people decision. It is also an architecture decision, and it is rarely reviewed as one.

Some organisations use this on purpose. ThoughtWorks listed the "Inverse Conway Maneuver" on its Technology Radar in July 2014; it "recommends evolving your team and organizational structure to promote your desired architecture." Matthew Skelton and Manuel Pais built a whole method around team design in Team Topologies (2019), with four fundamental team types and three ways for teams to interact.

Individuals count too. When one person is the only channel between two teams, the interface lives in that person's head, and the system inherits the bus factor of one that comes with routing everything through a single person.

Questions to ask before you draw the boxes

Before a design review, read the organisation and the system side by side. This table is the checklist I would start from.

Source: my own checklist, built on Conway (1968); not a measured study.

Run the questions twice: once on your own organisation and once on the client's. The first tells you where your system will bend. The second tells you where your project will wait.

The org chart is the first draft of the architecture. Most teams review every diagram except that one.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.