Monolith Decomposition Is a Team Topology Problem First

Most decomposition programs redraw the architecture and leave the org chart untouched. Then they wonder why the services stay coupled.

Almost every enterprise carrying a large monolith has a service-decomposition roadmap. Few have one that survives contact with the org chart. The roadmap names bounded contexts, draws clean service boundaries, and sequences the extractions. What it usually omits is the only variable that decides whether those boundaries hold: which team owns which seam, and whether that ownership maps to the architecture you just drew. Decomposition fails far more often as an organizational problem than as a technical one, and the failure mode is predictable.

The technical pattern for splitting a monolith is well understood. You front it with a routing layer, extract by bounded context, integrate through events, and retire the legacy paths on a committed schedule. We have written about that sequence elsewhere. This paper is about the part the architecture diagram cannot show you: the team structure that has to change in lockstep, because if it does not, the org chart quietly re-couples everything you separated.

Conway's law is not a metaphor, it is a constraint

In 1968, Mel Conway observed that any organization that designs a system will produce a design whose structure copies the organization's communication structure. Sixty years of software has not dented the observation. It is not a tendency or a risk. It is a constraint as reliable as latency. If three teams build a compiler, you get a three-pass compiler. If one team owns the order service and the payment service and the inventory service, you get three services that share a database, call each other synchronously, and deploy together. They are a monolith wearing a microservices costume.

This is why the most common decomposition outcome is the distributed monolith: services on paper, a single failure domain in practice. The team that built the monolith keeps building, now across repository boundaries instead of package boundaries. The coupling moves from compile-time to runtime, which is strictly worse. A change that used to be one pull request becomes a coordinated release across four repositories owned by the same eight people. We have watched a 14-month decomposition produce a system with 40 services and zero independently deployable units, because all 40 were owned by two teams that still planned, estimated, and shipped as one.

The contrarian framing we offer is blunt. The service boundary is a derived artifact. The team boundary is the real one. You do not get to choose your architecture and then staff it. You choose your team topology, and the architecture follows whether you intend it to or not. Teams that accept this design the org chart first and let the code fall into place. Teams that fight it spend two years discovering Conway's law the expensive way.

The inverse Conway maneuver, and where it overreaches

If the org structure determines the architecture, the obvious move is to invert the arrow: deliberately structure your teams to match the architecture you want, then let Conway's law work for you instead of against you. The technique has a name, the inverse Conway maneuver, and the DORA State of DevOps research program has repeatedly found that loosely coupled teams and loosely coupled architecture are among the strongest predictors of software delivery performance. The 2023 DORA report identified team independence, the ability to deploy and test without a tightly coupled handoff, as a primary driver of throughput and stability.

So far so good. Here is the counter-take we will defend, because the maneuver is routinely oversold. Reorganizing teams to mirror a target architecture only works when you already know the target architecture, and for a monolith you usually do not. The bounded contexts are not obvious from the outside. They emerge from running the system, watching where change clusters, and noticing which parts of the code change together. Reorganize the teams around a guessed architecture in month one, and you have hardcoded a wrong guess into the most expensive and slowest-to-change layer you own, which is people. We have seen this fail twice as badly as leaving the monolith alone, because now the wrong boundaries have political owners who will defend them.

The discipline is to sequence it. Discover the seams first using the existing code and traffic, validate them with a small number of extractions, then move teams to match the seams that proved real. Move the people last, not first, but commit to moving them. A discovered boundary with no team behind it decays back into the monolith within two or three quarters.

The four team types you are actually staffing

The most useful vocabulary for this work comes from the Team Topologies model, which names four and only four team types worth maintaining: stream-aligned teams that own a slice of business value end to end, platform teams that provide internal services the stream-aligned teams consume as a product, enabling teams that raise capability and then leave, and complicated-subsystem teams that own a part requiring deep specialist knowledge. Decomposition done well is the process of converting one large team that owns everything into a set of stream-aligned teams that each own a vertical, supported by a platform team that owns the routing, observability, and deployment substrate the strangler pattern needs.

The mistake we see most is extracting services along technical layers and staffing them the same way. A "data access team," an "API team," and a "front-end team" produce horizontal slices, and a horizontal slice gives you worse latency and the same coupling, because no single team can ship a feature without all three. Stream-aligned means vertical. The order team owns the order user interface, the order service, the order data, and the order on-call pager. That is the unit that can move independently, and independent movement is the entire point of decomposition.

Cognitive load is the constraint that decides how small the verticals must be. Team Topologies frames team size against the limits of what a group can hold in its head, and the practical number we use is that a stream-aligned team of 5 to 9 engineers can own roughly 3 to 5 services before context-switching tax eats the independence you bought. Past that, the team becomes a mini-monolith with the same internal coupling you were trying to escape. When a vertical grows beyond what one team can carry, the signal is to split the vertical, not to add a coordination layer on top of it.

Interaction modes are the part everyone skips

Naming team types is the easy half. The half that determines whether decomposition holds is how the teams interact, and Team Topologies names three modes: collaboration, where two teams work closely for a defined period to figure out a hard boundary; X-as-a-service, where one team consumes another's output with minimal conversation; and facilitating, where an enabling team helps another over a hump. The target end state for a decomposed system is X-as-a-service almost everywhere, because that is the interaction mode with the lowest communication overhead, and low communication overhead between teams is exactly what produces loose coupling in the code.

The trap is leaving teams in permanent collaboration mode. Collaboration is expensive and it is supposed to be temporary. Two teams in collaboration mode produce tightly coupled code by Conway's law, because they are communicating constantly, and constant communication is the precondition for shared structure. We tell clients to put a clock on every collaboration: a boundary that two teams are still collaborating to define after 8 to 12 weeks is a boundary in the wrong place. Either it belongs inside one team, or the interface between the two needs to be made explicit enough that the teams can switch to X-as-a-service and stop talking daily.

A regulated-industry wrinkle sits underneath all of this. When you operate under SOX or PCI-DSS, the team that owns a service also owns its audit evidence and its segregation-of-duties controls. A team boundary that splits a regulated workflow across two teams creates an audit seam, not just a technical one. Map the compliance boundaries onto the team boundaries early, in the first planning cycle, not during the controls assessment.

Sequencing the people and the code together

The order of operations matters more than any individual decision. We sequence decomposition programs as a tight loop rather than a phased plan, because the discovery of seams and the movement of teams have to inform each other.

First, instrument the monolith to learn where change actually clusters. Commit history and runtime call graphs tell you which modules change together and which talk to each other most; those are your candidate seams, and they are usually not the seams on the original architecture diagram. Second, stand up the platform team before the first extraction, so the routing seam and the uniform observability exist as a product from day one rather than being negotiated per extraction. Third, extract one vertical end to end with a single newly formed stream-aligned team, and treat that extraction as the test of whether the boundary was real. Fourth, only after the first vertical ships independently, replicate the team pattern across the remaining seams, moving people to match boundaries that have proven they hold.

The metric that cannot be gamed is the same one that governs the technical pattern: not services created, but independent deployments achieved. A service that still has to deploy in lockstep with three others has not been decomposed; it has been relocated. Track the number of teams that can deploy to production without coordinating with another team, and track it weekly. That number, not the service count, tells you whether the org chart has actually moved.

Where this is headed

Decomposition is not primarily a refactoring exercise, and the firms that finish treat it as an organizational redesign that happens to produce code as a side effect. The technology for splitting a monolith has been stable for a decade. The hard, slow, political work is moving the people so that Conway's law produces the architecture you want instead of the one you are trying to escape.

1. Map your current team structure against your current architecture and name the places where one team owns multiple intended services. Those are your re-coupling risks, and they are where the distributed monolith will form.
2. Instrument the monolith for change-coupling and runtime call patterns before drawing a single target boundary. Let the data nominate the seams.
3. Stand up the platform team first. The routing, observability, and deployment substrate is a product, owned by one team, not a per-extraction negotiation.
4. Extract one vertical with one stream-aligned team and prove it deploys independently before you reorganize anyone else.
5. Put a clock on every collaboration interaction and convert proven boundaries to X-as-a-service so the teams can stop talking and the code can stay loose.
6. Report progress as independent deployments achieved per team per week. If that number is not climbing, your services are services in name only.