An organizational development team restructures a company's engineering division for what look like purely people-oriented reasons — clearer reporting lines, better career pathing, more balanced team sizes. Eighteen months later, the company's software architecture has reorganized itself along strikingly similar lines to the new org chart, with clean interfaces appearing at exactly the boundaries between the newly restructured teams. This isn't a coincidence — it's a well-documented, decades-old observation known as Conway's Law, and it means org design decisions carry architectural consequences that most org development work doesn't explicitly account for.
What Conway's Law actually observes
Melvin Conway's original 1968 observation, borne out repeatedly in subsequent research and widely cited in software engineering, states that organizations which design systems are constrained to produce designs that mirror their own communication structure. Teams that need to coordinate closely to build a system tend to produce a system with correspondingly tight coupling between the parts they each own; teams that communicate less frequently or less easily tend to produce a system with more separated, more loosely coupled parts at exactly those organizational boundaries — not because anyone planned the system architecture that way deliberately, but because the communication patterns required to design a more integrated system simply didn't happen as readily across those particular team boundaries.
This makes a reorg an architecture decision, whether or not anyone frames it that way
An org development initiative undertaken purely to solve people problems — unclear ownership, uneven workload, unclear career progression — still changes who talks to whom regularly and how easily, and that changed communication pattern will shape whatever systems the organization goes on to build or evolve afterward. Treating a reorg as a purely human-resources decision, disconnected from any consideration of the systems the organization produces, misses a real and predictable consequence of the change — one that often surfaces months later as unexpected friction in exactly the places the new org boundaries were drawn.
Where this becomes a real, practical problem
A common and specific failure mode: an organization reorganizes teams around a desired new system architecture that hasn't been built yet, expecting the org chart to lead the technical change. Conway's Law suggests the more common actual outcome runs in the other direction — the existing communication patterns and expertise, only partially reshaped by the new reporting lines, continue producing a system that resembles the old structure more than the new one, because deep architectural change requires the communication patterns to genuinely shift, not just the reporting lines on a chart.
The inverse Conway maneuver — using this relationship deliberately
Rather than treating Conway's Law as an unavoidable constraint discovered after the fact, some organizations deliberately design team structure around the system architecture they actually want to end up with — a practice sometimes called the inverse Conway maneuver. If the goal is a system with clean, well-separated services, structuring teams to genuinely mirror those intended service boundaries — including the communication patterns, not just the org chart lines — gives the desired architecture a much better chance of actually emerging, because the teams' natural, everyday communication patterns will reinforce it rather than working against it.
What this means for how org development work gets planned
- Consider the likely architectural consequences of any significant reorg explicitly, not as an afterthought once technical friction shows up later
- Recognize that a reorg intended to reshape a system's architecture needs to genuinely change communication patterns, not just reporting lines, to have the intended effect
- Use the inverse Conway maneuver deliberately when a specific target system architecture is known in advance — design the team structure to match it directly
- Treat unexpected friction at specific system boundaries, appearing some time after a reorg, as a plausible Conway's Law effect worth investigating, not just a technical problem in isolation
Org development and system architecture are more entangled than most organizational charts acknowledge — treating them as fully separate concerns means a purely people-focused reorg will still reshape the systems built afterward, just without anyone having planned for how.