Delivering one customer outcome requires six teams. What is that telling you architecturally and what would you change?

What is being tested

Whether you recognise functional alignment and know that the fix is organisational as well as architectural.

What it tells you

The organisation is aligned to function, and the value stream crosses it repeatedly.

Six teams means at least five handoffs, five queues, five sets of priorities to negotiate, and a delivery time dominated by coordination rather than by work. Typically under 10% of elapsed time is actual work.

Architecturally it also tells you something specific: the system boundaries do not match the domain boundaries. If they did, one team could deliver a customer outcome. The fact that six are required is evidence that functionality which a customer experiences as one thing is scattered across six components — which is a cohesion failure, not a coupling one.

What to change

1. Establish where the work actually waits. Map the stream and record queue time at each crossing. The constraint is usually one team through which everything passes — a database team, a security review, a shared platform.

2. Realign teams to streams. A stream-aligned team owns a customer outcome end to end and can deliver without waiting for anyone. This is the structural fix, and it usually implies realigning the systems too, because Conway's Law will otherwise pull them back.

3. Convert the remaining crossings into self-service. Some capabilities genuinely should be shared — infrastructure, identity, data platform. Those become platform teams providing self-service capability, not teams performing work on request. A platform team that takes tickets is a functional team with a new name, and the value stream still crosses it.

4. Merge components that always change together. If two services are always modified for the same features, the boundary between them is in the wrong place, and merging is a legitimate and under-used move.

The sequencing question

Do you change the architecture or the organisation first? Usually the organisation, because Conway's Law means the architecture will follow whatever the organisation is — so changing the architecture without changing the teams produces a design that will be fought by gravity for its whole life.

Realigning teams first, then letting the boundaries move, is slower to start and far more durable.

What a strong answer adds

Naming cognitive load as the constraint on how far this can go. A stream-aligned team can own only so much, which is why platform investment is not optional in this model — without it, autonomy is just isolation and each team is solving infrastructure problems from scratch.