How team interdependence breaks (and how to design around it)
How team interdependence breaks at scale—and how to design around it. A diagnostic on Dunbar’s number, the geometry of relationships, and team structure.
The illusion of independence
Steve was on the verge of a breakdown, and I didn’t see it coming.
He ran a team of thirty for me. Technically, he was brilliant — the kind of person who could juggle dozens of tasks. Also, he was the person I’d quietly pointed to as the model of culture in my department: warm, welcoming, the one who pulled new hires under his wing.
Indeed, it was 2020. His kids were home from school, the project was running through the screen of a laptop set up on a kitchen table, and Steve was the connective tissue holding thirty people together. From the outside, he looked like the same Steve — sharp on calls, patient with new hires, shipping updates on schedule. Of course, I knew the project had slipped. Still, I told myself he was handling it.
His wife is the one who called me.
By the time we spoke, Steve had been pulling all-nighters for months. Meanwhile, his marriage was on the brink. Not long after that call, he would end up in a treatment facility. Ultimately, he wasn’t failing for lack of effort or expertise. He was carrying a team — and a household, and a pandemic — that no single nervous system was built to carry.
Steve was fighting geometry.
Years before I met Steve, I’d had my own first lesson in interdependence. I bought a 1985 Dodge Omni — six hundred dollars, a color I called “Champagne Gold” — and thought it meant freedom. Then I tried to drive it to Boston and spent four hours bumper-to-bumper on I-93, surrounded by thousands of people chasing the same illusion. Independence holds up only until it collides with interdependence.
This is the daily reality of team interdependence. Our success depends on others meeting their commitments, just as theirs depends on us. We are inextricably tied to one another.
In college, that interdependence showed up in the ever-frustrating group project. Someone inevitably refused to do the work. The high achievers muscled through, carried the weight others wouldn’t, and still got the A. The pain was real, but temporary — the semester ended, you started new classes with new teammates, a fresh start.
Manageable, but temporary.
At work, there is no end-of-semester to lug to. If you carry what others should, you’re stuck with it for years.
And the problems are far more complex than textbook assignments. You need the expertise of others to find the right solution — not just to share the workload, but to see the full picture.
As teams grow, so does that interdependence. Every team’s output is limited not by how hard people work, but by the relationships that hold them together — or pull them apart.
That’s the central tension of this chapter:
How large can a team grow before team interdependence itself becomes unmanageable?
“Teams should be able to act with the same unity of purpose and focus as a well-motivated individual.”
That’s the aspiration. Steve’s team, and most teams I’ve watched, fall somewhere short of it. The question is why — and what to do about it.
The pain of team interdependence
“Almost everything worth doing, from marriage and parenting to business or politics, depends on cooperating with others, and therefore on exposing yourself to the emotional uncertainties of relationships.”
There are two types of information flowing through any relationship between two teammates:
- Relational information — the trust, empathy, and connection that build cohesion.
- Technical information — the data, insights, updates, and dependencies required to get work done.
Both matter. Relationships create the safety that lets people collaborate. Technical information helps build the mental maps the team uses to navigate to a solution together.
But both have limits. You’ve surely felt the overwhelm of managing — or even just participating in — a large group. That feeling of overload isn’t imaginary. It’s biological.
In 1992, anthropologist Robin Dunbar published a now-famous paper in the Journal of Human Evolution called “Neocortex Size as a Constraint on Group Size in Primates.” Observing baboons and chimpanzees, he found that they form large groups of 50–55 that band together to collaborate on the basic needs for survival: finding food, fighting off predators. When a group exceeds this limit, it becomes unstable and begins to fragment.[3]
But a large group, undifferentiated, would be full of conflict and competition. (You know how hard it is just to order pizza for a crowd. So much friction. So many strong opinions.)
To maintain stability, these primates form smaller, more intimate “grooming cliques” of two to five individuals. Within these cliques, conflict and competition are limited, trust deepens, and bonds often last a lifetime — even as membership in the larger group shifts.
These small cliques collaborate with one another inside the larger troop. Borrowing terms from nuclear physics, anthropologists call this dynamic a “fission–fusion society.”
Smaller groups temporarily fission (split apart) and then fuse (join up) with others for specific purposes — a hunting or foraging expedition, for example. When the mission is complete, the temporary coalition disbands, and each member returns to a stable core clique.
This pattern — alternating between intimacy and coordination — forms the social basis that strengthens the larger group.
The limit of group size, Dunbar argued, isn’t just a social phenomenon but a cognitive constraint tied to brain size. The neocortex determines how many social relationships an individual can track and maintain. As Dunbar put it, the size of the animal’s brain “places an upper limit on the size of the groups which any given species can maintain as cohesive social units through time.”
Extrapolating from primate data, Dunbar estimated that humans can maintain about 150 meaningful relationships. This figure became known as Dunbar’s number.
“The figure of 150 seems to represent the maximum number of individuals with whom we can have a genuinely social relationship, the kind of relationship that goes with knowing who they are and how they relate to us. Putting it another way, it’s the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar.”
He found historical examples of human communities clustering around that number — from early farming settlements in 5000 BC to modern company divisions and military units.[5]
Within those 150, he says, there is a maximum of ten to fifteen people in your inner circle with whom you can have a deeply empathic relationship. This is analogous to the chimpanzee’s grooming clique. Dunbar calls this inner circle a sympathy group.
“It is striking that groups of this size are common in situations where very close coordination of behavior is required: juries, the inner cabinets of many governments, the number of apostles, the size of most sports teams.”
Now translate that into a team context. Adding a single person doesn’t add one relationship. It adds many — each new member multiplying the web of connections and dependencies the group must manage.
The math of relationship complexity
The number of relationships in a group is defined by a simple formula:[7]
Consider this: when I got married, there was one relationship to manage — my wife and me. (You could argue there’s also the relationship between me and myself, but let’s keep the meta to the side.)
Then we had a child. Now there are three relationships: between my wife and me, between my wife and the child, and between me and the child.
Then we had a second child — now six relationships.
And now my daughters want a dog. Not everyone has the same attitude toward this idea.
I made this visualization to make it more obvious:
Each line represents a connection — a conversation, a decision, a potential miscommunication. Start with a team of five — how many relationships? Then slide to six. It doesn’t add one relationship; it adds five. For every n+1, you add n relationships. With every new person, the web tightens.
Now think back to Steve. The conventional wisdom is that a team should max out around ten. Steve’s team was three times too large. But measured by relationships, Steve’s team had nine times too many.
Small vs. Large Team Relationships
Comparing how the number of relationships grows as team size increases.
Anyone who’s tried to order pizza by polling five people has felt the pain of rapidly scaling interdependence. Add one strong opinion — someone insists on anchovies — and feel how it shifts.
When you add people, communication becomes heavier. There are more opinions, more people to keep up to date. And, as Dunbar shows, team interdependence stops compounding and starts fragmenting when the number gets too high.
Steve’s problem wasn’t personal effort. He was fighting geometry. But he was running a scope that genuinely required thirty people to deliver. So if small teams move fast and large teams tackle large missions, how do we take what we’ve learned from Dunbar’s chimpanzees and scale without collapsing under the weight of our own relationships?
Designing structure: divide and conquer
“The greatest improvements in the productive powers of labour, and the greater part of the skill, dexterity, and judgment, with which it is anywhere directed, or applied, seem to have been the effects of the division of labour.”
The world is full of examples of small teams that deliver. Apple’s Safari web browser was ported by just ten people. There are twenty-five names on the original iPhone patent.[9]
Amazon founder Jeff Bezos coined what he calls the “two-pizza team” rule. A team should be small enough to be fed with two pizzas — roughly seven to ten people. That works out to 21 to 45 relationships.
The “Two Pizza” Team Relationship Range
A team comprised of 7-10 people would have between 21 and 45 relationships.
But what happens when the work simply can’t be done by seven to ten people? Steve had thirty. I’ve managed 160. The Manhattan Project ran 180,000 people at its peak.
That’s where structure comes in. Team interdependence at scale doesn’t collapse for lack of effort. It collapses for lack of design.
Organizational design expert Amy Kates puts it this way: “You can’t design an organization without creating silos — but if you place them well, silos create focus.” The secret isn’t to eliminate silos. It’s to build connective tissue between them — processes and rhythms that preserve interdependence without chaos.
Reducing chaos through designed structure
This visualization shows how structure transforms complexity into clarity. Here, Steve’s team of thirty is organized into three sub-teams, each led by a single representative responsible for that group’s outcome. Those team representatives connect to a shared leader. This is a team of teams — the same structure Apple used to build the iPhone keyboard.
Instead of one tangled web of hundreds of relationships, each sub-team manages its own internal dependencies while the leaders handle cross-team coordination. The number of relationships the top leader must maintain drops from 435 to six.
Structure doesn’t slow communication. It makes it human again.
But you can’t just place these sub-teams arbitrarily. They have to be put in very specific places.
Conway’s Law
“Organizations which design systems are constrained to produce designs which are copies of the communications structures of these organizations. (Therefore) a design effort should be organized according to the need for communication.”
Architecture consultant Ruth Malan, building on Conway’s Law, observes:
“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
In other words: if elements of a system are supposed to communicate across an interface, and the team developing it does not communicate across that interface, the system will not integrate.
Consider a contractor building a house. The house is itself complex, and it has connections to systems outside it — power, water, sewer. Those systems are developed by teams outside the team building the house.
Now imagine the contractor never calls the power utility. What happens? The house never gets power. It can’t perform its intended function.
This proves Malan and Conway correct. The design of the system and the design of the team were at odds, and the structure of the team won.
What Steve’s team needed
Steve’s thirty-person team wasn’t a failure of will. It was a failure of team interdependence at scale — too many relationships for any single leader to hold, in a structure that didn’t yet match the work. The way out wasn’t to push harder. It was to design smaller, well-placed teams, and then to draw the connective tissue between them with intention.
How large can a team grow before interdependence itself becomes unmanageable?
Larger than ten — if you build the structure that lets the people inside it stay human to each other.
- [1]Bill Gates, Business @ the Speed of Thought: Succeeding in the Digital Economy (Grand Central Publishing, Kindle Edition), p. 261. ↩
- [2]Oliver Burkeman, Four Thousand Weeks: Time Management for Mortals, First Edition (Farrar, Straus and Giroux, 2021), p. 30. ↩
- [3]R. I. M. Dunbar, “Neocortex Size as a Constraint on Group Size in Primates,” Journal of Human Evolution 22, no. 6 (1992): 469–93. ↩
- [4]Robin Dunbar, Grooming, Gossip and the Evolution of Language, 6th print (Harvard University Press, 2002), p. 77. ↩
- [5]Robin Dunbar, Grooming, Gossip and the Evolution of Language, 6th print (Harvard University Press, 2002), p. 71. ↩
- [6]Robin Dunbar, Grooming, Gossip and the Evolution of Language, 6th print (Harvard University Press, 2002), p. 76. ↩
- [7]Standard combinatorial result for the number of pairs in a set of n elements: C(n, 2) = n(n−1)/2. ↩
- [8]Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations (Project Gutenberg, 1776). ↩
- [9]Ken Kocienda, Creative Selection: Inside Apple’s Design Process during the Golden Age of Steve Jobs, First Picador Edition (Picador, St. Martin’s Press, 2019), p. 251. ↩
- [10]Melvin E. Conway, “How Do Committees Invent?,” Datamation 14, no. 4 (1968): 28–31. ↩
- [11]Ruth Malan, in commentary on Conway’s Law as cited in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press, 2019). ↩