Team ownership, boundaries and Conway's law

Micro-frontends are an organizational tool first. The architecture works when the split between remotes matches the split between teams, and every piece has one clear owner.

Conway's law in one paragraph

In 1968 Melvin Conway observed that organizations design systems that copy their own communication structure. If four teams build a frontend, the frontend tends to end up with four parts, and the interfaces between the parts look like the conversations between the teams.

For micro-frontends this works in both directions. If the remotes follow the team structure, each team can work alone most of the time. If they cut across it, every change needs a meeting. This is also why the architecture makes little sense for a single team, as explained in when to use micro-frontends.

Split by business domain

The unit of a micro-frontend is a business area that a user would recognize: orders, billing, catalog, customer support. Each has its own screens, its own data and its own roadmap.

Splits that fail:

• By technical layer. A remote for components, another for data access. Every feature touches all of them.
• By page fragment. A remote for the header, another for a table, another for a form. The teams must coordinate on every screen.

A useful test for a boundary: can the team deliver a typical feature in this area without a change in any other remote? If the answer is usually yes, the boundary is good.

One remote, one owner

Every remote has exactly one owning team. That team:

• Decides what is built and when it is released.
• Owns the pipeline and the production health of the area.
• Receives its alerts.
• Reviews every change to its code.

A team can own more than one remote. A remote shared by two teams has no owner in practice. If two teams need to change the same remote regularly, the boundary is wrong or the two teams should be one.

Write the ownership down: a table of routes, remotes and teams, kept next to the manifest. Code owner files in the repositories make it enforceable.

What the platform team does

Autonomous teams need a common base. A platform team provides it as an internal product:

• The host: layout, navigation, session, loading of remotes.
• The contract between host and remotes, and its versioning.
• The design system, or close cooperation with the team that owns it.
• Pipeline templates, project generators and the shared dependency policy.
• Monitoring that attributes errors and performance to each remote.
• Documentation and support for the feature teams.

What it should avoid:

• Building business features.
• Approving every release. If the platform team is a gate, the bottleneck has only moved.

In a small organization the platform team can be two people working part time. What matters is that the role exists and has time assigned.

Signs of a distributed monolith

A distributed monolith has the costs of micro-frontends and the coupling of a single app. The signs are visible in how teams work before they show up in the code:

How to avoid it

• Keep shared code thin. Share the design system, the contract and technical utilities. Business logic stays inside its area, even at the price of some duplication.
• Communicate through explicit contracts. Navigation, a small set of events and the backend. See communication between micro-frontends.
• Keep backward compatibility. A remote must work with the previous version of the host and of its neighbours. That is what allows separate releases.
• Review boundaries when teams change. A reorganization that moves responsibilities should move code too. If it does not, the architecture describes a company that no longer exists.

Shaping teams on purpose

Conway's law can be used deliberately: decide the architecture you want, then organize teams to match it. If you want billing to be independent, create a team that owns billing end to end, ideally including its backend API.

This also sets a limit. The number of remotes should follow the number of teams that can own them. Ten remotes for three teams means most remotes have no real owner, and the overhead is paid without the benefit. Splitting too small is the first entry in common micro-frontend mistakes.

More in this section

• The real cost of micro-frontends
• Common micro-frontend mistakes and how to avoid them
• Micro-frontend readiness checklist
• Micro-frontend security: what changes and what to do