Coordination Tax

When services are split by function (onboarding, catalogue, pricing, fulfilment) but work arrives by journey (bring a supplier live with their catalogue and negotiated prices), every feature becomes a multi-team coordination problem: several backlogs, several pipelines, a release sequence and a distributed debugging session.

This cost is structural. No amount of process improvement removes it, because process is what you add when the structure is wrong.

Why it matters

The tax is invisible in any single feature — each one just takes a bit longer and needs a meeting — and enormous in aggregate. It is also self-concealing: organisations respond by adding coordination roles, which makes the symptom manageable and the cause permanent.

Implementation patterns

Only two fixes actually address it:

• Change the organisation to match the desired architecture (the Inverse Conway Manoeuvre): form stream-aligned teams owning a journey end to end and let boundaries follow. Effective, slow, political, and usually beyond an architect's authority.
• Change the architecture to match the organisation: if the functional split is genuinely right for the business, merge into fewer, larger services each owned outright. Consolidation is a legitimate architectural improvement when the split produced coordination rather than independence.

Diagnostics worth running: how many teams must change for a median feature · how many services must deploy in a fixed order · how many incidents required more than two teams in the call.

Industry example

A B2B marketplace such as Moglix, where supplier onboarding, catalogue ingestion, negotiated pricing and fulfilment were separate services owned by separate teams, finds that the single most common business event — onboarding a supplier — crosses all four. Every meaningful feature is therefore a four-way negotiation, and the observable symptom is that delivery slows as the platform matures rather than speeding up.

Failure scenarios

• The third option: adding a programme manager, a release train and a shared roadmap, which institutionalises the tax.
• Splitting further in response to slowness, on the theory that more independence is better, which multiplies the coordination surface.
• Boundaries drawn by technology (a "database team", a "queue team") rather than by ownership of an outcome, which guarantees every feature crosses all of them.
• Treating consolidation as a career-damaging retreat, so the correct fix is never proposed.

Trade-offs

Consolidating services reduces coordination and increases blast radius: one deployable, one failure domain, and any genuinely independent scaling requirement is lost. That trade is favourable when the services shared a release cadence anyway — which, if every feature needs all of them, they did.

The honest test is independent deployability. A boundary that delivers it is earning its cost; a boundary that does not is pure overhead, whatever the diagram says.

Interview question

"Your four services each need to change for almost every feature. Argue for merging them. Then argue against. What evidence would you collect before deciding, and what would change your mind?"