One of the main reasons we split large monolithic teams into smaller service teams is to manage Cognitive Load — a concept borrowed from psychology that describes the total amount of mental effort a person or team can sustain at once.
The Limit of Headspace
Just as a CPU has a finite number of cores and a finite amount of cache, a team has a limit on how much software complexity it can hold in its collective head. This isn't a criticism of engineers — it's a fundamental constraint of human working memory.
If a team owns "The Entire Monolith" (millions of lines of code, dozens of subsystems, hundreds of database tables), the cognitive load exceeds what any team can manage effectively. The consequences are predictable:
- Fear of changing code: "I don't know what this touches, so I won't touch it."
- Slow onboarding: New engineers take 6+ months to become productive.
- Cascading bugs: A change in one area breaks something seemingly unrelated because nobody understood the dependency.
- Defensive architecture: Engineers add abstraction layers not for good design reasons, but to protect their area from other teams' changes.
Matching Team Size to Software Size
When performing the Inverse Conway Maneuver, a key design goal is to size each software boundary (the Service) to fit within the cognitive limit of the team (the Squad). Team Topologies formalizes this as a primary constraint: team cognitive load should be the primary input to service boundary decisions, not technical convenience.
A practical rule of thumb: a "Two-Pizza Team" (6–10 people) should own a service small enough that any member of the team can understand the whole thing within a few weeks of joining. They should be able to answer: "What does this service do? What are its inputs and outputs? What are its failure modes?" without needing to consult another team.
If the software grows too complex for the team to hold in their heads, you have two options: reduce the scope of the service, or split the team and the service simultaneously. Splitting the team without splitting the service (or vice versa) just recreates the original problem in a new form.
A common staff-level interview question is: "How do you decide where to draw service boundaries?" The weak answer focuses on technical criteria (database tables, API endpoints). The strong answer leads with cognitive load: "A service boundary should be drawn where a team can own the entire service without exceeding their cognitive capacity. Technical criteria like data ownership and failure isolation are secondary — they validate the boundary, they don't define it."