A platform company's teams are organised by technical layer - frontend, backend, database, infrastructure. What problems does this create, and what is the alternative?

The problems

1. Every feature requires every team. A user-visible change touches frontend, backend and database, so it becomes a coordination exercise across three teams with three backlogs and three priorities. Lead time is dominated by handoffs and queueing, not by work.

2. Nobody owns the outcome. Each team delivers its layer correctly and the feature is late or wrong. There is no single team accountable for the user experience.

3. Conway's Law produces layered architecture. Teams communicate through interfaces, so the system will have interfaces at the team boundaries — which is why layer-organised teams produce layer-coupled systems where a single change spans all layers.

4. Specialists become bottlenecks. The database team is a queue for everyone, and its utilisation determines everyone else's lead time. A fully-utilised specialist team maximises its own efficiency and maximises the queue in front of it.

5. On-call is misaligned. Nobody owns a user journey end to end, so incident response requires assembling several teams.

The alternative

Stream-aligned teams owning a slice of user value end to end — frontend through data — with the specialists reorganised as:

• Platform teams providing self-service capabilities that stream-aligned teams consume without coordination. Infrastructure becomes a product with an interface, not a queue.
• Enabling teams that work alongside stream-aligned teams temporarily to build capability, then leave — the answer to "we still need deep database expertise" that does not recreate the bottleneck.
• Complicated-subsystem teams for the genuinely specialist components that cannot reasonably be owned by a stream team.

What must be true for it to work

• Stream teams need the skills to be autonomous, which requires investment, and in the transition they will be worse at some things than the specialists were.
• The platform must be genuinely self-service. A platform requiring a ticket is the old bottleneck with a new name.
• Ownership must include operations. A team that builds and does not run has no feedback loop.
• Boundaries drawn around capabilities, not process steps, so they survive product changes.

The honest caveat

Layer-organised teams are not always wrong. For a small organisation, or where one layer is genuinely specialised and stable, they can be efficient. The failure appears when feature delivery consistently requires all of them, which is the signal that the boundaries are cutting across the flow of value rather than along it.