Most engineering leaders manage headcount and deadlines. The book Team Topologies argues they're missing the variable that actually governs whether a team functions: cognitive load. A team, like a person, can only hold so much in its head at once. Load it past that limit and it quietly stops behaving like a team at all.
Key Takeaways
- Teams have a finite cognitive capacity, and exceeding it degrades performance (Team Topologies).
- Push a team past its limit and it stops behaving like a team, fragmenting into a set of individuals each siloed on an overloaded slice (Team Topologies).
- Overloaded teams lack the bandwidth to master their craft and pay constant context-switching costs (IT Revolution).
- Manage the number of domains a team owns, not only the number of people on it.
The Idea
In Team Topologies, Matthew Skelton and Manuel Pais make a claim that reframes team design: a team has a cognitive capacity, the same way an individual has a limit on how much they can hold in mind at once (Team Topologies). Every service a team owns, every domain it has to understand, every tool it has to operate, draws down that shared budget. Spread a team across too many domains and you blow the budget. Their blunt point about what happens next: past that limit, a team stops working as a team and fractures into a group of individuals, each siloed on their own overloaded slice, with no shared context left.
The Symptoms of Overload
Cognitive overload rarely announces itself. It shows up as symptoms leaders misread as motivation or skill problems: the team is always busy but slow, quality slips, nobody has time to improve anything because they're too busy keeping ten things barely alive, and onboarding a new person takes forever because there's simply too much to learn. Skelton and Pais point out that overloaded teams lack the bandwidth to pursue mastery and pay heavy context-switching costs (IT Revolution), the same tax we covered in context switching, scaled up to a whole team.
| Symptom | Often misread as |
|---|---|
| Busy but slow | Laziness or weak process |
| Quality slipping | Carelessness |
| Endless onboarding | Weak hires |
| No time to improve | Lack of initiative |
A Concrete Version
A six-person team owns the web app, the mobile backend, the billing integration, the internal admin tools, and the data pipeline, five domains. On paper it's staffed. In reality each person is the lone expert on one or two of those, nobody understands the whole, and every incident pulls the one person who knows that area away from their own work. The team is 100% busy and moving at a crawl. Split those five domains across two focused teams, each owning a coherent slice, and the same people suddenly have room to actually understand their area, and throughput jumps. Nothing changed but the load.
How to Manage It
Three moves keep cognitive load in check. First, limit the number of domains per team; if a domain is too big, split the domain into sub-domains rather than splitting one domain across teams (Team Topologies). Second, use platform capabilities to take undifferentiated work (deployment, observability) off product teams' plates, the argument for platform engineering. Third, treat "we own too much" as a real signal to narrow the team's scope or add a team, rather than telling people to work harder.
What This Means for Staffing
Cognitive load reframes a common hiring mistake. When a team is drowning, the instinct is to pile on more responsibility because "they're the experts," which deepens the overload. The better move is to narrow scope or add a focused team that takes a whole domain off their plate. When you add senior engineers, giving them clear ownership of a bounded domain, rather than a slice of everything, is what actually reduces the load, which connects to the team-size and ownership research. See available engineers.
Frequently Asked Questions
What is team cognitive load?
The total amount a team has to hold in mind to do its work, across all the domains, services, and tools it owns. Team Topologies argues teams have a finite cognitive capacity, and exceeding it degrades how they function.
What happens when a team is cognitively overloaded?
It stops behaving like a team and acts like a group of individuals, each siloed on their overloaded slice. Symptoms include being busy but slow, slipping quality, and endless onboarding.
How do I reduce a team's cognitive load?
Limit the domains a team owns (split large domains into sub-domains for separate teams), offload undifferentiated work to platform capabilities, and narrow scope or add a team instead of piling on more.
Isn't this just about team size?
Size matters, but load is about scope, how many domains and services a team must understand, not only how many people it has. A small team with one clear domain can outperform a larger one spread across five.
The Bottom Line
Team Topologies makes a case worth taking seriously: cognitive load, not headcount, governs whether a team functions. Load a team past its limit and it fractures into overloaded individuals, busy and slow. Manage the number of domains a team owns, give people clear bounded ownership, and split scope before you split focus.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
