Every feature needs the frontend, backend, database and QA teams. What does Conway's law suggest, and what would you change?

Layered teams produce layered hand-offs. Move towards stream-aligned teams that own a flow end to end, with a small platform team providing shared capabilities as a service.

Name the four Team Topologies team types and the three interaction modes.

Team types: stream-aligned, enabling, complicated-subsystem, platform. Interaction modes: collaboration, X-as-a-Service, facilitating.

How do you know a team's cognitive load is too high?

They can't confidently explain, operate and change everything they own: frequent incidents in rarely touched systems, slow onboarding, constant context switching between unrelated domains. Split or move ownership.

Team Design and Cognitive Load — The Engineering Manager Handbook (Development Manager)

Scenario

Example organisation: the 40-engineer organisation has a frontend team, a backend team, a database team and a QA team. Every feature needs all four. Lead times are long, hand-offs constant, and every team says it's overloaded.

What you see on the team

Features waiting in queues between teams.
Many cross-team meetings to coordinate simple changes.
Teams owning too many unrelated systems.
No team able to deliver a customer-facing change alone.

The common mistake

Organising teams by technical layer or skill and adding coordination when it doesn't work, instead of organising around the flow of work with ownership a team can actually handle.

Why it happens

Grouping by skill feels efficient and matches how people were hired. But Conway's law means the system's architecture follows the communication structure: layer teams produce layered hand-offs. Team Topologies proposes four fundamental team types — stream-aligned, enabling, complicated-subsystem and platform — and three interaction modes — collaboration, X-as-a-Service and facilitating — with team cognitive load as a design constraint (Team Topologies key concepts).

The playbook

Map the flows of work (customer journeys, business domains) and the systems each needs.

Make most teams stream-aligned: each owns a flow end to end (UI, API, data) and can ship independently.

Use other team types sparingly:

Platform teams provide internal products (deploy pipeline, observability) consumed as a service;
Enabling teams help stream-aligned teams adopt new capabilities, temporarily;
Complicated-subsystem teams own parts needing deep specialist knowledge (e.g. a pricing engine).

Check cognitive load: can the team hold its systems in their heads, operate them and change them safely? If not, split ownership or move systems.

Define interaction modes explicitly between teams, and expect them to change (collaboration during discovery, X-as-a-Service once stable).

Size teams at roughly six to eight people in steady state (Larson).

What to say

Proposing a reorganisation:

"Today every checkout change needs four teams. I'd like to try two stream-aligned teams — checkout and account — each owning their UI, API and data, with the database specialists forming a small platform team that provides tooling as a service. We'd review in a quarter using lead time and hand-offs per feature."

Trade-offs

Stream-aligned teams may duplicate some work and need broader skills; platform teams and shared standards reduce duplication.
Specialists spread across teams can feel isolated; communities of practice help.
Reorganisations are disruptive; change in steps and measure the effect.

Signals it's working

Most features are delivered by a single team.
Lead time and hand-offs per feature drop.
Teams can explain what they own and operate it confidently.
Interactions between teams are explicit and change deliberately.

Key points

Conway's law: system structure follows team communication — design teams on purpose.
Make most teams stream-aligned; use platform, enabling and complicated-subsystem teams sparingly.
Treat cognitive load as a design constraint.
Make interaction modes explicit and review the design with flow metrics.