code-ownership-and-boundaries

Code Ownership and Boundaries

Unclear ownership shows up as either "nobody reviews this, it merges unchecked" or "five teams have to approve every change, so nothing ships." Both are ownership-boundary problems, not process problems to fix with more approval steps — fix the boundary, not the process on top of it.

Conway's Law: architecture mirrors communication structure

"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." (Melvin Conway, 1968)

The practical implication: if a single logical feature routinely requires coordinated changes across three teams' codebases, that's evidence the module boundaries don't match the team boundaries — not a sign that the teams need better coordination processes. The fix is usually to move the boundary (merge the modules under one team, or split the team along the same line the module already has), not to add more cross-team meetings. This also runs in reverse (the "inverse Conway maneuver"): deliberately restructuring teams to match a desired target architecture, used when you're confident in the target design and want the org to converge toward it.

CODEOWNERS as enforced, not aspirational, ownership

A CODEOWNERS file (GitHub/GitLab convention: a file listing path patterns mapped to required reviewers/teams) turns "the payments team owns /services/payments/" from a wiki page nobody checks into a rule the platform enforces at merge time — a PR touching that path cannot merge without an approval from that team, regardless of who authored it.

Guidelines for a CODEOWNERS file that actually works:

• Map ownership to the same boundary the org chart uses, per Conway's Law — if CODEOWNERS says team A owns a directory but the people who actually understand that code report to team B, the file is documenting a fiction and reviewers will rubber-stamp without real review.
• Every path should resolve to exactly one clear owner for the common case; shared/overlapping ownership across many paths is a sign the module boundary itself needs redrawing, not a routing problem to solve with more reviewers per rule.
• Keep rules narrow enough that the named owner can actually review meaningfully — a single team listed as owner of the entire repository root is not real ownership, it's a formality that guarantees shallow review.
• Update CODEOWNERS when teams reorganize, in the same change that reflects the reorg elsewhere — a stale file routes reviews to a team that moved on, producing exactly the rubber-stamp problem above.