the forgotten constraint
every discussion about team structure eventually collides with the same wall: how much can a team hold in its head? team topologies treats this as a first-class design constraint — not a soft-skills footnote. cognitive load is finite. a team of eight doesn't have four times the capacity of a team of two; it has four times the coordination cost plus the same-ish attention for the actual work.
the framework borrows three categories of load from sweller's original work. you don't need to memorise the labels; you need to recognise what each one looks like when it's wrong.
- intrinsic the essential difficulty of the problem. rocket science is intrinsically harder than crud. you reduce this by hiring more skill, or by scoping the team to problems within its range.
- extraneous incidental friction — unfamiliar toolchains, confusing build systems, ci that takes 40 minutes, infra the team shouldn't have to own. this is the load team topologies says you can most cheaply reduce, usually by pushing it onto a platform team.
- germane the productive load of building mental models — learning the domain, the codebase, the customer. this is the load you want the team to carry. maximising headroom for germane load is the whole point of reducing the other two.
rule of thumb
a small team can hold one domain well. stretching a seven-person team across ten microservices, a customer-facing product, a legacy monolith, and their own ci is a mathematical impossibility — they'll appear to cope by dropping something quietly. the question is which something. usually: documentation, tests, then quality, then morale, then people.
score a team
below is a rough calculator. it doesn't replace judgement — the weights are deliberately coarse — but it does force a conversation. tick what applies to a team you know. adjust the team size. watch the verdict.
cognitive-load calculator
tick every row that reasonably describes the team. the score is total load; the verdict is load divided by team size — how much each person is effectively carrying.
what to do with a stretched team
- shed, don't add. the first move is always scope reduction. move one of the four services to another team. hand the pager to platform. retire a legacy surface. adding people to a stretched team usually makes it worse before it makes it better.
- pull extraneous load onto a platform. if the team is spending 30% of its week on ci, observability, or infra it shouldn't own, that's the load platform teams exist to absorb. if you have no platform team, extraneous load is the cheapest argument for creating one.
- split on a fracture plane. if the team owns two coherent flows, make it two teams. a fracture plane is a boundary where both halves can work independently for weeks without needing to coordinate. if you can't find one, the team is one team with too much scope — not two teams.
next: conway's law — why your org chart is already choosing your architecture, whether you like it or not.