How does Conway's Law — the observation that a system's architecture mirrors the communication structure of the organization that built it — inform how you draw the boundaries between microfrontends and assign team ownership, and what goes wrong when the technical boundaries and the team boundaries don't match?

## What the law says Conway's Law, first stated by Melvin Conway in 1968, observes that any organization that designs a system will produce a design whose structure mirrors the organization's communication structure — teams that talk to each other easily produce tightly coupled modules, and teams that are organizationally separated produce loosely coupled ones, regardless of what the org chart says the intended architecture is. Microfrontends are one of the few architectural patterns where this isn't treated as an unfortunate side effect to route around, but as the design principle itself: the entire justification for splitting a frontend into independently-owned fragments is to let each team ship on its own schedule, and that only works if the fragment boundary and the team boundary are the *same* boundary. This is sometimes called the **inverse Conway maneuver** — instead of letting team structure accidentally produce architecture, you deliberately shape team structure (or fragment boundaries) so the two stay aligned on purpose. ## Business capability versus technical layer In practice this means splitting by business capability rather than by technical layer or UI type. Contrast the two: | Boundary drawn | What a single product change costs | |---|---| | **By business capability** | a "checkout team" owning the entire checkout fragment — cart summary, payment form, confirmation screen — can ship a change to any part of that flow without asking permission from anyone else, because nothing about checkout's internal behavior crosses into another team's territory | | **By technical concern** | one team owns "all modals across the site," another owns "all forms," so a single product change (say, redesigning the checkout confirmation modal) now requires the modals team and the checkout team to coordinate, because the boundary cuts across a single piece of user-facing behavior rather than isolating it | The business-capability split isn't just aesthetically cleaner; it's the one that actually produces the loosely-coupled, independently-deployable pieces the whole architecture promises. This mirrors exactly how backend teams organize around bounded contexts in domain-driven design — microfrontends are the same idea applied to the presentation layer. ## The trade-off The trade-off is that business-capability boundaries sometimes cut against natural technical reuse. A "design system" or a set of shared low-level components (buttons, inputs, date pickers) doesn't belong to any single business capability, so it needs its own ownership model — usually a platform or design-system team that publishes a versioned, shared package everyone consumes (governed by the same additive/breaking versioning discipline as any other contract). Getting this split wrong in the other direction — carving out "shared" ownership for things that are actually business-capability-specific — recreates the coordination problem inside what was meant to be a shared, low-friction layer. ## Two failure modes when the boundaries diverge When technical and team boundaries diverge, two distinct failure modes show up, and they're worth naming separately because they look different in practice. 1. **The first is *shared ownership of a single fragment*:** two teams both need to touch the same microfrontend because its boundary doesn't map to either team's actual responsibility. This produces the classic "everyone owns it, no one owns it" pattern — code quality erodes because no team feels fully accountable for it, deploys get slower because both teams need to review changes touching shared code, and the fragment becomes a magnet for cross-team disputes about priority. 2. **The second is *a single feature spanning multiple team-owned fragments*:** a product change that touches, say, the header (team A), the cart (team B), and checkout (team C) simultaneously now requires a mini-release-train just for that one feature — exactly the cross-team coordination overhead microfrontends were adopted to eliminate. Both failure modes are symptoms of the same root cause: the fragment split was drawn by a technical or historical accident (e.g. "this is just how the old monolith's routes happened to be organized") rather than by a deliberate mapping to team responsibility. ## The test to apply before you commit to a split A well-known real-world instance of getting this right is how large e-commerce and media platforms (Zalando, Spotify's engineering culture writings on "squads" owning end-to-end features, IKEA's public microfrontend platform writeups) explicitly organize frontend teams around a single business capability with full-stack ownership — front end, relevant backend services, and often the on-call rotation for that slice — precisely so the Conway's-Law mirroring works in their favor instead of against them. The practical takeaway for someone drawing these boundaries: before finalizing a microfrontend split, ask "does exactly one team have the authority and full context to change this fragment without asking anyone else?" If the honest answer is no, the boundary is wrong, not the team structure — or the team structure is wrong, not the boundary — but the two must be reconciled before the split is trustworthy.