How does team cognitive load act as a constraint on architectural boundaries, and what do you do when a team is overloaded?

## What cognitive load means here Cognitive load theory (John Sweller) distinguishes three kinds of mental effort. *Team Topologies* applies it at team scale: - **Intrinsic load** — effort inherent to the task and required skills: knowing the language, the framework, how to test, how the domain works. Reduced by training, coaching, and hiring, not by tooling. - **Extraneous load** — accidental effort caused by how work is organized: hand-rolled deploy scripts, flaky environments, undocumented internal tools, ticket queues, five different CI systems. This is pure waste and the first thing to attack. - **Germane load** — effort spent on the valuable thinking: understanding the business domain, designing the model. This is what you want maximized. A team's total capacity is roughly fixed. Every subsystem it owns consumes some of that budget in all three categories, permanently — not just while building it, but for running, patching, and answering questions about it. ## Why it constrains architecture Conway's Law says team boundaries become architectural boundaries. Cognitive load says how *much* a team boundary can enclose. Put together: > An architecture is only viable if each boundary fits inside one team's cognitive-load budget. A "beautiful" decomposition where one team owns nine services across three unrelated domains will degrade: the team will context-switch, learn each system shallowly, take shortcuts across the boundaries they own (because internal shortcuts are cheap), and the services will drift into a tangle. Conversely, boundaries so small that a team owns one trivial service leave capacity unused and multiply cross-team coordination. This inverts a common habit: instead of "design the system, then staff it", you check each candidate boundary against "can one long-lived team realistically own this — build, run, and be on call for it?" If not, the boundary is wrong, or the team's other responsibilities must go. ## Symptoms of overload - Lead time for changes rises; work sits in progress waiting for the one person who knows. - Change failure rate and MTTR climb; incidents in the less-loved systems take much longer. - On-call is dreaded; runbooks are stale; the team can't explain half of what it owns. - Toil and upgrades are perpetually deferred; dependency versions rot. - "Bus factor of one" per subsystem — knowledge is siloed inside the team. - The team refuses or slow-walks new work not because of capacity in hours but because of unfamiliarity. A useful low-tech measurement: ask the team to list every domain and subsystem it owns and self-rate its comfort with each; the count of low-comfort items is your signal. Cognitive load is not measurable in story points; it is measured in *distinct things that must be understood*. ## Remedies, in order 1. **Delete or consolidate.** The cheapest load reduction is decommissioning a system nobody needs, or merging two near-duplicate services. 2. **Remove extraneous load with a platform.** A self-service deployment pipeline, standard runtime, and turnkey observability strip the same accidental burden from every stream team at once. This is the *purpose* of a platform team — not centralization for its own sake. 3. **Standardize.** Fewer languages, frameworks, and deployment shapes lowers intrinsic load across the org, at the cost of local optimization. A deliberate trade. 4. **Bring in an enabling team.** Temporary coaching (test automation, security, performance) raises capability so the same scope costs less effort. Time-boxed — a permanent helper becomes a dependency. 5. **Extract a complicated-subsystem team.** If part of the scope needs genuinely rare expertise (an optimization solver, a codec, an ML pipeline), concentrate it in one specialist team so stream teams consume it as a service. 6. **Split the domain.** Last and most expensive: identify a fracture plane (business subdomain, change cadence, compliance, user persona), carve out a bounded context, and give it to a new long-lived stream-aligned team — with its own data and pipeline, or you'll create a distributed monolith. Adding people to the existing team is *not* on the list as a first move: beyond roughly 8-9 people the internal communication cost grows superlinearly, so a bigger team does not buy proportionally more cognitive capacity; it usually means the team informally splits anyway. ## Trade-offs and edge cases - **Standardization vs. autonomy.** Lower intrinsic load through uniformity conflicts with teams choosing the best local tool. Most orgs pick a "paved road" that is optional-but-excellent. - **Platform load is real too.** The platform team itself has a cognitive-load budget; "thinnest viable platform" exists so the platform doesn't grow into its own unmaintainable monolith. - **Legacy nobody wants.** Load from legacy systems is often invisible until an incident. Explicitly account for it, and prefer decommission plans over quiet ownership. - **Small organizations.** With 15 engineers, everyone communicates cheaply; formal load management is overhead. The constraint bites as headcount and system count grow. - **Domain vs. technology load.** A team can absorb a wide domain with familiar technology, or narrow domain with unfamiliar technology, but rarely both at once — useful when planning a migration. ## The one-line takeaway Cognitive load turns "where should the boundaries be?" from a purely technical question into a socio-technical one: a boundary is correct when one stable team can own everything inside it, end to end, without exceeding what it can hold in its head.