Why care about this at all?

Many of the teamwork and system changes we’ve made within Cognician’s Platform team over the last 5 years were directly aimed at reducing our cognitive load.

From moving specific work streams to different teams, to the playbook we follow when dealing with ad-hoc requests, we’ve found and ‘gardened out’ a ton of extraneous effort from our systems, both social and technical.

We’ve also done several big projects that took months to complete, to streamline our effort for years to come: one of the biggest was to switch to a mono repo for our source code. (If this is something you’d like to hear more about, let me know!)

This has allowed us to operate a living system with very little (comparative) effort, to make meaningful investments into that system’s growth, and to have space and time to make other, newer ‘development bets’ as a team. All while keeping the lights on and meeting our business’s daily needs.

We’ve done all this while also making it possible for everyone on the team to enjoy their non-working hours with mental clarity and peace, knowing that the work side of things is set up for success. No late nights or weekends at work are needed.

And, we’ve plenty of time and space to coach and mentor our junior team members, whether they’re new to the role, or just new to our team.

High-leverage effort, calm and well-rested people, and plenty of room for growth and change. Three BIG wins from pursuing a single powerful line of inquiry: mapping cognitive load, and making investments to reduce and streamline it for the whole team.

Of course, that’s not to say that we have ‘fixed everything’…. there are always some things that could be simpler or easier to deal with. It is a living system, after all. It’s part of the dance! 😄

Today I’ll share a short a primer of this model of cognitive load, and then look at some options for finding and reshaping your system of work to optimise load for your team.

Contents

• A primer on cognitive load

• Caveats

• Strategies

  • Part 1. Mapping cognitive load - 3 strategies

  • Part 2. Make investments to reduce load - 5 strategies

—

A primer on cognitive load

I learned this model through the excellent Team Topologies book.

Your ‘cognitive load’ is finite, and, for a given focus of attention, can be categorised in three ways:

1: Intrinsic Cognitive Load

The mental ‘software’ of your chosen activity:

• How to think through the work

• How to code / draw / write / your-verb-here

• How to use the tools

• Environmental context, such as links and passwords

2: Extraneous Cognitive Load

All the stuff you wish you didn’t have to deal with:

• Slow builds

• Broken tools

• Over-complicated systems

• Rabbit-hole discussions

• Success theatre

• Pointless meetings

We all have our 'favourites' :-) Here are Cory House’s:

I couldn’t agree more, Cory!

3: Germane Cognitive Load

This is the subject matter you’re applying your mind and energy to.

• The new skill or information you're learning

• The program or prose you’re writing

• The art you’re creating

• The systemic challenge you’re unravelling

This is the good stuff. The stuff we want to live and breathe.

—

Optimally, you want as little of the Intrinsic load as necessary to function, and you want no Extraneous load at all.

Why?

So that you have maximised space for the work itself: the Germane subject matter.

Reducing or removing the Extraneous in particular, is important in two directions:

1. Greater budget for Intrinsic skills.

   High-skill specialists tend to work in a focused manner (in that other people handle the more mundane or administrative aspects of the work) because they need the cognitive bandwidth!

2. Greater budget for Germane context.

   Put another way, the bigger the problems you can solve.

Removing Extraneous cognitive load:

• Feels great

• Promotes flow states

• Gets the best out of everyone’s contributions

It should be a major goal for Complexity wranglers and Tool-builders alike.

I summarise this model of cognitive load as:

1. Intrinsic: skills and facts

2. Extraneous: noise and waste

3. Germane: needs and value (and more facts)

Caveats about dealing with systemic cognitive load

Before we dive into the 8 strategies, it’s important to position them in the broader context.

Diminishing returns

There is a finite amount of load that we can reduce. At some point, effort in this direction will produce little value.

Thankfully, though, most teams who haven’t looked at their work through this lens, typically have plenty of straightforward interventions they can benefit from.

It is incredibly unlikely that digital knowledge-work teams avoid all of these issues by happenstance!

Right time and place

Sometimes, circumstances may require that we leave things as they are, and put all of our effort into the primary, core work activity, to make forward progress during a momentous time for the team or business. This is one of those ‘disagree and commit’ situations — knuckle down, power through it, push through to the win condition.

Once the dust settles, though, don’t forget to come back to it. A perfect time to return to this idea is during the retrospective of that big push!

It’s also work

Systemic change is also work.

It creates a temporary load of its own, as we reason through things together and make deliberate changes, and as the full team learns to live with these changes, and take advantage of the ‘new normal’ we’ve created.

It’s a 2 steps back, 10 steps forward sort of thing. Be ready for this. Take it into account when making plans.

Strategies for dealing with cognitive load

To reduce intrinsic load is to reduce the number of things I need to be able to do or to remember, as I do my work, or as I interpret the work of a teammate.

To reduce extraneous load is to remove unnecessary or redundant effort from the work and from the environment.

We follow a basic two part process, in a continuous loop:

Part 1 — Mapping the load - 3 strategies

Before choosing one or more of these interventions to apply, get clear on where your team’s load is.

Part 2 — Experiments and investments to improve load - 5 strategies

Once you have enough clarity to know where your biggest issues are, then you can get to work making things better.

Part 1: Map out your team’s cognitive load

There are three high-leverage approaches to take here, which all build on each other:

1. Start a learning board

2. Talk to people

3. Reflect on the work as it happens

I recommend trying them all. You want to see the shared system from more than one angle, and you want to control for faulty human memory.

Also, like many things in the world of work, it’s continuous and cyclical. You keep doing them all!

—

1. Start a learning board

Gathering

Use the findings from the next two tactics to make a list of options for improvement within the team’s tools and processes.

Rank these observations by ‘pain level’ (frequency, subscription - % of team, severity).

Experimentation

As you and your team start to make investments as detailed in the next section, contrive experiments to run that could teach you more about the issues, and what might make them less bad, or go away entirely.

All the strategies below are options, but you’ll likely have more of your own. Either way, be sure to be clear on these questions:

• Do they reduce intrinsic cognitive load? How so?

• Do they reduce or remove extraneous load? How so?

• What do we intend to learn from this experiment?

• How long will we run it for?

Rank these experiments by effort, and by how much pain they’d reduce or remove.

Run the experiments that are in the value + effort sweet spot.

Key things to remember about running experiments:

• We delay judgment while the experiment is running.

• We’re not trying to fix something so much as we’re seeking to learn what would cause the thing to be fixed. It’s subtle, but vitally important to bear in mind.

• The only way to fail is to learn nothing from it!

As you learn from your experiments, you can make decisions about how the work works, and use what you learn to construct and run more experiments.

Advantages to running a learning board

• We can limit how much extra cognitive load your experiments create by limiting the number of experiments at any given time. Ideally, you start with just one, and add more over time as comfort and bandwidth increase

• It’s a centralised source of truth for the current how-the-work-works situation for your team

• It’s an excellent source of information for onboarding new joiners.

I first learned this idea from Claudio Perrone, through his talk on PopcornFlow (first 30 mins or so — slides here).

I got the name “learning board” from John Cutler, who put this 3-minute explainer video together.

John writes of the fantastic Beautiful Mess newsletter, which I heartily recommend!

—

2. Talk to people

Have 1:1s and team discussions. Talk to folks from other teams that your team interacts with regularly. Look at your system of work from lots of different perspectives.

Ask lots of questions. Share the screen and demonstrate how things are broken or slow. Work to see the system through your people’s eyes as clearly as possible.

Include questions on cognitive load in your sprint or project retrospective template.

In this mode, you’re looking for issues with high frequency (happens daily or multiple times a day), and high subscription (percentage of people on the team).

Those items that have both properties — high frequency and high subscription — are BIG levers for relieving substantial and immediate pressure in the system.

Encourage folks to volunteer these observations early and often.

Questions you could ask:

• What’s annoying or frustrating you right now?

• What do you wish could be simpler, faster, or take fewer steps?

• How do you get stuck, and how do you deal with it when it happens?

• Wave a magic wand. What’s no longer in the way?

• When contemplating a decision: how will this increase/decrease which kind of cognitive load?

—

3. Reflect on the work as it happens

After every task, do a mini ‘After Action Review’.

For ad-hoc requests, ask: why did we have to do this? What would make it unnecessary for this to be delegated to us, or for any human to have to deal with this again?

For the items that are necessary for the team (i.e. our usual work), look for ways to reduce that effort. Find ways to move it away from complex and towards simple. After finishing a task, write down the things that caused friction, either for individuals, or between individuals.

Then, at an appropriate level of effort, go and fix those things (using the strategies below, or your own), so that the next time this issue or request would have occurred, the correct response or intervention is already in place to deal with it.

To give you a sense of where this kind of reflection can lead, here’s the list of interventions we routinely applied as we responded to ad-hoc work of various kinds:

• Write documentation: FAQs, explanations, reference material, how-to guides, so we don’t have to write all this out when people ask questions

• Fix one or more bugs, so we stop having to support folks past them

• Silence annoyance-level error messages, so folks stop getting distracted by them or reporting them

• Migrate some data, so folks stop getting confused

• Build one or more features, so we stop having to do things manually

• Remove redundant features, documentation or data, so we stop having to direct people away from them

To me, this is the spirit of continuous improvement.

Part 2: Make investments to reduce load

Just as with mapping, intervening is also continuous and cyclical. All these strategies build on each other.

Where you begin, and what order you work in, will be based on your particular situation. (Therefore, this order I present them in here is arbitrary.)

1. Fix the tools

2. Directly attack entropy

3. Train the tools, train the practices

4. Write and maintain a knowledge-base

5. Set up a ‘stupid questions’ channel

This list is not exhaustive, however, if you’re doing all of them sufficiently well, it’ll be a lot easier to see whatever else there is that needs your attention 😅

—

Fix the tools

Look at the most frequent activities of the team and find slow or broken things that are used often (daily is a good threshold to begin intervening), and speed them up, or fix them.

These are all examples of load reducers for software development:

• Working test suites

• Static analysis tools with editor support

• CI processes - this directly correlates with one of the four DORA Metrics (Deployment Frequency). Running from start to finish in less than 15 minutes is the sweet spot. Any improvements after that are just fantastic ‘quality of life’!

• Scripts to run everything on a dev machine

• Scripts to run anything to do with cloud environments

• Automate routine things so that humans don’t have to remember to do them

Each team will have its systems with similar needs and opportunities for simplification and repair. Find yours, and fix them.

Also, be sure to set up a process to keep them all updated and in good working order.

—

Directly attack entropy

A good ‘digital hygiene’ discipline is fundamental to counteract entropy. We must clean up after ourselves, early and often.

This is a wonderful lesson from the culinary world: Mise en place. A working kitchen would fall apart completely if they weren’t relentless and deliberate about keeping their environment optimised for a few people to prepare food for many people — quickly, hygienically, and with high quality.

We can benefit from the same thinking for our work!

Deleting unused stuff — from small stuff like unused files, documents, etc, to not-so-small things like entire unused features or systems.

Correcting obvious mistakes as we encounter them:

• Spelling mistakes

• lint errors / warnings

• Annoyance-level bugs that are easy to fix if we would just focus on them for a short time

Removing inconsistency when we find it.

Unifying needlessly duplicated or fractured things - for us, moving to a mono repo was a HUGE reduction in so many things at once.

Removing unnecessary meetings. Shutting down unnecessary traditions (e.g. producing reports each week for people who never read them).

Bonus points for automating good hygiene e.g. breaking the build when the linter has warnings.

Some of these can sometimes mean substantial refactoring work, in that they need to be planned out and focused on.

Also, we have a saying in programming: ‘Deleted code is debugged code — Jeff Sickel’.

This means that you can remove work and waste from the system by deleting things so that we don’t spend any time talking about or fixing anything inside them.

—

Train the tools, train the practices

People also need to use these tools correctly. There’s a discipline element to it — everyone needs to contribute. Fixing tests. Refactoring for consistency. Reporting bugs correctly. Deleting unused stuff. It all helps, it all makes a difference.

• Pair with people to see what shortcuts or tool knowledge they’re lacking. Write shortcut notes together and have them practice.

• Write how-tos together, for next time (see the next point).

If you do it long enough, eventually you will help people to learn how to do this for themselves automatically whenever learning a new tool. They’ll become self-sufficient learners.

Build all of this into your mentorships.

Of course, directly invest in your people with books and courses and the like, too!

—

Write and maintain a knowledge-base

Ideally, this would all be in a single system for your team, but it may be spread out over several systems (especially if your business is not small any more).

Either way, you want any particular piece of knowledge to be one of these types:

• FAQs — this is best kept in a tool with excellent metadata and search capability. We use StackOverflow for Teams, and it has over 1000 questions in it!

  • Another bonus: Over time, we spend less time waiting for humans to provide answers, AND we switch context less often.

• Explanation — Narrative prose that spells out whatever the thing is. Could be a single document or a whole Notion database full of linked wiki pages.

• Reference — Any enumerations of facts. From spreadsheets to API references and everything in between.

• How-tos — system-specific playbooks that focus only on how to take a specific set of steps to get a specific outcome. This might be used by different teams to those who maintain the systems, so they might be kept in different a knowledge-base to the other categories.

We separate these types out from each other to simplify and focus each piece; for example, we don’t try to provide ‘how to’ guidance in the middle of a reference document, or list FAQs inside an explainer.

Instead, we cross-link between these different types to provide that context. This allows us to reduce repetition in our documentation, which eases corrective and maintenance work.

We create coherence and context for the reader by cross-linking between these pieces, and by using consistent language across all the different types.

For that reason, you’ll probably want to maintain a Glossary, too 😊

The last three items here come from the excellent Diataxis framework for writing technical documentation. I believe they are suited to any knowledge work context.

—

Set up a ‘stupid questions’ channel

I believe that the only stupid question is the one you didn’t ask (at least, within a well-intentioned, purpose-aligned team of people).

Set up a channel in your team chat space that’s specifically for folks to ask their ‘stupid’ questions. Make a point of modelling this behaviour yourself. Imposter syndrome is real; people need to see that it’s not only safe to do so, but that it’s normal and expected to do so.

Model ignorance and vulnerability, demonstrate to the team that it’s OK not to ‘know’. This directly invests in growing and strengthening your team’s psychological safety.

Of course, the point here is that many seemingly stupid questions are actually some of the best questions we could ask, because they reveal the gaps in our perceptions and understanding, and our various products, be they internal or customer-facing.

Lean into learning together, on purpose. Take full advantage of all the “beginner’s mind” you can find in your business. Juniors and new joiners should be encouraged to participate, and recognised and celebrated when they do.

To reduce effort over time, be sure to harvest and codify FAQs from this channel!

For more on psychological safety, I heartily recommend Tom Geraghty’s Psychological Safety newsletter.

Over to you

Using cognitive load as a framework for assessing the ‘personal cost’ side of systems is hugely beneficial. Using its guidance to improve the system can provide great predictive power and reduce effort substantially. You can get a lot more value for a lot less effort.

With the load optimised, growing the team is also optimised, because no one has to take on any unnecessary load, nor does anyone need to spend time training people on those redundant things.

I’ve given you a couple of starting points. A low-effort first step you could take: share this with your team, have them read through it, and then have a ‘so what do we want to do with this?’ discussion as a team.

I can help

If this is something you’d like help with, I offer a modest number of consulting hours per month. We can look at your system of work together, and reason through where the highest leverage places are for you to intervene next.

If this is something you’re interested in, please reach out via any of the links below!

In case this was forwarded to you:

Hi. I’m Robert Stuttaford.

In this Knowledge Worker's Toolkit newsletter, I introduce, explain, tell stories, share past experiences, and explore the connections and intersections of all the various systems thinking & knowledge work concepts & models I've encountered during my tenure as CTO at Cognician, over the past 13 years (and counting!)

Subscribe to the Knowledge Worker's Toolkit newsletter here:

https://kwt.stuttaford.me

Learn more about me, and what I’m about here:

https://www.stuttaford.me

Find me on:

• Twitter — https://twitter.com/RobStuttaford

• Mastodon — https://mas.to/@rost

• LinkedIn — https://www.linkedin.com/in/robertstuttaford/