Cognitive Bandwidth Is the Constraint

Stop me if you’ve heard this one. You have been staring at a hard problem for an hour, and you finally have the whole flow in your head. The function that looks innocent but quietly mutates shared state. The three callers that depend on the old behavior. The edge case in the retry logic that nobody documented. The reason the obvious fix breaks something two modules over. It is all in your head at once, every piece in the right relationship to every other piece, and you can finally see the shape of the change you need to make.

“Hey, can you jump on this real quick? It is urgent.”

So you do. It genuinely takes fifteen minutes. Then you come back to your editor and the whole structure is gone. You are looking at the same code you understood completely twenty minutes ago, and you have to walk back through it piece by piece to rebuild what you had. You had to dump the whole structure to handle the urgent fifteen-minute request. You remember some of the path you took to get there, but you still need to reconstruct your mental model. The fifteen minutes was never the real cost. The “real quick” interruption is now forty-five minutes of retracing your steps.

We tend to talk about limits on developer productivity as if it were about effort or speed. LLMs let you write lines of code more quickly, so you must be more productive. If the job were simply writing code, this would be true. The real work is understanding the problem, which means modeling the system in your head, understanding the domain you’re working in, knowing the strategic direction to ensure you don’t close off future development paths, while maintaining your architectural patterns.

Software is the work of building and maintaining mental models. To change a real system safely, you have to hold a surprising amount of it in working memory at once: how the system behaves, what the users actually need, the domain rules, the invariants nobody wrote down, the edge cases, the failure modes, and the tradeoffs you already considered and rejected and would otherwise reconsider from scratch. That model is the real work product. The code is just the part that ends up on disk at the end.

Working memory is small, and it is volatile. Building one of these models is slow and expensive. Losing it is instant and free. And the single most expensive thing you can do to an engineer is force them to rebuild a model they already had.

There is an old joke, usually credited to Phil Karlton, that the two hardest problems in computer science are cache invalidation, off by one errors, and naming things. The joke lands because cache invalidation really is hard. A cache is fast because it holds a warm, ready-to-use copy of something that was expensive to compute the first time. It is worth it right up until the underlying thing changes and the cached copy is quietly wrong. So you evict it, and the next read is a cache miss: you pay the full price of computing the whole thing again from scratch. In the real world, this is expensive. A freshly booted system can take an order of magnitude more resources until the cache is properly filled. Many systems are built with pre-population of caches as a startup step to get around this.

A loaded mental model is a warm cache. An interruption invalidates it. When you come back, you take the miss, and you pay to rebuild. Context switching is cache invalidation for the human brain. And exactly like a real cache, the expensive part was never the eviction itself. It is the miss that comes after. Unfortunately you can’t really prewarm a human brain.

This is why “jump on this real quick” is usually false, even when the person saying it is completely sincere. The quick part is real. The other task might genuinely take fifteen minutes. But the cost lands on the task you left, in the eviction and the rebuild, and it does not stop there. Sophie Leroy’s research on what she calls attention residue found that when you switch tasks, part of your attention stays stuck on the previous one. So you do not even get to rebuild at full capacity. You rebuild while a piece of your mind is still chewing on the thing that interrupted you.

Once you start seeing productivity as a bandwidth problem, it helps to have a way to talk about where the load actually comes from. Educational psychologists have one. Cognitive Load Theory, from John Sweller, splits the load on working memory into three kinds. The useful part for anyone leading engineers is that you have a different lever on each one.

The first is extraneous load. In the original theory this is the load imposed by how a task is presented rather than by the task itself. For an engineer, the sharpest version of it is everything the organization piles on that has nothing to do with the engineering at all. It is chasing a marketing director for sign-off before you can push a copy change to the website. It is finance interrupting your afternoon because you used the wrong billing code on a timesheet. It is the recurring status meeting that exists to reassure someone three levels up, and the approval step that stopped protecting anything years ago. None of it is the problem you are being paid to solve, and all of it draws down the same working memory the problem needs. Extraneous load is pure waste, and driving it toward zero is the most direct productivity work a leader can do.

The second is intrinsic load. This is the difficulty inherent in the task itself, given the engineer’s current expertise. You cannot delete it, because some problems are just hard, and that hard part is usually where the value is. But the assumption that intrinsic load is simply fixed is wrong. You can shrink it, in two different ways. This is a point Team Topologies makes at the level of whole teams: you reduce a team’s intrinsic load through good abstractions and good tooling, so the team can fit its actual problem inside its actual capacity. This is a lot of what platform engineering is for. The paved road exists so that nobody has to spend scarce attention re-deriving how to ship, or carrying a brittle release process in their head on top of the actual problem.

One way is to change the task. A good abstraction takes interacting pieces out of working memory entirely. If I can call a well-designed queue and trust it to behave, I do not have to hold its internals in my head while I solve my own problem. Decoupling does the same thing structurally. The fewer things that can affect each other, the fewer things you have to think about at once. A good abstraction does not hide complexity so much as take it out of the engineer’s head.

The other way is to change the engineer. Expertise is compression. A novice looks at a system and sees ten separate things that all interact, and has to hold all ten. An expert has seen that pattern so many times that it has collapsed into a single thing they recognize at a glance, and it costs them almost nothing to hold. This is why mentorship and giving people the time to build deep familiarity with a system is a direct investment in lowering intrinsic load. It is a large part of what good developer experience work and platform investment actually buy. It is also the reason that managing engineers as fungible assets is so damaging. Engineers are not interchangeable resources and managing them as if they are misunderstands the work they do.

The third kind is germane load, and it is the good one. This is the effort that goes into genuinely understanding the problem and building the durable model, the schema that becomes tomorrow’s expertise. This is the load you want people spending their bandwidth on, because this is the work. Everything else is overhead competing with it for the same small pool of attention.

Which brings the interruption back into focus, because an interruption does something worse than cost time. It takes germane load, real progress on understanding the problem, and converts it into extraneous load, the pure-waste work of rebuilding a model you had already built. The lost minutes are the least of it. You turn work that was moving forward into work you have to do over again. That is close to the worst trade available anywhere in the system, and we hand it out casually, all day long, in the name of being responsive.

That reframes a whole category of things we usually file under etiquette. Protecting focus time, leaving people large unbroken blocks in their calendars, setting norms about when a message deserves an immediate ping and when it can wait an hour: all of it is cognitive-load management, and cognitive load is the actual constraint on the actual work. Meeting hygiene and communication norms are not manners. They are productivity infrastructure.

The DevEx research from Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler puts some structure behind this. When they looked at what actually drives developer productivity, they landed on three dimensions: feedback loops, cognitive load, and flow state. Two of those three are exactly what we have been talking about. Keep the load down, and protect the uninterrupted stretches where that load can actually turn into progress instead of getting evicted before it does.

So the diagnostic I keep coming back to is a simple one. Look at your best engineers and ask how much of their attention actually reaches the problem in front of them, and how much gets eaten before it ever gets there. How much of their bandwidth goes to fighting the deploy, decoding the undocumented thing, recovering from the fourth interruption of the morning, sitting in a meeting that could have been a paragraph. Every unit of that is bandwidth that was not available for the work you are actually paying them to do.

Managing that load is one of the concrete things technical leadership is made of. You clear away the organizational friction that is pure extraneous load. You invest in the platforms, abstractions, and expertise that shrink intrinsic load. You defend the blocks of time where germane load quietly turns into working software, and, over a longer horizon, into people who are genuinely expert in your system. None of it is glamorous. All of it compounds.

You cannot make hard problems easy. The intrinsic difficulty is real, and it is where the value lives. But you can make sure your engineers are spending their limited bandwidth on the hard problem itself, instead of on the pile of avoidable overhead we tend to stack up around it. That is most of the game. Bandwidth is the constraint. The job is to spend it on the work.