What you'll learn: By the end of this lesson you will be able to state Conway's law as its author wrote it, explain why a micro-frontend split that ignores team structure produces a distributed front-end monolith, compare teams organised by technical layer with teams organised by business slice, use the four team types and three interaction modes of Team Topologies to place a shell team, a design-system team and product teams, run a simple feature census to test whether your boundaries match your teams, and describe what the "inverse Conway manoeuvre" asks and where it stops working.
Picture a house built by two contractors who never talk to each other. One builds the ground floor and the other the upper floor, each from their own copy of the drawing. The staircase lands where the two contracts meet, and nowhere a family would choose. Nothing in the bricks explains the odd staircase. The explanation is in who spoke to whom.
Software has the same property, and a front end split into independently deployed pieces shows it plainly, because each piece has a visible edge and an owner. This lesson is about where those edges should be and why the answer depends on people as much as on code. Earlier lessons in this module covered whether to split and how to compose the pieces. Here the question is who owns what, and what happens when the answer and the architecture disagree.
The running example is the storefront again: catalog, basket and checkout pieces behind a shell. We compare two ways of organising the people who build it, both described, neither a real company.
The core idea
The structure of a system tends to copy the structure of the communication between the people who build it, so micro-frontend boundaries only hold when they are also team boundaries.
Three statements carry the lesson:
- Conway's observation. In his 1968 article "How Do Committees Invent?" Melvin Conway concluded that organizations which design systems "are constrained to produce designs which are copies of the communication structures of these organizations." It is an observation about how designs come to be, not a rule you can switch off.
- Coupling follows communication. Martin Fowler's page on the law quotes Chris Ford: "software coupling is enabled and encouraged by human communication." Where two groups talk constantly, their code will be intertwined. Where they rarely talk, an interface appears.
- So draw both maps together. Fowler's page says modular decomposition and organizational decomposition must be done together, and must evolve together. A micro-frontend split drawn on a diagram but not in the org chart is a plan to fight Conway's law, and the law usually wins.
Three illustrations run through the lesson, each labelled:
- Minimal example: a "feature census" that counts how many teams each change touches.
- Realistic example: a storefront organised by layer, reorganised around business slices, in "In practice".
- Failure example: a shared design-system release that nobody owns the rollback of.
What Conway actually wrote
The article is about committees designing systems, and it makes a precise structural argument: the design effort is split among groups, and the interfaces of the system come to mirror the communication paths between those groups. Two other sentences from it matter for front-end work.
First: "Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change." Conway concludes that organizational flexibility is therefore important to effective design. Boundaries drawn on day one will be wrong in places, so the organization must be able to move them.
Second: "Every time a delegation is made and somebody's scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed." Handing a piece to a team gives that team a smaller view and so a narrower set of choices. That is the benefit of delegation (focus) and its price (the whole is no longer anyone's view).
How firm is the law? Fowler's page cites no controlled study: its support is Conway's article, Brooks's naming of the law, and practitioner experience, and it says architecture is highly context-specific. Treat the law as a strong prior that is cheap to test in your own organization, not as a theorem.
Two ways to organise the storefront teams
The pieces of a micro-frontend system can be owned by teams cut in two different directions.
By layer. One team owns all UI components, another all services, another the build and deploy pipeline. A feature such as "choose a delivery slot at checkout" needs the UI team, the services team and the platform team to coordinate. Cam Jackson's article on micro-frontends argues against this shape: it says teams should be formed around vertical slices of business functionality, not technical capabilities, and that "each application should be owned by a single team". It names horizontal teams built around technical concerns such as styling or forms as the thing to avoid.
By slice. Each team owns one business area end to end: its pieces of the user interface, the services behind them and its release. Fowler and Lewis's article on microservices describes the same shape for services: teams organised around business capabilities are cross-functional, covering user experience, storage and project management, and each service includes its own interface, persistent storage and external collaborations. Fowler's Conway page adds that layer-based or lifecycle-based teams often clash with feature work, since each feature needs close collaboration across the layers.
| Property | Teams by layer | Teams by business slice |
|---|---|---|
| A new checkout feature touches | UI, services and platform teams | One team, plus a contract with neighbours |
| What the boundary on the diagram follows | Technology | Business capability |
| Natural micro-frontend cut | None: the cut would split every feature | One piece per slice |
| Typical queue | Each layer team's backlog | The slice's own backlog |
| Weakness | Hand-offs for every feature | Duplication, and inconsistency unless a platform exists |
Figure 1. The same product, two team shapes
How to read this: on the left, one feature needs two teams and two queues. On the right, the same feature lives with one team. A micro-frontend boundary can follow the right-hand shape. It cannot follow the left, because each feature would cross it.
A feature census: the minimal test
You do not need a model to see whether your boundaries match your teams. Take the last ten or so changes that shipped (a small sample; the number is yours to choose) and, for each, write down which teams had to change something. An illustrative result for the storefront organised by layer:
| Change | UI team | Services team | Platform team | Teams touched |
|---|---|---|---|---|
| Add delivery slot picker | yes | yes | no | 2 |
| New basket line-item badge | yes | no | no | 1 |
| Payment method update | yes | yes | yes | 3 |
| Fix slow product list | yes | yes | no | 2 |
Four rows, illustrative data: in this table three of four changes needed more than one team. Read the pattern, not the number. If most changes touch several teams, the team boundaries do not follow the change boundaries, and splitting the code along the same lines would turn each of those changes into a cross-release project.
A second signal is the reverse: a team that is constantly waiting on a shared piece owned by someone else. A boundary that looks clean in the repository may still be a queue.
Team Topologies as a vocabulary
Team Topologies offers shared terms for exactly this. Its key-concepts page defines four team types:
- Stream-aligned team: aligned to a flow of work from, usually, a segment of the business domain, and able to deliver in that stream without hand-offs to other teams.
- Enabling team: helps a stream-aligned team overcome obstacles, and temporarily boosts skills in other teams before moving on.
- Complicated-subsystem team: owns work where significant mathematics, calculation or technical expertise is needed.
- Platform team: a grouping of other team types that provides a compelling internal product, to speed up delivery by stream-aligned teams by removing complexity.
It also defines three interaction modes: collaboration (working together for a defined period to discover something), X-as-a-Service (one team provides and one consumes, with minimal interaction) and facilitating (one team helps and mentors another). And it states the idea that makes all of this a design constraint: teams can handle only so much complexity before breaking down, and overloaded teams make poor decisions and move slowly. That is cognitive load.
A mapping to the storefront (design judgement, not something the Team Topologies pages prescribe for front ends):
| Team | Type | Owns | Interaction with product teams |
|---|---|---|---|
| Catalog, basket, checkout | Stream-aligned | Its micro-frontend, its services, its release | Collaboration at first, then X-as-a-Service with neighbours via contracts |
| Frontend platform | Platform | The shell, the design system, the deployment pipeline, shared-dependency rules | X-as-a-Service: product teams consume it without asking |
| Web performance specialist group | Enabling | Skills, reviews, measurements | Facilitating, then moving on |
| Visual editor engine, if there is one | Complicated subsystem | A hard component with deep expertise | X-as-a-Service |
The mapping explains a common conflict. A shell team that approves every product team's release is a gate, not a platform: the platform's job is to make the right thing the easy thing, so that product teams ship without asking. The pipeline and shared-dependency rules described in Independent Deployment and Shared Dependencies are the platform team's product.
Figure 2. Teams and the pieces they own
How to read this: ownership arrows run from teams to the pieces they build and release. The platform team's arrow is dashed because it is provided as a service that product teams consume, not a stage in their release.
Reading the system as a communication map
Conway's law can be used as a diagnostic. Look for these symptoms of boundaries that disagree with teams:
- A change that needs several teams to release together. The pieces are separate in code and joined in practice. This is the distributed front-end monolith that the first lesson of this module describes.
- A shared component library that every team waits on. One group owns code that everyone else needs changed.
- Ownerless shared code. A package used by three pieces and owned by none: nobody ships its fixes or rolls it back.
Figure 3. A feature crossing teams, compared with one team
How to read this: in the top half every arrow between two teams is a queue. In the bottom half the teams are the same size but the work does not leave the slice.
The inverse Conway manoeuvre, and its limits
If structure follows communication, you can shape the structure by changing the communication, that is, the teams. Fowler's page calls this the Inverse Conway Maneuver and says the term was coined by Jonny LeRoy and Matt Simons in a 2010 Cutter IT journal article: deliberately organize teams to encourage the architecture you want. It ties the idea to microservices, where small, long-lived, business-capability teams are meant to produce independently deployable services.
It is not a switch. Fowler's page warns that reorganizing teams around a rigid existing system is unlikely to be an instant fix and may create friction, and advises small steps with a watch on feedback. Two further limits from the same page:
- Small organizations do not need it. Small teams of a dozen or two communicate informally and tend to build a monolith. If one team owns the whole front end, a modular monolith is usually the honest answer, not micro-frontends.
- Distance matters. Conway's law applies to remote teams, but the relevant communication is online, and time zones still matter. A boundary that needs daily conversation is expensive between teams that share few working hours.
Figure 4. Should the split follow the teams?
build the front end?"} -->|"one"| M["Keep one codebase,
modular inside"] Q1 -->|"several"| Q2{"Are teams cut by
business slice?"} Q2 -->|"no, by layer"| R["Reorganise around slices first
(small steps)"] Q2 -->|"yes"| Q3{"Does a typical change
touch more than one team?"} Q3 -->|"often"| R2["Move the boundary,
then split"] Q3 -->|"rarely"| S["Split along team boundaries,
add a platform team"]
How to read this: the split is the last step, not the first. The first questions are about people. If you cannot answer them well, the code boundary will not hold.
Trade-offs
| Choice | You gain | You pay |
|---|---|---|
| Teams by slice with micro-frontends | Independent releases, clear ownership, fewer hand-offs | Duplication, inconsistency across pieces, the need for a platform team |
| Reorganise first, split later | Boundaries proven by working practice | Time before any technical change shows |
| Split first, hope teams follow | Quick visible progress | Distributed monolith, drift between diagram and org chart |
The other side of this topic
The same law shapes the server side. Splitting a back end into services without splitting who owns them gives a distributed monolith there too; the back-end lesson Decomposing Microservices: Data Ownership and Distributed Monoliths works through the data and runtime coupling, and it states the same rule: a service boundary pays only where a team can change and ship without waiting. A common arrangement follows one business cut through the whole stack, so the catalog slice owns its piece of the page and its catalog services together.
In practice: a storefront reorganised before it is split
This is a realistic scenario, not a case history. It is a composite built from common patterns. It describes no specific company or product, and every number in it is an illustrative assumption.
The situation
A storefront has three teams by layer: UI, services and platform, about 24 people in all (illustrative). The leadership wants micro-frontends so "teams can release independently". The feature census of the last quarter shows that most changes touched at least two teams, and the UI team's backlog is the constraint on every other team.
Starting architecture
Figure 5. Layer teams and one front-end codebase
How to read this: all three teams push into one codebase and one release train. The warning colour marks where independence is missing, which is the team structure as much as the code.
Options considered
| Option | What it fixes | What it costs |
|---|---|---|
| Split into micro-frontends, keep the layer teams | A visible technical split | Every feature still crosses teams, now also across deployments |
| Reorganise into slice teams, keep one codebase for now | Ownership and hand-offs | Reorganisation effort, and a period with no technical change |
| Reorganise, then split along the proven slices | Boundaries that match the teams | Two phases and more elapsed time |
The decision
| Field | Decision record |
|---|---|
| Context | Layer teams, a shared release train, and a census showing most changes cross teams. |
| Decision | Form three stream-aligned teams (catalog, basket, checkout) that own screens, services and release for their slice, plus a small platform team for the shell, the pipeline and the shared-dependency rules. Keep one deployable for the first phase, with module boundaries per slice and an owner for each. Split deployables only after a trial period (two quarters, illustrative) in which the census shows most changes touch one team. |
| Consequences, good | Boundaries tested in daily work before they cost a deployment; clear owners. |
| Consequences, bad | Slower visible progress; some duplication between slices; reorganisation is disruptive. |
| Revisit when | The census still shows many cross-team changes after the period. Then the slices are wrong, and the boundary moves before anything is split. |
Rollout and verification
- Map ownership. For every directory and shared package, name one owning team. Anything unowned gets an owner or is retired.
- Move people in small steps, as Fowler's page advises: start with one slice (checkout) and compare its cross-team changes with the others.
- Repeat the census each quarter and chart the share of changes that touch more than one team.
- Split one piece when the data supports it, using the contract and dependency practices of the earlier lessons in this module.
The 2 a.m. failure
At 02:00 a release of the shared design-system package changes a button's behaviour, and two pieces break on their checkout and basket forms. The package has no single owner: the platform team publishes it, but each product team reviews changes for its own area, and nobody has the rollback runbook. The checkout on-call finds a failing region but the package's repository is not theirs; the platform team's on-call is in another time zone.
First three checks: (1) find the package version each broken piece loaded and compare it with the last known good release; (2) check who last published it and whether their pipeline can revert; (3) look for a pinned older version a piece can use immediately. Mitigation: pin the previous version in the affected pieces, or move the shared dependency pointer back, and say who may do it. Follow-up: give the package one owning team with an on-call and a rollback runbook, require a contract test from each consuming team in the package's pipeline, and add "who owns the rollback" to the checklist for every shared artefact.
Architect's notes
- Draw the organization first. Before any module boundary, write down the teams, who talks to whom daily, and what each team can release alone.
- Give every shared artefact one owner and an on-call. A shared thing with several owners has none.
- Treat the platform team's output as a product with users. If product teams work around it, it is a gate.
- Run the census before and after any reorganisation. It is cheap evidence that does not depend on opinions.
Common mistakes
- Splitting the code before the teams. The result is a distributed monolith with extra deployments.
- Cutting pieces by technical concern (forms, tables, modals), which mirrors horizontal teams.
- A platform team that approves every release. That makes it a gate.
- Ownerless shared packages.
- Treating a reorganisation as instant. Fowler's page advises small steps and feedback.
Key takeaways
- Conway observed that organizations which design systems produce designs that copy their communication structures.
- Coupling follows communication, so micro-frontend boundaries hold only where they are also team boundaries.
- Teams by layer cross every feature; teams by business slice can own a feature end to end, and a micro-frontend can follow the slice.
- Team Topologies gives four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes (collaboration, X-as-a-Service, facilitating), and warns about cognitive load.
- A platform team provides the shell, pipeline and shared rules as a service. If it approves every release, it is a gate.
- A feature census, counting the teams each change touches, tests the match between boundaries and teams.
- The inverse Conway manoeuvre shapes teams to get the architecture you want. Take small steps and watch for feedback.
- One team, or a small organization, usually needs a modular monolith, not micro-frontends.
Practice exercises
Exercise 1 — Starter (30 min): List the last ten changes your team shipped and, for each, the teams that had to change something. Count the share that touched more than one team. Say in two sentences what that suggests about your boundaries.
Exercise 2 — Intermediate (2 hours): Draw your organization as a communication map (who talks to whom at least weekly) and your front end as a module map, on one page. Mark every place they disagree. Propose one change to the teams and one to the code that would reduce the disagreement.
Exercise 3 — Advanced (half day): Write a one-page platform-team charter for a front end with four product teams: what it provides as a service, what it will not do, how product teams ask for changes, and how you would tell, from observable signals, that it has become a gate.
Related reading
In this course:
- Monolith vs Micro-Frontends, whether to split and the distributed front-end monolith.
- Micro-Frontend Composition Approaches.
- Independent Deployment and Shared Dependencies, the platform team's shared rules in detail.
- Cross-App Communication in Micro-Frontends, the contracts between pieces.
Elsewhere on the site:
- Backend: Decomposing Microservices, Data Ownership and Distributed Monoliths, the same pressure on the server side.
Official documentation
- Melvin Conway: How Do Committees Invent? (Datamation, April 1968), the original statement.
- Martin Fowler: Conway's Law, including the Inverse Conway Maneuver and its caveats.
- Martin Fowler: Micro Frontends, by Cam Jackson.
- Martin Fowler and James Lewis: Microservices, teams organised around business capabilities.
- Team Topologies: key concepts, team types, interaction modes and cognitive load.