Systemic Reduction of Cognitive Load

Why Cognitive Load Matters

* This text is a version of the foreword I wrote for the free e-book Navigating Complexity of Cognitive Load by Jurgen De Smet and Viktor Grgic.

Have you ever tried collaborating with an overloaded person? In my experience, it is impossible to tell whether a person is overloaded or lacking professional attitude and skills. In other words, overloading makes us incapable of producing work of the expected quality.

The American Institute of Stress reports that workers' daily stress (measured in the US and Canada) increases by roughly 5% yearly. 83% of US workers suffer from work-related stress, with 25% saying their job is the number one stressor in their lives. A stressed worker gets, on average, 41% less productive and 33% less engaged.

I found no numbers specifically in our high-tech knowledge work field, i.e., digital product development. But we can be sure that the ever-increasing complexity and speed at which companies are forced to push new value onto the market doesn't make us less stressed.

Quite the opposite!

So, it shouldn't surprise us that reducing cognitive load has been gaining increasing traction in our field over recent years. For five years, it has become one of the most quoted factors managers consider when making organizational design decisions in their R&D organizations.

The most common treatment for the cognitive load problem is limiting the scope of ownership of software teams. This argument is easy to agree with (hence its popularity): the less code the team needs to manage, the less would be the cognitive load of the team members. 

Problem solved!

Yet, such organizational design decisions that seem correct when analyzed without proper scrutiny (fast thinking) have unexpected side effects rippling throughout the entire product development organization. It doesn't take a rocket scientist to see how private code ownership policy (applied to fight high cognitive load) quickly creates problems in other parts of the organizational system. Queues of pull requests, longer lead times of time-to-value, the “us vs. them” culture between different teams owning different parts of what a customer would call a “single product.” 

For at least several years, the industry is familiar with these ramifications, which spread almost uncontrollably within the larger product development system, making it slow to deliver, unresponsive to learning, and essentially non-agile. 

Are these the trade-offs that your organization is willing to make?

This book you are about to read goes several layers deeper than the popular materials on reducing the cognitive load you can find online and on bookshelves. The world is not black and white. There are no one-size-fits-all solutions out there. There is no quick fix to complex dilemmas.

Reducing cognitive load is so important that we must keep uncovering better ways to deal with it. But without dualistic ideas of either-or, we need to fight the work-related stress of our workforce and simultaneously learn to tap into the unlimited potential of our organizational intelligence.

We must go beyond curing just the symptoms and applying fast, sloppy thinking to complex issues.

Reduction of Cognitive Load is Critical!

And it is also important to understand that cognitive load has nothing to do with storing of information in our brains: those limits have not been found by the research, so we can assume that our inner hard drives are unlimited.

Hence, point #1: cognitive load has nothing to do with knowing different things, we can keep acquiring new information almost forever.

But what is limited, in fact, is our immediate temporary memory (i.e., RAM) - we cannot stay productive by being focused on more than a handful of things, and we cannot be engaged simultaneously in several unrelated complex activities. E.g. did you notice when driving a car that when the traffic situation worsens, then for those few moments we stop paying attention to the news on the radio?

Hence, point #2: cognitive load is essential for maintaining our productivity. 

Now, how to approach this in our workplace? How to design organizations that take that into account? The art and science of org design is not to mix primary and secondary concerns. 

What do we mean by that? Organizations are NOT created to reduce cognitive load. In fact, the best way to reduce it would be NOT to start a company and NOT to engage in product development. So, in fact, not delivering value is not an option.

Hence, point #3: the primary concern of an organization is to discover and deliver customer value. 

Now, now we agree that the customer value is our primary concern, we must find ways how to do that in the most effective and productive manners by maintaining adequate levels of cognitive load. This work becomes our secondary concern in org design.

Customer value in most cases is a thing that spans different components, modules, microservices, applications ... it is a cross-cutting thing. Therefore, in order to solve customer problems and provide the best customer experience, we need to keep this wholistic view.

Hence, point #4: we need to find ways to stay productive and reduce cognitive load without jeopardizing customer value and customer experience. 

So point #5: divide and conquer (i.e., split the product into parts and give away those parts to be owned by individual teams) is not always the best option. In fact, that must be our last resort.

To Summarize: Misapplying Cognitive Load Theory is Dangerous

As Dennis Wagner concludes in his post on Debunking Cognitive Load Theory (CLT) in the Context of Team Work:

The Danger of Misapplying the CLT: the conclusions drawn by the authors of Team Topologies are not just wrong, they are dangerous! Misapplying CLT to team work undermines the essence of DevOps and Agile principles. It suggests a rigid, narrow approach to teamwork that will stifle innovation and flexibility!

To avoid the false advice offered by the misapplication of CLT - we need to have more options to consider on how to deal with cognitive load. Not merely limit the team's scope of work, as this is a contradiction to all that we've learned about Business Agility so far.

More options, please?

There Is More Than One Way To Manage Cognitive Load

Hence, this list below is ways to reduce cognitive load by maintaining a systemic view on the customer problems:

#1 Simplify, Automate and Standardize (Reduce Switching Costs)

#2 Apply Test-Driven Development

#3 Share Work and Mob (Avoid Individual Tickets)

#4 Use GenAI

#5 Minimize the Distance to Customers 

#6 Avoid Separating Discovery and Delivery (Continuous Discovery Habits)

#7 Embed Business Analysis into the Teams

#8 Minimize General Organizational Complexity

#9 Use Modeling Techniques to Grasp the Bigger Picture 

#10 Minimize WIP

#11 Develop Learning Skills by Making Learning a Habit

... and the list goes on and on.

Get the free e-book!

Expand your option set when dealing with cognitive load management.

This article was initially published at:

https://www.orgtopologies.com/post/systemic-reduction-of-cognitive-load