Cognitive Load for Knowledge Work
If you’re responsible for a budget that pays programmers or other knowledge workers, you probably care a great deal about getting good value for money from them.
This post describes a model of the burdens we place on these teams and the results we expect from them, called Cognitive Load. It’s a great thinking tool to help us manage capacity to achieve quality results without burning people out.
Cognitive load
If you’ve ever been a programmer yourself, you probably have some sense of what Matthew Skelton and Manuel Pais mean when they talk about the cognitive load on a software team.
The total amount of mental effort a team uses to understand, operate and maintain their designated systems or tasks.
Cognitive Load Theory comes from education, and it’s important to be aware that it has not been studied in the context of day-to-day programming work. However, my experience is that programmers spend all day learning: about their problem domain, their codebase, their tools and programming environment, their production environment, their team-mates and themselves, and so the application of this theory to knowledge work feels instinctively right to me. The authors of Team Topologies have made a great case for it.
The theory breaks down cognitive load into three types:
- intrinsic: the (lack of) ability of each individual learner to pick up the new concepts
- extraneous: how hard we make it for the learning to happen
- germane: the difficulty of the task itself
I find these original names a bit abstract and difficult to grasp. I propose some new names that I think better express what they mean, at least the context of knowledge work:
- Cognitive strength (of the individual or team)
- Cognitive friction (from the environment)
- Cognitive weight (of the task or problem)
The total cognitive load on any given team or individual is some function of these three elements. A team with high cognitive strength, working in an environment with low cognitive friction, performing tasks of low cognitive weight, will experience a cognitive load that’s well within their capacity. On the other hand, a team with low cognitive strength, working in an environment with high cognitive friction, attempting tasks of high cognitive weight, will struggle and become overwhelmed.
So for people paying for programmers, thinking about cognitive load is important. If you want quality results, you need to keep the cognitive load on the team within their capacity.
You want the cognitive load on the team to be coming from the hard problems they’re solving for your organization (cognitive weight), not from their environment (cognitive friction); and you want them to have the capacity (cognitive strength) to be able to carry the load you need them to.
Cognitive strength
If we can talk about cognitive load on a team, it’s also reasonable for us to talk about their cognitive strength: the amount of mental effort any individual or team has available to apply to their work on any given day.
In my experience, cognitive strength fluctuates: some days I feel sharp and I can tackle tough problems with relative ease and clear focus; other days, I just seem to get stuck and frustrated. This is also the concept of “gumption” from Zen and the Art of Motorcycle Maintenance:
Gumption is the psychic gasoline that keeps the whole thing going. If you haven't got it there's no way the motorcycle can possibly be fixed. But if you have got it and know how to keep it there's absolutely no way in this whole world that motorcycle can keep from getting fixed.
This is also similar to the (much debated) concept of decision fatigue or ego depletion. Famously, former US president Barack Obama only had two colours of suit:
You’ll see I wear only gray or blue suits,” [Obama] said. “I’m trying to pare down decisions. I don’t want to make decisions about what I’m eating or wearing. Because I have too many other decisions to make.
Cognitive strength also comes from experience. Knowledge of the problem domain, the specific programming language and frameworks, and the codebases used by the team, are all important indicators.
The more cognitive strength your team has available, the more cognitive weight they can carry.
Unless, of course they’re subjected to too much cognitive friction.
Cognitive Friction
Cognitive friction comes from the environment around a team, for example:
- How often are they interrupted by context-switching?
- Do they have great equipment and tools?
- Are repetitive processes automated?
- Do the team like each other? Do they feel psychologically safe around one another?
- Does the team practice Test-Driven Development (TDD) /Behaviour-Driven Development (BDD) or work in more of a code-and-fix mode? Do they do test automation at all?
- Is the codebase well architected and pleasant to navigate, or is it a confusing mess?
This friction contributes to the cognitive load on the team by amplifying the cognitive weight that the team is trying to carry. A relatively simple task can be made challenging by a high-friction environment, while difficult tasks become much easier when you have the right environment to support you.
Cognitive weight
When thinking about capacity, I like the metaphor of carrying weight for the work we do as programmers.
Some of the problems we solve are small and light, and even the most junior person on the team would have the cognitive strength to pick them up and solve them.
Working on problems that are a bit of a stretch builds cognitive muscle, and increases your strength for next time.
Some problems are big and heavy, and require a great deal of cognitive strength to tackle them.
Working on problems that are too big will crush you. Sometimes the cognitive load of a particular problem is just too great for any one individual to bear alone. It’s hard to sum it up any better than this comic from @vincentdnl:
Sure, you might have one powerful genius on the team who, through some fortunate combination of coffee, context and confidence is able to summon the cognitive strength to solve the problem on their own. But will anyone else on the team ever be able to touch that code again? Will this heavy block of cognitive load get carried gently to its destination, or is our solo hero, straining every mental sinew, likely to give it some bumps and scrapes along the way, leaving complexity and bugs in the code?
This is why we need ensembles, but more on that another time.
Capacity
Just like lifting weights in the gym, we will get the most out of a team if they’re operating at around their cognitive capacity, but not exceeding it.
This is an art, not a science, and involves working respectfully with the team, rather than throwing work at them.
All three elements of cognitive load on a team are things you can control, to some extent:
- You can create space, provide resources or coaching for teams and individuals to study and practice to increase their cognitive strength. You can add individuals with the right context and experience to increase the team’s collective cognitive strength. You can encourage them to work in ensembles, which multiply the cognitive strength of a group.
- You can facilitate continuous improvement processes, and encourage teams to take ownership of and solve problems that cause them friction. You can invest in these solutions to make it clear how important it is.
- You can take care not to overwhelm teams with problems that are beyond their capacity, breaking down problems or even entire monolithic systems, so that the team have the possibility to wrap their heads right around the work.
If you like the ideas in this post, you can hire me to work with your team or organization. I’m available!