Conway's law and team topologies

Draw the teams and you have drawn the system. Cut both along the work.

Before you read: predict

A chat app's code changed in 30 changes last quarter: 12 changed messaging (each touching the web client, the API and the message store), 10 changed presence (the web client, the API and the presence cache) and 8 changed notifications (the API and the push sender). Three teams will own the code from now on, and the next quarter's work looks the same.

Which split makes the fewest of those 30 changes need more than one team?

The 30-second version

A system ends up shaped like the communication structure of the organisation that builds it (Conway, 1968), so choosing teams is choosing architecture. Where two teams' parts meet, the two teams must agree. Cut the system so one team ships each common change alone, size each team for what it can hold, and name how teams interact.

Draw the teams and you have drawn the system. Cut both along the work.

How it works

Step 1 of 12

Conway's thesis. Organisations that design systems produce designs that copy their own communication structures (Conway, 1968).

In the kitchen

each company's line runs where its own surveyors and directors decided → a design copies its makers' structure (step 1)

Analogy: Two railway companies building lines that meet

In the age of steam, each company laid its own track to its own drawings.

On the railway	In the system
each company's line runs where its own surveyors and directors decided	a design copies its makers' structure (step 1)
where two companies' lines meet, the station, the timetable and the rail width must be agreed by both boards	an interface between two teams' parts (step 2)
one company built to a wider gauge; where it met a neighbour, passengers and goods changed trains	a boundary nobody negotiated becomes a hand-off in every journey (steps 2, 4)
a company that runs a whole route from the port to the city sells one ticket and times every train itself	a stream-aligned team (step 7)
a rolling-stock works builds and maintains the carriages every line runs	a platform team (step 8)
the bridge engineers who alone can design the viaduct over the estuary	a complicated-subsystem team (step 10)
an inspector who spends a month teaching a line's crews the new signalling rules	an enabling team, facilitating (steps 9, 11)
two companies merging to build one through-route under one board	reshaping the organisation for the system you want (step 6)

Breaks down when: track, once laid, stays for a century; a codebase can be reshaped in months once the teams change, and so it drifts back toward the teams if they do not.

Contrasting case: a single company that owns the whole network: no gauge break and no joint stations, but one board deciding everything, which slows as the network grows (step 3).

In real terms: before drawing services, ask which teams will own them, and cut the system so that the common change stays inside one team.

Examples, run for real

The change log is a labelled fixture: one term's changes as counted below, not data from any real company.

4.1 ExamHall EXH-4310: one change, three teams

ExamHall's code was owned by layer: web, API, data, and operations for the deploy pipeline. One term's 54 changes: 18 to the candidate experience, 14 to proctoring, 12 to grading and results (each touching its screen, API and store), 4 showing proctor flags on results, and 6 to the pipeline alone.

4.1 EXH-4310 by layer (web, API, data, ops) · 48 of 54 changes need more than one team · teams per change: candidate experience 3, proctoring 3, grading and results 3, proctor flags on results 2, deploy pipeline 1
4.1 MR !4610 by stream (candidate, proctoring, grading; platform runs the pipeline) · 4 of 54 · teams per change: candidate experience 1, proctoring 1, grading and results 1, proctor flags on results 2, deploy pipeline 1

Almost every change waited for three teams. MR !4610 regroups the same people into three stream-aligned teams, each owning its slice from screen to store, and a platform team running the pipeline (steps 7, 8). The 4 flag changes still cross two teams: an interface they agree on, collaborating until it settles (steps 2, 11).

4.2 Paths between people

4.2 possible paths, one group where anyone may talk to anyone · 6 people 15 · 12 people 66 · 24 people 276 · 24 as four teams of 6, two contacts each, whose eight contacts talk: 84

Count each pair once: a team's two contacts are already a pair inside their team. The restriction is not a loss: it is the structure the design will copy, so choose it (steps 3, 6).

4.3 Interfaces that cross a team

4.3 interfaces crossing a team boundary · by layer 9 of 10 · by stream 4 of 10: grading API to proctoring API, and 3 to the deploy pipeline

By layer, nearly every interface joins two teams; by stream, one interface joins two streams and three join a stream to the platform (steps 2, 8).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 6

A streaming service's encoding-ladder component chooses the bitrates for each title with a perceptual-quality model. Only three engineers, all video-signal-processing specialists, can change it safely. The TV-app and mobile-app teams call it to encode their titles.

Which type of team should own it?

Question 2 of 6

A payments-ledger company's platform team runs the deploy pipeline. The settlement team ships through it using the pipeline's docs and an online request form; the two teams meet only once a quarter to agree the pipeline's roadmap.

Which interaction mode is this?

Question 3 of 6

Two accessibility specialists join the checkout team for six weeks before an accessibility deadline. They review its pull requests, pair on the first fixes and teach the team to test with a keyboard and a screen reader. The checkout team merges every change and keeps running its own service; after the six weeks the two join the search team before its deadline.

Which type of team are the specialists?

Question 4 of 6

A chat company's 20 engineers work as one group in which anyone may need to talk to anyone. It splits them into four teams of five: inside a team anyone talks to anyone, and between teams only each team's one named contact talks to the other teams' contacts.

Counting each pair of people who may need to talk as one path, how many paths are there after the split?

Question 5 of 6

In a design round you draw a payments-ledger system as three services: accounts (account screens, accounts API, balances store, interest job, statements job), transfers (transfer screens, transfers API, transfer queue, fraud rules) and disputes (disputes console, case store). The three teams stay as they are: the Accounts team builds all of accounts, the Payments team builds the transfer screens, the transfers API and the transfer queue, and the Risk team builds the fraud rules and all of disputes.

The interviewer asks: "Two years on, with these teams, how will your drawn services have changed?" Which answer survives the next question?

Question 6 of 6

A video app has five services: the player calls the playback API and the catalogue; recommendations calls the catalogue and the licence check; the playback API and the catalogue each call the licence check. Team Red owns the player and the playback API, team Blue owns the catalogue and recommendations, and team Green owns the licence check. Each interface between parts built by two different teams is one those two teams must agree on.

How many of the six interfaces need such an agreement?

Go deeper

Pro tips

When asked to split a system, ask first how many teams will own the result, then cut it so that the common change stays inside one team. When: the row's typical question "How would you split this system across three teams?" or any microservices question (steps 1, 6, 7). Verify:
```
tip same 54 changes · cut along the four layer teams 48 need more than one team · cut along the three streams and a platform 4
```
Status: RAN.

Source

quote-check.mjs finds every passage below verbatim in its saved text. Valid as of 2026-10-15.

Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968, as published by the author: https://www.melconway.com/Home/Committees_Paper.html (conway-committees.txt). The row's first source. Quoted: "organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." · "If there is a branch, then the two (not necessarily distinct) design groups X and Y which designed the two nodes must have negotiated and agreed upon an interface specification to permit communication between the two corresponding nodes of the design organization." · "Elementary probability theory tells us that the number of possible communication paths in an organization is approximately half the square of the number of people in the organization." · "To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces." · "The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon." · "Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design." · "a design effort should be organized according to the need for communication." · "Speaking as a mathematician might, we would say that there is a homomorphism from the linear graph of a system to the linear graph of its design organization."
Team Topologies, Key Concepts: https://teamtopologies.com/key-concepts (tt-key-concepts.txt). The row's second source. Quoted: "Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain" · "Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams" · "Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities." · "Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed." · "Enabling teams temporarily boost skills in other teams, then move on." · "Complicated subsystem teams handle complex components requiring specialist knowledge." · "Platform teams create services that accelerate stream-aligned teams, removing complexity." · "Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)" · "X-as-a-Service: Consuming or providing with minimal interaction (low cost, clear boundaries)" · "Facilitation: one team helps and mentors another team" · "Each new tool, responsibility or domain your team is given taxes their mental bandwidth." · "The Stream-aligned teams are “You Built It, You Run It” teams. There are no hand-offs to other teams for any purpose."

The row's typical question "What is the inverse Conway maneuver?" is answered in step 6 from Conway's criterion; the name itself appears in neither fetched page, so no item keys on it.

Checked against the tools and docs as of 2026-10-15.

Predict first