A B2B marketplace splits into supplier-onboarding, catalogue, pricing and fulfilment services. Eighteen months later every meaningful feature requires all four teams. What does Conway's Law say happened, and what are the two available fixes?

The diagnosis

The services were drawn along functional lines while the work arrives along customer-journey lines. Onboarding a supplier with their catalogue and negotiated pricing is one business event that crosses all four boundaries, so every feature becomes a four-team coordination problem with four deployment pipelines and a distributed debugging session.

Conway's Law is usually quoted as a warning that systems mirror organisations. The useful form is the inverse: if your system's boundaries do not match how work arrives, you will pay a permanent coordination tax, and no amount of process improvement removes it because the cost is structural.

The two fixes

Change the organisation to match the desired architecture (the Inverse Conway Manoeuvre). Reorganise into stream-aligned teams that own a customer journey end to end — "supplier lifecycle" owning onboarding through first order — and let the service boundaries follow. This works and it is slow, political, and outside most architects' authority.

Change the architecture to match the organisation. If four functional teams is genuinely the right structure for the business, then a four-service split along the same lines is wrong, and merging into fewer, larger services that each team can change independently is an improvement — even though it reads as a retreat.

The mistake worth naming

The third option teams actually take is neither: keep both structures and add coordination — a programme manager, a synchronised release train, a shared roadmap. That treats the symptom, institutionalises the tax, and makes the misalignment permanent because now there is a role whose job is to absorb it.

Consolidating services is a legitimate architectural improvement when the split produced coordination rather than independence. Independent deployability is the whole point of a service boundary; a boundary that does not deliver it is pure cost.