Team Cognitive Load

When we talk about cognitive load, it’s easy to understand that any one person has a limit on how much information they can hold in their brains at any given moment. The same happens for any one team by simply adding up all the team members’ cognitive capacities.

What is Cognitive Load

Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory.”

Sweller defines three different kinds of cognitive load:

• Intrinsic cognitive load—relates to aspects of the task fundamental to the problem space (e.g., “What is the structure of a Java class?” “How do I create a new method?”)
• Extraneous cognitive load—relates to the environment in which the task is being done (e.g., “How do I deploy this component again?” “How do I configure this service?”)
• Germane cognitive load—relates to aspects of the task that need special attention for learning or high performance (e.g., “How should this service interact with the ABC service?”)

For example, the intrinsic cognitive load for a web application developer could be the knowledge of the computer language being used (on top of the fundamentals of programming).

The extraneous cognitive load might be details of the commands needed to instantiate a dynamic testing environment (which needs multiple hard-to-remember console commands).

And the germane cognitive load could be the specific aspects of the business domain that the application developer is programming (such as an invoicing system or a video-processing algorithm). 

Broadly speaking, for effective delivery and operations of modern software systems, organizations should attempt to minimize intrinsic cognitive load (through training, good choice of technologies, hiring, pair programming, etc.) and eliminate extraneous cognitive load altogether (boring or superfluous tasks or commands that add little value to retain in the working memory and can often be automated away), leaving more space for germane cognitive load (which is where the “value add” thinking lies).

Dangers of Ignoring Team Cognitive Load

When assigning responsibilities or software parts to a given team, we hardly ever discuss cognitive load. Perhaps because it’s hard to quantify both the available capacity and what the cognitive load will be. Or perhaps because the team is expected to adapt to what it’s being asked to do, no questions asked.

When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.

Cognitive Load at OutSystems

Miguel Antunes, R&D Principle Software Engineer at OutSystems, a low-code platform vendor, relayed an example of this very challenge.

Their Engineering Productivity team at OutSystems was five years old. The team’s mission was to help product teams run their builds efficiently, maintain infrastructure, and improve test execution. The team kept growing and took on extra responsibilities around continuous integration (CI), continuous delivery (CD), and infrastructure automation.

Victims of their own success, sprint planning for the now eight-person-­strong team was a mix and match of requests across their stack of responsibilities.

Prioritization was hard, and the frequent context switching even throughout a single sprint led to a dip in people’s motivation.

This is not surprising if we consider Dan Pink’s three elements of intrinsic motivation: autonomy (quashed by constant juggling of requests and priorities from multi­ple teams), mastery (“jack of all trades, master of none”), and purpose (too many domains of responsibility).

Demand on Cognitive Load Increases Over Time—Leading to Bottlenecks

While the team in the industry example above was providing internal services to development teams, the effect is the same for teams working on software for external customers.

The number of services and components for which a product team is responsible (in other words, the demand on the team) typically keeps growing over time.

However, the development of new services is often planned as if the team had full-time availability and zero cognitive load to start with.

This neglect is problematic because the team is still required to fix and enhance existing services.

Ultimately, the team becomes a delivery bottleneck, as their cognitive capacity has been largely exceeded, leading to delays, quality issues, and often, a decrease in team members’ motivation.

Build Teams with Cognitive Load Limits in Mind

We need to put the team first, advocating for restricting their cognitive loads. Explicitly thinking about cognitive load can be a powerful tool for deciding on team size, assigning responsibilities, and establishing boundaries with other teams. 

Overall, the Team Topologies approach advocates for organization design that optimizes for flow of change and feedback from running systems. This requires restricting cognitive load on teams and explicitly designing the intercommunications between them to help produce the software-systems architecture that we need (based on Conway’s law).

Cognitive Load at IKEA

Albert Bertilsson, Solution Team Lead, and Gustaf Nilsson Kotte, Web Developer, felt the weight of a continuously increasing cognitive load on the mobile team they were leading at IKEA back in 2017. As they relayed to us, in the previous year, the team kept growing as a result of successful delivery of multiple projects in a short period of time and across multiple markets.

This high-performing team kept adding more and more responsibilities on their shoulders, as the number of software products they maintained kept increasing.

Eventually, they started to run into problems due to some work streams preventing the releases of others. Despite understandable pushback from the team, Bertilsson and Kotte managed to convince team members that they really had two products in the same codebase and needed to split the team in two, following Conway’s law.

An interesting bit to retain here is that this was a high-performing team with all the intrinsic motivators (autonomy, mastery, and purpose), yet they were still feeling the pains of cognitive overload.

In our next blog we’ll look at how to use boundaries to minimize cognitive load.

This post was adapted from the book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais. 

- About The Authors

Matthew Skelton

Matthew Skelton is co-author of the award-winning and ground-breaking book Team Topologies, and Founder & Principal at Conflux. The Team Topologies book was rated one of the ‘Best product management books of all time’ by Book Authority and is widely used by organizations worldwide to transform the way they deliver value.

Follow Matthew on Social Media

• 
• 

Manuel Pais

Manuel Pais is co-author of "Team Topologies: Organizing Business and Technology Teams for Fast Flow". Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Continuous Delivery.

Follow Manuel on Social Media

• 
•