Conway's law says an organization's software structure tends to mirror its communication structure. How does that principle interact with the choice of monorepo vs polyrepo, and what does it mean in practice for how you'd decide to split or merge repositories as an org's team structure changes?
answer
- Conway 1968: system design mirrors communication structure
- repo boundary = communication boundary
- inverse Conway maneuver: restructure teams to get the architecture you want
- monorepo without CODEOWNERS discipline = ownerless commons
- revisit repo topology when team topology changes
basics
~20 sConway's law says your code ends up organized like your teams are organized. Repo boundaries don't automatically fix bad team boundaries -- if teams don't talk or don't own things clearly, splitting or merging repos alone won't solve that; repo structure should follow real ownership lines, and should change when the team structure changes.
solid answer
~60 sConway's law observes that system design mirrors organizational communication structure, because interfaces between components tend to form along the same lines as interfaces between the teams that build them. Repository topology is a visible expression of this, not an independent lever: a polyrepo per team works well when team boundaries are stable and interfaces between them are genuinely arm's-length, because the repo boundary reinforces a communication boundary that already exists. A monorepo works well when the organization needs frequent, low-friction cross-team collaboration on shared code -- it removes a structural barrier that would otherwise force teams into slow, high-ceremony coordination. The trap is assuming the tool choice can substitute for organizational clarity: splitting a monorepo into per-team repos doesn't create real team autonomy if those teams still have tightly coupled runtime dependencies and have to coordinate every release anyway (the 'inverse Conway maneuver' argument), and keeping everything in one monorepo doesn't create collaboration if there's no CODEOWNERS/build-visibility discipline reinforcing who actually owns what. Repo structure should be revisited whenever team structure meaningfully changes, because a repo boundary that no longer matches real ownership becomes either an artificial barrier or a false sense of isolation.
go deeper
Should be able to restate Conway's law in plain terms: teams that don't talk much tend to produce code with a hard boundary between their parts, and vice versa.
Should connect this to repo choice at a basic level: repo-per-team fits stable, arm's-length teams; one shared repo fits teams that need to collaborate closely and often.
Should recognize that repo topology alone doesn't create or remove real coupling, and should be able to describe what has to accompany a monorepo (ownership/visibility discipline) or a polyrepo split (genuinely decoupled interfaces) to make the boundary meaningful rather than cosmetic.
Should be able to invoke the inverse Conway maneuver explicitly, reason about which direction of causality to lean on (team structure driving architecture vs. the reverse) for a given org, and give concrete guidance on when to revisit repo topology as team structure evolves, citing failure modes of drift between the two.
## The law and the mechanism behind it Conway's law, first stated by Melvin Conway in 1968, observes that organizations which design systems are constrained to produce designs that are copies of the communication structures of those organizations. The mechanism behind it is mundane but powerful: designing an interface between two pieces of software requires the people building each side to communicate -- agree on a contract, negotiate changes, coordinate releases. Communication is expensive across an organizational boundary (different managers, different priorities, different time zones, different channels) and cheap within one (same standup, same reviews, shared context). So, over time, software interfaces naturally end up cheap-to-change where the people are organizationally close and expensive-to-change (more formal, more stable, more API-like) where the people are organizationally distant -- not because anyone designed it that way on purpose, but because that's where the path of least communication resistance leads. ## Why repository topology is the visible artifact Repository topology is one of the most visible artifacts of this dynamic, because a repo boundary is itself a communication boundary. Different repos usually mean: - different CI pipelines - different release cadences - different code-review pools - often different access permissions All of which make cross-repo collaboration structurally more expensive than cross-directory collaboration in the same repo. This is why the monorepo-vs-polyrepo choice isn't purely a technical build/tooling decision -- it's implicitly a statement about where you want communication to be cheap versus where you're comfortable paying a coordination tax. - A **polyrepo-per-service** architecture matches an organization built around genuinely independent teams with stable, well-specified interfaces: the repo boundary reinforces a real organizational boundary that already exists, and the extra ceremony of versioned APIs and release coordination is a feature, not a bug, because it's exactly the discipline you want enforced between teams that shouldn't be casually coupling to each other's internals. - A **monorepo** matches an organization that needs frequent, low-latency collaboration across what might otherwise be team boundaries -- for instance, when a platform team's library changes need to land atomically with every consumer's adaptation, or when the org deliberately wants engineers to feel ownership of the whole system rather than just their team's slice. ## The law runs in both directions The trade-off, and the place this gets subtle at the principal level, is that Conway's law runs in both directions, and tooling choices alone don't override it. Simply splitting a monorepo into per-team repos does not, by itself, grant teams real autonomy if their services still have tight runtime coupling -- shared database schemas, synchronous call chains, lockstep deployment requirements -- because the teams will still have to coordinate constantly regardless of the repo boundary; the repos will just make that coordination more annoying (cross-repo PRs, version pinning) without reducing how often it's needed. This is the reasoning behind the **'inverse Conway maneuver'**: if you want a system to become more modular and teams more independent, restructuring the teams and their ownership/communication patterns first tends to produce the architectural decoupling you want, more reliably than restructuring the repository first and hoping the org catches up. Conversely, dumping everything into one monorepo doesn't automatically produce collaboration or shared ownership if there's no reinforcing discipline -- without CODEOWNERS-style path ownership, clear API boundaries between teams' directories, and build-visibility rules, a monorepo just becomes a large commons where nobody is quite sure who owns what, and Conway's law reasserts itself informally anyway: teams still only really talk to the teams they already talk to, they just now also occasionally step on each other's code without meaning to. ## When repo structure and team structure drift apart The practical failure mode shows up whenever repo structure and team structure drift out of sync and nobody revisits the mapping. 1. A common real-world version: a company splits into a polyrepo-per-microservice structure while team boundaries were drawn along a different axis (say, by feature area rather than by service), so a single feature change routinely requires coordinated PRs across three or four repos owned by the same team -- the repo boundary is now pure friction with no corresponding organizational benefit, because the 'other side' of each repo boundary is the same team talking to itself across a slower channel. 2. The opposite failure: a team is split off to own a new bounded context, but its code stays embedded in the general monorepo commons with no path ownership or build-visibility enforcement, so other teams keep casually reaching into what should now be that team's private implementation, and the new team never gets the isolation its org chart implies it should have. ## Revisit topology when the org changes The practical guidance that follows is to treat repo topology as something to revisit deliberately whenever team structure meaningfully changes -- a team splitting, merging, or its actual coupling with another team shifting -- rather than as a one-time architectural decision. The broader 'Team Topologies' framework (Skelton and Pais), and well-documented industry experience at companies like Spotify and Amazon, is built directly on this idea: design team boundaries around the coupling you actually want in the system first, and let repository and service boundaries follow from that, rather than picking a repo strategy and hoping team structure conforms to it.
- What is the 'inverse Conway maneuver,' and why would a company use it instead of just restructuring repositories?It's the practice of deliberately restructuring teams and their communication/ownership boundaries first, in order to produce a desired software architecture, rather than trying to impose that architecture directly. The reasoning is that Conway's law will reassert itself regardless of how you draw repo lines -- if the same people keep talking to each other daily, their code will keep coupling tightly no matter how many repos you split it into -- so changing the org chart is a more reliable lever for architectural decoupling than changing repo topology alone.
- If a monorepo doesn't automatically prevent teams from stepping on each other's code, what actually has to be added to make ownership boundaries real inside it?Enforced path ownership (CODEOWNERS-style required approvals per directory), build-visibility rules that restrict which targets can depend on which without an explicit, reviewed exception, and often a clear internal-API convention so one team's directory exposes a stable surface rather than being freely reached into. Without these, the monorepo's flat, everything-visible structure just becomes a commons, and de facto ownership reverts to whichever team already talks to whichever other team -- Conway's law expressing itself informally.
It's like seating charts in an office: if you want two people to collaborate closely, you sit them next to each other rather than just telling them to email more; the desk (repo) layout either reinforces or fights the collaboration pattern you actually need, and moving desks without changing who reports to whom rarely fixes a broken collaboration pattern by itself.
saying these in an interview costs you the question
- treats Conway's law as just 'org chart should match code structure' without the communication-cost mechanism behind it
- believes splitting repos automatically creates team independence
- believes a monorepo automatically creates cross-team collaboration with no supporting discipline
- unaware of the 'inverse Conway maneuver' framing when discussing this at a senior/principal level
- doesn't mention that repo structure should be revisited as team structure changes