Leadership accepts that the current three-layer team structure is producing a tightly coupled system, and reorganises into cross-functional product teams in one step. What happens over the following six months?

What happens in month one

The architecture does not change, and the teams now own slices of a system that was not built in slices. Each new product team is handed responsibility for a customer journey that runs through code owned, until last week, by three separate groups. The immediate effects:

• Every team touches every component. Ownership is nominal, because the code is still layered. Merge conflicts, competing changes and unclear review responsibility rise sharply.
• Deep expertise is diluted. The three engineers who understood the data layer are now in three different teams with three different backlogs, and the first difficult database problem finds them all busy.
• On-call gets worse before it gets better. Teams are paged for failures in code they did not write, in a part of the stack they have not yet learned.

Months two to four: where it amplifies

The gap between nominal and real ownership is where the damage concentrates. Without a deliberate programme to carve the system along the new boundaries, teams optimise locally inside a shared codebase, which produces exactly the coupling the reorganisation was meant to remove, now with less shared understanding.

The second amplifier is organisational. A reorganisation resets every informal channel: who to ask, who reviews what, which decisions need whose agreement. That knowledge took years to build and is rebuilt over quarters, during which decision latency rises.

What makes the difference

The manoeuvre works when it is paired with structural work, sequenced deliberately:

1. Choose boundaries from the business, not the current code — the journeys, capabilities or customer segments the teams will own.
2. Assign provisional ownership with an explicit interim rule: shared components keep a named maintainer and a review requirement until they are genuinely split.
3. Fund the carve-out. Extracting the first bounded piece is real engineering work, and if it is not in the plan, the structure and the system stay mismatched indefinitely.
4. Keep an enabling group for the deep skills — data, performance, security — so the diluted expertise is available to every team rather than lost to one.
5. Sequence, do not big-bang. One journey at a time, with the old structure intact around it, is slower on paper and far more likely to finish.

What the user sees

Nothing, for several months, which is the political risk: the costs of a reorganisation appear immediately and the benefits appear after the structural work, so the change is frequently judged at its worst moment and sometimes reversed then.

What would have to be true for it to self-heal

Only that the system was already decomposable along the new boundaries. If the architecture already had seams where the new teams are drawn, the reorganisation is cheap and fast. If it did not, the structure is a bet that teams will create the seams, and that bet needs funding, sequencing and roughly two to four quarters of patience.

When not to reorganise at all

When the coupling is in the data model rather than in the code. Teams cannot own independently what shares one schema with cross-cutting transactions, so the reorganisation produces friction without independence. Fix the data boundaries first, or accept a structure that matches the system you actually have.