Team Topologies: Teams Built for Flow, Not the Org Chart

Alexander records the first Code of Leadership episode with a guest who has spent his career somewhere between product and engineering management on infrastructure and platform projects. Stanislav declares himself a sceptic at once: a manager has little spare time, IT books lay their material out far too expansively, and discussions like this one deliver a book's core value without the reading. The participants date the book to 2019, a year after Accelerate on speeding up delivery, and note it was written by two consultants focused on DevOps and infrastructure. That bias, the guest warns, will colour the whole conversation: about what precedes delivery — development and quality management — the book says almost nothing. The shape is simple: three parts of three chapters, and the whole content, they joke, folds into one picture with four team types and three interaction modes.

Chapter one opens with the org chart: in a good company somebody has at least drawn it, in a mid-sized one you reconstruct it from Outlook signatures. It settles administrative matters such as signing off holidays but does not show who works with whom, especially as project, product and legal structures live beside it. Then comes the list of what obstructs the delivery flow: software whose cognitive volume exceeds what a team can hold; a tangle of matrix structures; painful yearly reorganisations; dependencies that cannot be cleared quickly; and, as the end point, teams whose motivation the org structure has destroyed. At the top sits Conway's law, and the guest notes that Conway spoke not about org design but about communication structure, which organisations then force into the boundaries of org units. The illustration is the DBA: a correction comes up in the conversation — a separate database person appears not when the model is complex but as soon as a database exists — and Stanislav then recalls an architect-DBA who prepared complex migrations by hand and alone held the rights to apply them.

Flipping the team structure over produces the familiar three-tier architecture, after which the authors propose the reverse manoeuvre: if software mirrors the communication structure, teams can be designed so that autonomous services come out at the end — low coupling between teams, high cohesion inside. The guest qualifies it: the lesson is how to go fast and independently rather than well, and quality management, reliability and security are left outside, because the book was written from a different time. The theory of part one closes with Dunbar's number: a person builds deep trusting relationships with about five people and mutual trust within a group of fifteen, from which the authors derive a limit on team size and the participants recall Amazon's two-pizza principle, plus a joke about meat toppings. Tuckman's model, Stanislav suggests, is best studied through Marvel films about assembling superheroes, to which Alexander replies that norming does not apply there: what norms, when one team member is a talking raccoon.

Part two starts with the classic chain in which some develop, others test and a third group operates, with context thrown over the fence at every arrow; the authors collapse the four boxes into a team aligned to the value stream. It used to be called cross-functional, but that term, the guest argues, misses the continuity of the flow; Alexander counters that such a team can be assembled out of anybody — a C++ developer, a designer and a potter — and the question is what idea they were gathered around. The picture about scale and engineering maturity genuinely broke them: the axis labels appear to be swapped. The guest reads maturity as the ability of teams to form temporary collaborations and fully own their product, Alexander as delivery and operations practice; he then walks through the authors' quadrant where, at large scale with weak practice, complexity is hidden in a platform, and holds that going deeper, into how platforms and SRE practice are arranged, was a mistake.

A complicated-subsystem team holds a complex component whose knowledge you do not want spread around: a time-series database engine inside a telemetry management system, say, where the product team cares about metric scenarios rather than how bytes are stored. A platform team hands over services rather than a component — deployment, monitoring, builds — and is internally arranged like a product team, with its own engineer-users and their stories, whereas a component team need not be self-sufficient or maintain what it wrote. The enabling team the guest met under that name for the first time: in his experience such expert groups were called a rapid-reaction team. The example both had seen is a Java performance team that joins a product team, reads the code together, finds needless serialisation and helps tune thread pools. Only very large organisations with strong core engineering can afford that, in the guest's experience; in startups and mid-sized companies he never met one. The guest adds that he mentally mapped familiar companies onto the model: DevOps fits well, security does not — however he turns it, the old Security Operations Center silo comes out, and both leave the question of trust in shifting left for a future discussion.

There are three interaction modes. Collaboration is the most expensive: responsibility boundaries blur, people must hold the neighbouring domain in their heads, and it fits only a short window while two teams beat down cognitive complexity together, after which it should stop. X-as-a-Service needs a fixed contract and a catalogue to request the service from, and it stumbles on multi-tenancy: teams without cloud experience never design a tenancy model and end up with overlapping data, and where isolation is poor everything slides back into collaboration. Facilitating is the enabling team, which, as Alexander jokes, inflicts good on you; the participants recall the solver archetype from the book Staff Engineer. Hence the guest's point about the word evolve: the movement is not towards complexity but towards cheaper modes. Both rate the change triggers highly, split into cognitive load, delivery speed and surplus dependencies. At the end both sum up: the model in the limit looks coherent, while the client stories are generic, without metrics or detail, and propped up by references — the last five to fifteen pages, by the guest's reckoning, are notes. Alexander recalls that he pulled the useful parts into a short retelling of about forty minutes' reading, and both suggest starting there.