Pattern/Computing and Information/No. 0212
Conway’s Law
Conway’s law is the tendency for systems to reflect the communication structure of the organizations that design them. Described by Melvin Conway in 1968 and popularized by Fred Brooks, it links team boundaries with software architecture, a pattern studied as the mirroring hypothesis.
- Evidence
- Well established
- Read
- 6 min
- Links
- 6 connections
- Useful when
- Designing products · Organizations and bureaucracy · Running projects
01You've seen this when…
- in life
You change your mailing address in your bank’s app. A month later, your credit-card statement still goes to the old address; that division keeps its own customer record.
- at work
The checkout team and the fulfillment team plan their releases separately. Customers can buy a new delivery option before the warehouse software knows how to handle it.
- out in the world
A city launches a single permit website. Applicants still enter the same property details separately for planning, fire safety, and environmental review.
02The idea
A product can look unified in a presentation and feel divided in use. Separate accounts, repeated questions, awkward handoffs: these often follow boundaries between the people who designed it.
Conway’s law says that an organization’s communication structure tends to show up in the structure of the systems it creates. People who work closely together can make many small, interdependent decisions. People who rarely communicate need to rely on formal agreements and firmer boundaries so they can make fewer decisions together. Their systems often reflect that difference.
The organization chart is one part of the communication structure. Who reviews whose work and who can resolve a disagreement also matter. So do the teams that share planning sessions and the conversations that require a ticket or a contract. Two teams under one manager may barely communicate; teams in different departments may work together daily.
This isn’t automatically a defect. Independent teams can produce well-separated components. The trouble starts when the product requires coordination that its designers cannot sustain. The customer then has to bridge the gaps.
03Why it happens
- Design requires repeated agreement. Teams must agree on release timing and on how their components share data and handle errors. This involves hundreds of small decisions. Frequent communication makes those decisions easier; distant teams tend to reduce the number they must make together.
- Team boundaries make natural component boundaries. Assigning each group a separate piece makes ownership clearer. That encourages modularity, but the chosen pieces may fit the staffing plan better than the user’s task.
- Coordination has a cost. Meetings, approvals, time zones, and supplier negotiations create transaction costs. Designers often choose an interface that minimizes those costs, even when it makes the overall system less convenient.
- Existing boundaries become expensive to move. Once each team has its own code and database under a separate release process, changing the division means changing both technology and working relationships. This creates path dependence: yesterday’s arrangement shapes tomorrow’s options.
The influence can also run backward. A system with tightly connected components may force its teams to coordinate closely. Organization and architecture can reinforce each other.
04A worked example
Consider an invented meal-delivery company. One team builds ordering; another builds driver dispatch. Each has its own customer record and release schedule. They exchange order details through an interface agreed months ago.
The ordering team adds a feature that lets customers correct an address after paying. Dispatch receives the original address but has no mechanism for receiving the correction.
What it looks like An isolated missing feature. Support agents must call drivers whenever a customer changes an address.
What’s actually going on The technical boundary follows the organizational boundary. Each team can complete its own work without checking the full delivery journey. Their separate planning processes leave no dependable place to negotiate changes that affect both systems. The interface preserves the assumptions made when it was first agreed.
What would have helped Giving both teams responsibility for address changes from entry through delivery. A shared interface review and an integration test would support that responsibility. The teams need a reliable way to make the decisions their systems share, which they can build while remaining separate. Adding another field without changing that process would fix this incident while leaving the next mismatch waiting.
05How to spot it
06What to do about it
- Map conversations beside components. Draw the major parts of the system, then mark who designs each part and who must talk to whom. Look for necessary conversations that have no dependable channel.
- Organize around shared decisions. If two parts change together repeatedly, give their designers regular access to each other and someone who can settle trade-offs. Sometimes a cross-functional team helps; sometimes a standing review is enough.
- Support independent work. If teams should work separately, define clear responsibilities and invest in stable interfaces backed by compatibility tests. Loose coupling requires engineering work even when teams have separate reporting lines.
- Test complete journeys. Assign ownership for outcomes that cross components. A successful checkout can still lead to a failed delivery, and component-level dashboards may conceal that gap.
- Change structure deliberately. The approach sometimes called the inverse Conway maneuver starts with a desired architecture and arranges teams to support it. Treat this as a design hypothesis with uncertain results. Reorganization without interface changes, migration time, or clear authority can simply add disruption.
07When it isn’t an organizational fingerprint
Awkward interfaces can reflect communication failures or other constraints. Security requirements, regulation, performance limits, and inherited technology can all force boundaries. Separate records may be intentional. Start by finding the actual constraint to assess the organization chart’s role.
Nor should every boundary disappear. Separation of concerns can make a system easier to understand and maintain. The aim is to align communication with necessary coordination, not make everyone attend every meeting. Brooks’s law warns that more people can increase coordination demands rather than solve them.
Research supports mirroring as a recurring pattern that has exceptions. MacCormack and colleagues compared software products with similar functions but different development arrangements and found evidence linking organizational differences to differences in modularity. A broader review by Colfer and Baldwin found support alongside important exceptions.
Much of this evidence is observational. It does not establish that organizational structure always causes architecture, or that redrawing reporting lines will repair a system. Designers can deliberately depart from existing boundaries, especially when they invest in the communication that departure requires.
08Roots
Melvin Conway’s 1968 article in Datamation tackled a practical problem: an organization must divide design work before it fully knows what the finished system should look like. That early staffing decision can quietly become a technical decision.
He offered a memorable anonymous example. Eight people were assigned to build two compilers, programs that translate programming languages: five worked on COBOL and three on ALGOL. In his account, the resulting compilers used five passes and three passes respectively. The division of people reappeared in the way the programs processed their input. It was an anecdote, not a controlled test, but it made the pattern easy to see.
Fred Brooks helped spread the name Conway’s law through The Mythical Man-Month in 1975. Later researchers studied the broader relationship as the mirroring hypothesis. The idea traveled from a warning about design committees into software architecture and organizational design: deciding who talks to whom is part of deciding what can be built.
09How solid is this?
Comparative software studies and broader research reviews support a recurring association between organizational and technical boundaries. Much of the evidence is observational, with meaningful exceptions; it does not show that reorganization alone reliably changes architecture.
10Connections
- Countered byLoose Coupling
- See also Modularity, Transaction Costs, Path Dependence, Separation of Concerns, Brooks’s Law
11Origin and sources
Melvin E. Conway described the pattern in How Do Committees Invent? (Datamation, 1968). Fred Brooks popularized the name Conway’s law in The Mythical Man-Month (1975).
- [1]Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), 28–31.
- [2]Brooks, F. P., Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- [3]MacCormack, A., Rusnak, J., & Baldwin, C. Y. (2012). Exploring the duality between product and organizational architectures: A test of the "mirroring" hypothesis. Research Policy, 41(8), 1309–1324.
- [4]Colfer, L. J., & Baldwin, C. Y. (2016). The mirroring hypothesis: theory, evidence, and exceptions. Industrial and Corporate Change, 25(5), 709–738.
Suggest an edit· Updated 2026-10-02