There is a sentence in Team Topologies that most readers skate past on the way to the diagrams, and it is the one that matters most this year. Size the software to the team, never the reverse. One complicated domain per team. When the software outgrows what the team can hold, split the software.
Read that against what has happened to your codebase since 2024. The software grew. The team did not. Nobody made a decision and nobody proposed a change to the operating model. The rule broke from a direction Matthew Skelton and Manuel Pais had no reason to anticipate when they published the first edition in 2019.
Conway appeared in this series during Deciding, for the claim that an organisation ships its communication structure. This article picks up what two practitioners built on top of that observation, and what happens to their construction when a large share of the code is written by something that has no place on the org chart.
1. From an observation to a manoeuvre
Conway’s 1968 paper made a descriptive claim. A system’s design copies the communication structure of the organisation that built it, because the interfaces people can negotiate are the interfaces they have conversations across.
Skelton and Pais turned the description into an instruction, and the move is the reverse Conway manoeuvre. If your architecture will end up mirroring your team structure whatever you do, then decide the architecture you want and build the team structure that produces it. Stop drawing target architectures and start drawing target org charts, because only one of those two things is under your control.
Their vocabulary is four team types and three interaction modes, and its value is that it is small enough to hold in a meeting. Stream-aligned teams own a flow of change to some part of the business. Platform teams reduce what stream-aligned teams have to know. Enabling teams raise capability and then leave. Complicated-subsystem teams exist where genuine specialism is unavoidable. The modes are collaboration, self-service, and facilitating, and the discipline is that a pair of teams should be in exactly one mode, deliberately chosen, and should change it deliberately rather than by drift.
The second edition arrived in September 2025 with new case studies. The framework has become the default vocabulary for engineering org design in large organisations, which is worth noting mainly because default vocabularies stop being examined.
2. The constraint underneath all of it
The four types are not the theory. Cognitive load is the theory, and everything else is a consequence.
The idea comes from John Sweller, who distinguished the intrinsic difficulty of the material, the extraneous difficulty added by how it is presented, and the germane effort that actually builds understanding. Their application is a constraint on org design: a team can own only as much domain as it can hold in its collective head. Draw the boundary past that line and you have not created ownership. You have created a name on a wiki page.
This is where the sizing rule comes from, and it is worth stating in the direction they state it. The team is the fixed thing. The software is the variable. When a domain grows past what a team can carry, the answer is to split the software, not to add people to the team, because adding people raises the coordination cost faster than it raises capacity.
Notice that Ousterhout named the same quantity two articles ago from inside the code. For him it is what a developer must hold to make a change safely. Skelton and Pais measure the same quantity at the scale of a team, and use it to decide where boundaries go. Two disciplines, one constraint, arrived at independently.
3. Which direction the rule broke
Now put generation into the model, and notice that it attacks the sizing rule from the side nobody defends.
The intended failure mode is a domain that grows because the business asked for more. That is visible, budgeted and argued about in a room. What is happening instead is that the volume of code inside an unchanged domain boundary has risen sharply while the team roster has not moved. The domain looks the same on the diagram. The amount that must be held to change it safely has gone up, and quite a lot of it was written by an agent, at speed, by somebody who read the diff quickly.
Three responses are available, and only three. Split the software, which is the answer the book gives. Narrow the domain, which means giving something away and is therefore politically expensive. Or accept shallow ownership, in which the team’s name stays on the service and its actual grip on the service quietly weakens.
Almost every organisation is taking the third option, and almost none has decided to.
There is also an uncomfortable dependency between this remedy and the last article but one. Splitting the software is only available if there is something to split along, which means the uses relation has to be a hierarchy rather than a tangle. Parnas’s loops and Skelton’s sizing rule meet here in an unpleasant way. Where generated code has accumulated dependencies nobody drew, the Team Topologies remedy is unavailable in exactly the situations that call for it.
4. The org chart has non-human nodes on it now
Conway’s law does not care whether the communicating parties are people.
Suppose a stream-aligned team’s real interface to a domain runs through an agent, and the agent’s context is a directory of markdown files somebody wrote in March. That arrangement is now part of the communication structure, and the architecture will come to reflect it. Whatever the agent finds easy to attach to is where things will attach. Whatever the agent has no visibility of will drift.
Skelton has been direct about this in his 2026 talks, and his framing is bounded agency. Organisations that had already learned to give humans clear, limited, well-supported autonomy turn out to be well placed to give agents the same thing. The problem has the same shape either way: what may this party do, what may it reach, and through which interface. He is explicit that agents should not have unbounded access to data and resources, which is the platform argument restated for a new kind of consumer.
Which makes the platform question sharper than the framework originally posed it. A platform justifies itself by the cognitive load it removes from stream-aligned teams and by nothing else. If your agents reach around the platform and touch whatever they like, you do not have a platform. You have a set of conventions and a strong hope, and Skelton’s vending-machine test applies unchanged: capabilities should be available through a clear self-service interface, not through a ticket and a favour.
5. What is being claimed, and by whom
A good deal is currently being asserted about how the four types change under AI, and it is worth separating the sources.
The community claims run roughly like this. Stream-aligned teams shrink towards three to five people. Complicated-subsystem teams dissolve because agents absorb specialist implementation. Enabling teams pivot towards context engineering and tool evaluation, and platform becomes the highest-return investment in the organisation. Every one of these is plausible. None of them is yet supported by evidence I would put in front of a board, and they come from commentators rather than from Skelton and Pais, who have been noticeably more careful.
The authors’ own claim is narrower and stronger. The principles were never about humans in particular. They were about any system trying to build and maintain software under a limit on what can be held at once, and that limit does not disappear because some of the holding is being done by a model. Cognitive load is indifferent to what kind of mind is being overwhelmed.
So the useful question for a leader is not which team type is obsolete. It is whether your teams still own what they are named after, and the sizing rule gives you a way to find out that does not depend on anybody’s opinion about the future.
The next articles move to measurement, which is where all of this either shows up in numbers or does not.
Placement: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Conway returns here on the Interaction lever, which asks how teams, components and agents relate. In Deciding his law was a warning about what a structure would produce; in Building it is a report on what it did. The Build Is the Test opens this stretch of the argument.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Ask a team to draw its own domain, and see whether it can.
Take one stream-aligned team. Give them a whiteboard and twenty minutes with no manager present, and ask them to draw everything they own: services, jobs, data stores, integrations, the lot. Then ask each person privately to mark the parts they could change safely on their own next week.
Two numbers come out. The size of the domain, and the fraction of it any individual can actually act on. The gap between them is your cognitive load overrun, and it is the number Team Topologies says should govern your org design.
Then ask when each part was last substantially changed, and by whom. Suppose a meaningful share of the domain was generated in the last year and nobody who works on it marked it as safe to change. That team no longer owns the service in any sense that will hold up at two in the morning. It owns the name.
Three responses exist and you must pick one out loud: split the software, narrow the domain, or say plainly that you are accepting shallow ownership and why. The third is a legitimate choice for a short period. It is not a legitimate accident.
Further Reading
Matthew Skelton and Manuel Pais: Team Topologies (second edition, September 2025). Short, practical, and unusually honest about its own limits, which is rarer in this genre than it should be. The site carries a readiness survey and the new case studies.
Matthew Skelton: Team Topologies as the infrastructure for agency with humans and AI (2026). The authors’ current position on agents, and considerably more restrained than most of what is being written around them. The slides are worth a scroll on their own.
Melvin Conway: How Do Committees Invent? (1968). Free on Conway’s own site, six pages, and it says more than the one line everybody quotes from it.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.