The architecture review has an agenda, three options on a slide, and a decision recorded in the minutes at the end. Anyone who has sat through several of these knows the real decision usually happened before the meeting started. What's less obvious is why, and the answer is older than most of the tooling in the room.
In April 1968, Melvin Conway published a paper in Datamation called 'How Do Committees Invent?' It's short, it's not an empirical study, and Harvard Business Review had rejected an earlier version of it on the grounds that he hadn't proven his thesis. Sixty years of software organizations have proven it anyway. If you are scoping engineering management for a business rather than a codebase, XenGrowth, who work on the commercial side of this covers that angle.
What Conway actually said
His formal claim, in his own words: organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Not culture. Not intent. Constrained — meaning the shape of the design follows the shape of who talks to whom, whether or not anyone in the room wants that outcome.
Two things about this get lost in the paraphrase that circulates today. First, Conway never called it 'Conway's Law' — that name came from Fred Brooks, who cited the paper in The Mythical Man-Month years later and gave it the label that stuck. Second, the paper isn't built on the large empirical survey people sometimes credit it with. It's a reasoned argument, illustrated with small cases — Conway's best-known example is an eight-person team asked to build a COBOL and an ALGOL compiler, which ended up producing a two-pass design, matching the team's own split into two subgroups, not because a two-pass design was technically superior but because that's how the team was already talking to itself.
Harvard Business Review's rejection is worth sitting with. The editors' objection wasn't that Conway was wrong — it was that he hadn't proven it. What decades of software organizations subsequently demonstrated is that some true things about organizations are visible well before anyone runs the study that would formally prove them.
Why coordination cost is the actual mechanism
Conway's argument works through a simple asymmetry: two engineers on the same team can settle a design question over a fifteen-minute conversation, because they share context, incentives and a manager who can arbitrate if they can't agree. Two engineers on different teams settling the same question need a meeting, an agenda, stakeholders from both sides, and usually a written proposal, because neither has the standing to bind the other's team to a decision. That asymmetry doesn't go away because the cross-team option is technically better. It just makes the cross-team option more expensive to pursue, so organizations systematically under-invest in exactly the designs that would require the most coordination — which are often the ones a system genuinely needs, since the coordination cost and the architectural benefit tend to correlate. The XenGrowth resource library goes further into the operations side of this.
Decision inside one team | Decision crossing a team boundary | |
|---|---|---|
Who can make the call | The team lead, informally, same day | Requires agreement from both teams' owners |
Cost to propose | Low — a Slack thread or standup | High — a doc, a meeting, stakeholder buy-in |
Default outcome under time pressure | Gets made | Gets deferred, or made unilaterally by whoever ships first |
Who effectively holds a veto | Nobody in particular | Whoever owns the boundary being crossed |
The meeting is theater for a decision the org chart already made
This is the uncomfortable part. By the time a cross-team architecture question reaches a review meeting with three options on a slide, the actual field of possible outcomes has usually already been narrowed by which team can move fastest without needing the other's sign-off, and which team's manager has the standing to say no. The meeting ratifies that narrowing. It rarely reopens it, because reopening it would mean re-litigating a coordination cost that was paid, informally, over the preceding weeks.
This is also why an engineer who is confident their proposal is correct is sometimes baffled that it loses to a worse option that happened to sit entirely inside one team's boundary. The comparison being made in the room isn't purely technical merit; it's technical merit divided by coordination cost, and a mediocre option that avoids a cross-team dependency frequently beats a better one that requires it.
What this means for getting a cross-boundary decision made
Identify the actual boundary the decision crosses before you write the proposal. If it's inside one team, you're arguing technical merit and that's usually enough. If it crosses teams, technical merit is necessary but not remotely sufficient
Reduce the coordination cost directly, rather than only strengthening the technical case. A pre-negotiated interface, a shared owner for the boundary, or a pilot scoped to avoid needing both teams' full sign-off up front all lower the actual obstacle, which the technical argument alone does not touch
Find whoever effectively holds the veto — usually whoever owns the team the decision would take dependency-creating work away from or add it to — and get their agreement before the review, not during it. The meeting is not where boundary-crossing decisions get negotiated; it's where they get recorded
If a design keeps failing to get adopted despite being correct, check whether the org chart is the actual obstacle before concluding the argument itself needs more work. Conway's mechanism predicts this exact failure mode, and no amount of better slides fixes a coordination-cost problem
Turning the mechanism around
If coordination cost shapes design, a later and more deliberate idea follows naturally from it, even though it isn't in Conway's own paper: restructure the teams first, and the design that follows will tend to match the structure you actually wanted. Practitioners sometimes call this the inverse Conway maneuver — instead of discovering after the fact that your microservices boundaries match your team boundaries by accident, you draw the team boundaries you want the architecture to have and let the coordination-cost mechanism do the rest of the work. It's a reasonable extension of the original argument, but it's worth being clear it's an extension: Conway's paper describes what happens, it doesn't prescribe reorganizing as the fix, and a reorg carries its own costs that a purely architectural read of the idea tends to underweight. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
Where this shows up most concretely is in decisions about shared infrastructure. A platform team and three product teams each building against a common service is a textbook cross-boundary situation: the platform team owns the boundary, so any product team's request to change the shared service's behavior runs into exactly the coordination cost Conway's mechanism predicts. This is not a design flaw to be argued away with a better technical proposal. It's the structure working as intended, for better and worse — and the honest response is either to accept the coordination cost as the price of shared infrastructure, or to change the team boundary deliberately, not to keep resubmitting technically superior proposals into a boundary that isn't going to move.
Situation | What Conway's mechanism predicts | What usually actually happens |
|---|---|---|
Two teams, no shared owner, overlapping domain | Duplicated logic, inconsistent behavior at the seam | Confirmed repeatedly in practice — the seam becomes the bug-prone part of the system |
One team owns a widely-depended-on service | That team's roadmap becomes an informal veto on every dependent team's plans | The platform-team-as-bottleneck complaint, which is this exact mechanism |
A reorg merges two previously separate teams | Coordination cost drops; designs that were previously avoided become newly cheap | Often true short-term; the org then discovers a new boundary it didn't have before |
The honest limit of Conway's argument
It's worth being precise about what this framework does and doesn't establish, because the paraphrase that circulates online oversells it. Conway's paper is not a controlled study; it's a reasoned argument from a small number of illustrative cases, and Conway himself would likely have resisted the certainty with which people now cite 'Conway's Law' as an empirically proven mechanism. What decades of subsequent software-engineering practice have done is repeatedly observe the predicted pattern — systems that mirror the org chart that built them — often enough that the mechanism is treated as reliable, even without the formal proof that was originally missing.
That distinction matters for how you use the argument. It's a strong predictive heuristic for where a good technical decision will struggle to get adopted, and a useful diagnostic when a correct proposal keeps stalling for reasons nobody can quite name. It is not a claim that org charts determine software quality, or that reorganizing a team automatically produces a better architecture — a reorg changes who talks to whom, but it doesn't, by itself, change the coordination costs that made the original design hard to avoid. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.
It's also worth noticing what this mechanism does not explain, because over-applying it is its own mistake. Not every lost technical argument is a coordination-cost problem — some are simply wrong, and some lose for reasons closer to the ones covered elsewhere in this series, where correctness and organizational persuasiveness are different skills scored differently. Conway's mechanism is specifically about the added cost of decisions that cross a communication boundary. If your proposal stayed entirely inside one team and still lost, the org chart isn't the explanation, and looking for one there will send you down the wrong diagnostic path.
The one thing worth doing differently
Most engineers treat the review meeting as the decision point and put all their effort into the proposal that gets presented there. Conway's argument suggests the leverage is earlier: in whether the coordination cost between the teams affected by a design has been reduced before anyone writes a slide. That's less satisfying than winning a room with a good argument. It's also the part of the process that actually determines the outcome, which the room-winning skill described elsewhere in this cluster only ever gets to operate on after the fact.
The practical test is simple enough to run before your next cross-team proposal: name the team boundary the decision crosses, name who owns each side of it, and ask honestly whether either owner has a reason to prefer the status quo. If the answer is yes, that's the actual obstacle, and it's worth addressing directly rather than treating as a communication failure to be solved with a better deck.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If engineering management is part of a growth programme rather than a standalone build, the team at XenGrowth is the companion reading.
Five questions on the actual 1968 paper, not the version that circulates as a paraphrase.
