When carving ownership boundaries in a monorepo, why do teams try to align project/module ownership tags with the org's team structure, and what goes wrong when that alignment drifts, per Conway's Law?

## What Conway's Law says Conway's Law, first stated by programmer Melvin Conway in a 1968 paper, 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 The mechanism behind it is straightforward once stated: building any nontrivial piece of software that spans more than one person requires coordination. - Coordination between two people who **sit on the same team**, share a manager, and talk daily is **cheap**. - Coordination **across a team boundary** — different priorities, a Slack message that waits a day for a reply, a meeting that has to be scheduled — is **expensive**. Engineers, often unconsciously, route around expensive coordination by drawing module and API boundaries so that most of their day-to-day changes stay within the cheap-communication zone, i.e., within their own team's owned code. Do that enough times across an organization and the resulting system's module graph ends up shaped like the org chart, not because anyone designed it top-down, but because it's the path of least resistance for every individual change. ## How it plays out in a monorepo In a monorepo specifically, this plays out through **ownership tags**: when a project's scope tag or CODEOWNERS entry names a team, and that team's actual composition and remit line up with the module's real boundaries, most pull requests touching that module only ever need approval from — and coordination with — people already working toward the same goals. This is the state teams aim for when they say they want ownership aligned with the org: not an aesthetic preference, but an attempt to make the cheap-coordination path and the correct-review path the same path. ## When the two drift apart The trouble starts when the two drift apart, which happens constantly in a growing organization: a team gets split into two (checkout becomes cart and payments), a team merges into a larger group, or a module's original owning team is disbanded and its responsibilities are informally redistributed without anyone updating the ownership metadata to match. Once that drift exists, changes that used to stay within one team's cheap-coordination zone now routinely need approval from a different team than the one actually doing the day-to-day work. Concretely this shows up as: - PRs needing sign-off from a CODEOWNERS entry mapping to a team the author doesn't work with day-to-day; - a rising rate of PRs requiring multiple different owning teams' approval because the module boundary now straddles two teams' actual responsibilities; - a general sense that everything requires talking to another team now, even though code complexity hasn't changed. The friction is organizational, not technical, and it's easy to misdiagnose as a codebase problem when it's really a Conway's-Law misalignment problem. ## The inverse Conway maneuver The deliberate fix is called the 'inverse Conway maneuver': instead of letting architecture passively emerge from whatever the org chart happens to be, an organization designs the target module or service boundaries first, based on the business domains it wants to be independently changeable, and then intentionally shapes team structure to match those boundaries, so Conway's Law works for the intended architecture instead of against it. This is the reasoning behind many 'align teams to domain boundaries' reorgs in companies practicing domain-driven design or platform-team models: the org chart is treated as a lever for shaping the system, not just an HR artifact. ## The limits of the alignment goal It's worth being explicit about the limits of this alignment goal: perfect one-to-one correspondence between teams and modules is not always desirable or even achievable. Shared or platform code — authentication libraries, a design system, core infrastructure tooling — is intentionally owned by one team but consumed by many, and forcing every consumer to fork or privately own a copy just to preserve alignment usually trades one problem, occasional cross-team coordination on a well-scoped shared module, for a worse one: duplicated, divergent implementations with no single source of truth. The realistic goal is that most day-to-day change stays within team boundaries, with a small number of deliberately shared, well-governed exceptions — not that every dependency edge in the module graph maps exactly onto an org-chart edge.