Teams and architecture
An architecture is built, run and changed by teams, and the shape of those teams leaks into the shape of the software whether anyone plans it or not. Architects who ignore this draw services that no team can own, or boundaries that every change has to cross. Architects who use it design teams and systems together, so most changes need one team, one deployment and no meetings.
1. The idea
Conway's law
Mel Conway, 1968: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Three teams split by layer (front end, back end, database) produce a three-layer system where every feature crosses all three. Two teams that rarely talk produce two systems with a thin, awkward interface between them.
The reverse (or inverse) Conway manoeuvre uses the law on purpose: decide the architecture you want, then shape teams to match, so the communication structure pulls the system in the right direction instead of fighting it.
Team Topologies: four team types, three ways to interact
Matthew Skelton and Manuel Pais' Team Topologies (2019) gives a small vocabulary that most organisations now use.
| Team type | What it does | Architecture it pairs with |
|---|---|---|
| Stream-aligned | Owns a flow of work for one part of the business, end to end: build, run, change | A bounded context or service it fully owns (Module 08a) |
| Platform | Builds an internal product (deployment, observability, data stores) that stream teams use as a service | Shared infrastructure behind a self-service interface |
| Enabling | Experts who coach stream teams in a new skill for a while, then leave | No component of its own |
| Complicated subsystem | Owns a part that needs rare expertise (a pricing engine, video encoding, a model) | A component with a clear interface |
Teams interact in one of three modes: collaboration (working closely together for a limited time to discover something), X-as-a-service (one provides, the other consumes, with little talking) and facilitation (one helps the other learn). Choosing the mode on purpose, and changing it as things settle, is part of the design.
Cognitive load: the real limit on team size
A team can only hold so much in its head. Team Topologies borrows three kinds of load from psychology: intrinsic (the difficulty of the domain itself), extraneous (friction from the environment: hand-written deploy scripts, five dashboards, unclear ownership) and germane (the useful learning about the business). The aim is to remove extraneous load, so that capacity goes to the domain. It recommends stable teams of about five to nine people; past that, trust and communication start to break down.
2. How it works
One change, two organisations
Marketing wants a "gift message" field at checkout. Watch the same change travel through teams split by layer, then through one stream-aligned team.
Interaction modes change over time
A platform team builds a new deployment pipeline with one stream team, then offers it to everyone. An enabling team spends a few weeks teaching tracing, then moves on.
3. Try it yourself
Design the organisation, watch the lead time
A product with three areas (checkout, catalogue, delivery). Pick how engineers are organised and how many there are. A typical feature needs three days of work; every hand-off between teams waits about three days in the next team's queue. The numbers are a simple model to show the shape of the effect, not a forecast.
4. Trade-offs
Stream-aligned vs specialist teams
Stream teams deliver without hand-offs, but each needs a spread of skills and can duplicate work. Specialist teams build deep skill and consistent practice, and every feature queues between them.
Platform vs do-it-yourself
A platform removes extraneous load from every stream team; it also needs product thinking, a roadmap and its own team. Start with the "thinnest viable platform": a wiki page and a template can be enough at first.
Collaboration vs X-as-a-service
Collaboration is fast for discovery and expensive to sustain: both teams' work slows. Move to X-as-a-service once the interface is understood.
Reorganise vs re-architect
Changing team boundaries is quicker than changing system boundaries, and the system follows over months. Change both together where you can; changing only one leaves them fighting.
5. In real projects
Map teams onto the architecture diagram. Colour each component by owning team. Components with no owner rot; components with three owners stall; changes that routinely need four colours point to a boundary in the wrong place.
A team API. Each team publishes how to work with it: what it owns, its services' interfaces and SLOs, how to request changes, its on-call and its preferred interaction mode. It's the human counterpart of a service contract (Module 25).
Platform engineering has become a discipline of its own: internal developer platforms with templates, golden paths for deployment, and self-service infrastructure, run as a product for internal customers. Its success measure is stream teams' lead time and cognitive load, not the platform's feature count.
Say it in the interview
- "How would you split this system?" Along bounded contexts that one stream-aligned team each can own end to end, with a platform team providing deployment and observability as a service. Conway's law means the team lines and service lines should match.
- "Why are features slow here?" I'd count the teams and hand-offs per feature. If most changes cross three teams split by layer, the fix is organisational as much as technical.
- "How big should a service be?" No bigger than one team of five to nine people can fully understand and run; cognitive load is the limit, not lines of code.
- Twenty microservices for a team of six.
- Front-end, back-end and database teams, with "slow delivery" as the complaint.
- A platform team that's really a ticket queue.
6. Remember it
How this hook works: what "the kitchen shapes the dish" means
What the slogan means, phrase by phrase
- "The kitchen"
- The organisation: team boundaries, communication paths and hand-offs.
- "shapes the dish"
- Conway's law: the system's structure copies the organisation's communication structure.
Why this picture fits: a kitchen organised by station produces dishes that queue at every station; one organised by dish, with a shared prep kitchen, serves straight through.
The story → the concept
| The kitchen | The organisation |
|---|---|
| A cook per station | Teams split by technical layer |
| A cook per dish | Stream-aligned teams |
| The prep kitchen | A platform team, consumed as a service |
| A visiting pastry chef who teaches | An enabling team |
The trap it saves you from
Drawing service boundaries that cut across team boundaries, and then wondering why every change needs a meeting.
7. Common mistakes
8. Design exercise (30 minutes)
- Colour the diagram (10 min). Draw a system you know and colour each component by owning team. Mark unowned and multiply-owned components.
- Trace three features (10 min). For three recent features, count the teams involved and the hand-offs. Where do they cluster?
- Redesign (10 min). Propose team types and interaction modes that would make the most common change need one team. What would have to move in the architecture to match?
9. Self-check quiz
What does Conway's law say?
What is the reverse Conway manoeuvre?
Which team type offers deployment and observability to other teams as a self-service product?
Hand-written deploy scripts and unclear on-call rules add which kind of cognitive load?
Which of these suggests a boundary in the wrong place?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| Team Topologies key concepts | 15 min | The four team types and three interaction modes from the authors. |
| Conway's Law (Mel Conway) | 10 min | The law in its author's words, with a link to the 1968 paper. |
| Conway's Law (Martin Fowler) | 10 min | Why it matters for microservices, and the inverse manoeuvre. |
| Team Topologies book notes (Dan Lebrero) | 20 min | A chapter-by-chapter summary, including cognitive load and team size. |