Cognitive Load
The total amount a team must hold in mind to do its work, treated as a hard constraint on how much a team can own.
The idea that gives Team Topologies its teeth: a team has a finite capacity for what it can understand and operate well, and exceeding it produces degradation that looks like poor performance but is really an allocation error.
Three kinds are worth separating. Intrinsic load is the difficulty of the domain and the engineering itself, reduced by skill and training. Extraneous load is the accidental burden — brittle deployment, undocumented systems, twelve tools to ship one change — and this is precisely what a platform exists to remove. Germane load is the valuable thinking about the business problem, and it is what the other two crowd out.
The architectural consequence is the one that changes decisions: service boundaries should be drawn so that a team's total load fits. A team owning fifteen services in five languages will maintain none of them well, regardless of how clean the boundaries look on a diagram. Conversely, the standard argument for splitting a monolith is often really a cognitive load argument, and saying so out loud tends to produce a better split than a purely technical decomposition.