Your team has a context window
Tokenising the team’s scope to avoid monolithic debugging
Every human has a limited context window, which is the set of facts, relationships, and recent events they can hold in “working memory” and use to make informed decisions. What’s less obvious is that teams also have a context window. It’s the shared body of knowledge, code, docs, relationships, and assumptions they must keep active to plan, build, and operate. When that collective window becomes too large, the team slows down, fragments, and eventually malfunctions. Not because the people are unskilled, but because the cognitive load is too much.
The Cognitive Science Behind Team Scope
Individual context window.
Psychologists call it working memory. It’s the small set of facts we can manipulate at once. For engineers, it’s the things one can hold in their head while coding or debugging. For example, the relevant service, recent commits, the feature’s business goal, and a mental model of the runtime. Human cognition is capacity-limited, and I often notice it in my life when running larger teams. The moment when I realise, I have no idea what the team is talking about.
Team context window. Scale up the individual context window, and you get the set of things a team needs to keep active to deliver: which products they own, the relevant codebases, APIs, and their guarantees, deployment flows, SLAs, stakeholders, and the historical decisions that matter. The larger this set, the higher the cognitive load required to do routine work. A team with too broad a mandate is cognitively similar to a person trying to solve a problem while juggling fourteen tasks and three conversations at once.
Why “window” is useful. A window implies boundaries and visibility. Good teams design windows that are the right size: small enough to be manageable, large enough to cover the team’s mission. When the window becomes scattered and defocused, context leaks, handoffs slow, and every decision becomes expensive.
Forces Behind the Context Window
There are three forces behind context windows that affect the team’s performance:
Cognitive limits: People can only track a limited number of moving parts at once. If an engineer is juggling ten services, multiple deployment paths, several data models, and a handful of product requirements, quality inevitably suffers.
Coordination cost: Every additional responsibility in scope or external dependency increases the complexity of keeping everyone aligned. This leads to more meetings, additional communication threads, and a growing number of required approvals, leading to slow teams with limited focus time.
Complexity amplification: When systems are tightly coupled and lack autonomy, even minor changes can set off unpredictable chain reactions. Resolving a bug in service A might demand a deep understanding of services B, C, and D, which slows down incident response and increases frustration. Simple fixes can quickly turn into a series of meetings just to align on priorities.
These challenges are concrete and observable. They explain why microservices without clear ownership devolve into monolithic debugging, why broad team scopes erode morale, and why feature velocity stalls even as headcount grows.
Increasing the Team’s Scope
When a team’s scope increases without intentional boundaries, the consequences show up gradually, then suddenly.
At first, work feels slower as engineers start navigating more repos, more code paths, and more stakeholders. A change that once involved two people now requires five. Then, the cascading effects appear as decision-making becomes difficult, where minor misalignments escalate into architecture disputes because no single person can see the whole system clearly anymore. On-call becomes detective work as the person responding to an alert must mentally traverse multiple subsystems, involve different teams and coordinate effective resolution. Ownership blurs, and accountability erodes when the team scope is unmanageable. Instead, individuals choose their specialisation and unconsciously assume “someone else” is covering the other piece. The team is not negligent, but the cognitive model simply no longer fits inside any single mind. People leave as frustration grows, the feeling of helplessness settles, and the team’s impact decreases. Simple retrospectives become scattered statements about ownership.
The irony is that leaders often interpret these symptoms as motivation problems, culture issues, or talent gaps. In reality, they’re cognitive failures caused by poorly scoped systems.
Why This Problem Scales With Modern Engineering
Modern software is inherently modular with different microservices, distributed systems, and asynchronous workflows. Modularity often introduces accidental complexity as every new service increases the number of components and the dependencies between them.
Teams inherit this complexity in the form of “implicit context”, aka the things they must know to avoid breaking the production system. Over time, engineering organisations end up recreating the constraints of monoliths, but this time not in code, but in cognition.
This is why high-performing engineering cultures obsess over boundaries. Amazon insists on “two-pizza teams” because each team must operate within a cognitively sustainable surface area. Netflix invests heavily in tooling, runbooks, and automation because reducing cognitive load is not a nice-to-have; it’s a foundational part of distributed systems.
The Real Insight: Scope Is a Cognitive Design Problem
Engineering leaders often talk about team scope in terms of efficiency, velocity, and ownership. But underneath those ideas hides something more fundamental: how much information humans can sustainably hold in mind.
If a team constantly feels overwhelmed, reactive, or trapped in meetings, it’s rarely because the people are underperforming. It’s because the team is attempting to operate with a context window that exceeds the team’s cognitive design.
The fix is not more process, or more meetings, or more dashboards. It’s a deliberate shrinking and shaping of the context window so the team can think again.
Because that’s what productivity really is: the ability to hold the right information at the right time.