Introduction

Welcome to Navigating the Complexity of Cognitive Load in Software Product Development.

This website is a reconstruction of the published eBook, created for the convenience of spreading knowledge and understanding to a wider audience.

Here, we explore how cognitive load — the mental effort required to perform tasks — silently shapes the outcomes of software product teams. While most conversations fixate on velocity, frameworks, or tooling, we turn the spotlight to something more human, yet equally technical: how much brainpower is burned just trying to get through the day.

Purpose

The purpose of this resource is to help individuals, teams, and organizations understand, recognize, and respond to the invisible drag of cognitive load. By exposing the patterns, causes, and consequences, we enable readers to make better structural, technical, and organizational choices.

Scope

This isn’t a guide for project managers. It’s for those who build products and lead teams in complex environments — engineers, architects, tech leads, product people, and decision-makers who are sick of slogging through sludge.

We cover:

• Real-world patterns and anti-patterns
• Technical and organizational contributors to overload
• Ways to reduce cognitive friction while increasing autonomy and flow
• Case studies of companies applying these ideas for real

Key Themes

• Autonomy without chaos: Empower teams without burying them in decisions
• Structure that supports, not suffocates: Reduce vertical, horizontal, and technical complexity
• Continuous learning: How teams evolve with minimal mental waste
• Human-aware systems thinking: Seeing orgs and code as co-evolving systems

This site is a map — not for navigating features, but for navigating thinking itself in product development.

TL;DR: We’re not just building systems. We are systems — overloaded, entangled, brilliant systems. Let’s fix that.

Forewords From The Book

Foreword by Alexey Krivitsky (Org Topologies)

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% every year. Moreover, 83% of US workers suffer from work-related stress, with 25% saying their job is the number one stressor in their lives. Over time, on average, a stressed worker becomes 41% less productive and 33% less engaged.

While I found no such numbers specific to our high-tech field, i.e., digital product development, we can be sure that the ever-increasing complexity and speed at which companies are forced to push new value into the market doesn't reduce our stress levels. Quite the opposite!

So, it shouldn't be surprising that methods to reduce cognitive load have gained increasing traction in our field in recent years. For five years, it has been one of the factors most-quoted by managers when making organizational design decisions in their R&D organizations.

The most common treatment for the issue of cognitive load 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 the cognitive load of the team members.

Problem solved!

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

Over several years, the industry has become familiar with these ramifications, which have 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 delves several layers deeper than the popular materials online and on bookshelves that focus on reducing cognitive load.

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, and we must continue to uncover more optimal means of dealing with it. Without dualistic ideas of either–or, we must fight the work-related stress of our people and simultaneously 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.

This book offers two or three dozen practical, pragmatic, and systemic suggestions for working with the root causes of high cognitive load. What's more important, however, is that our suggestions do not jeopardize the vital characteristics of product development organizations: fast lead times, organizational learning capabilities, and overall business agility.

So, stock up on fast carbs and delve in. Make your way slowly and thoughtfully through this mini-book, written by a group of excellent, hands-on experts who, by the way, have witnessed these ideas being executed—not in fancy start-ups where things are easy to change but in large-scale, traditional, complex organizations striving for systemic improvements.

Alexey Krivitsky
Co-creator of Org Topologies
Munich, March 2024

Foreword by Christof Debaes (CIO)

Cognitive load is a special creature, one that silently yet profoundly influences every aspect of our work and learning. It is an unseen force that shapes how we process information, solve problems, and make decisions. In the world of software product development, understanding and managing cognitive load is not just beneficial—it is essential.

When I began my tenure in my current role, one of my primary objectives was to enhance both developer output and ownership—metrics that had been steadily declining despite the team’s high motivation. Management strongly suggested that delineating clear component ownership among the teams would address these issues. However, informed by the insights of, amongst others, Jurgen De Smet, I chose to diverge from this traditional approach and create an organization with a more fluid ownership. As a consequence, there was a lot of fear that this organizational structure would increase cognitive load, causing a decline in motivation, efficiency and overall ownership. Contrary to these concerns, we observed a rapid and significant improvement: the team exhibited increased adaptability, collaboration, and a marked boost in both ownership and productivity.

Hence, I believe a better naming of the book would be “Navigating the Paradox of Cognitive Load in Software Product Development”. Indeed, the way cognitive load is perceived and how it influences the product development is not obvious at first glance. The mechanics of how this leads to a balanced cognitive load is described in detail in this book. From the nuances of organizational topologies to the tactical implementation of fluid ownership, the authors share a wealth of knowledge that is both practical and transformative. The authors question the conventional ideas of specialization and propose a more flexible, cooperative approach that matches the changing nature of modern software development.

As I was embarking on this journey, I found that managing cognitive load is not just about reducing mental effort but about designing work environments that empower teams to thrive in communication, standardization and speed. I find this book an essential read for anyone seeking to navigate the paradoxical insights of cognitive load and leverage it as a catalyst for success.

Christof Debaes
CIO AccentJobs
Roeselare, June 2024

Foreword by Thierry de Pauw (Head of Security & Infrastructure)

Throughout my career, I have mainly collaborated with big, multi-team organizations. During those collaborations, I have seen my fair share of dysfunctions provoking the necessary cognitive load on teams and staff. But, for a couple of years, I joined forces with a startup.

We are less prone to Conway's Law misalignment problems. We are only a single product team consisting of product managers and engineers. However, the startup experimented with the concept of squads. By good chance, that dissolved naturally limiting the cognitive load of multi-teams. For a long time, there was such a thing as a product team and an engineering team, causing a reasonable amount of Conway’s Law issues. Here also, favourably, we managed to bring those two teams together into a single product team. The product team is in close contact with users and defines the value delivered.

Despite this, cognitive load is still a thing. I am particularly pleased to see this book mentions engineering practices to contain cognitive load. Knowing the authors, I am not surprised, though. Therefore, to get a grip on cognitive load, we adopt certain engineering practices.

We use a mono repo that contains the code and automated tests for all applications and sub-systems, all database definitions, and infrastructure code, but also all documentation, operational runbooks and architectural decisions. A single clone allows all team members to gain awareness of all parts of the system. No need to chase after all different version control repositories. All team members can change any part of the system. Everyone can easily access the documentation without having to remember at which location they reside on the intranet. No, it is just there, inside the IDE. Engineers have all the required information at the tip of their fingers.

The mono repo is organized in a standard way, easing the navigation for team members. Code, whether applicative or infrastructure, is designed according to team standards, simplifying code discovery.

We have some specializations inside the team. That is natural. Some parts of the code base are rarely touched by some team members. If we were to unleash CodeScene on our version control history, it would reveal some knowledge bottlenecks. We are aware of that and know we need to work on that.

Safety nets are in place through automated testing of applicative code, a bit less for the infrastructure code, something we need to improve. And also by having continuous integration and deployment pipelines in place.

Even though we have all of that in place, we still suffer cognitive load. Trunk-based development and pair or team programming are not part of our practices. We make extensive use of pull requests, which come with loads of context switching and an appropriate share of cognitive load. That is a hard nut to crack as it is based on commonly held misbelieves in the industry.

Over the past six years, by sheer luck, we grew the business without growing the team because it is difficult to hire staff. Again, it positively influenced alignment with Conway’s Law. Consequently, it limited our cognitive load. Start small. Start with the smallest team possible. Then grow the team with the systems as we need.

In doing so, at some point, we may have to scale the team to multi-teams. In all likelihood, that is an interesting problem to solve. Coming from the Continuous Delivery community, I am a big fan of a value stream-driven approach, i.e. organizing teams around value streams. This requires identifying the sub-products that form the overall product offering of the organization and accordingly organizing teams around those sub-products. Right now, team members know all parts of the system. This might be overwhelming. With the value stream approach, we limit the number of systems team members need to acquire knowledge about, thus reducing the cognitive load. Nevertheless, teams still have overall control over which value to deliver to users.

This was the part of the book where I frowned. The book conflates component teams with value stream-aligned teams. Component teams are organized around system components. Hence, teams have no view of the value delivered. Their backlogs may possibly contain items from many different projects inducing context switching between those projects. It is a sure way to bring a whole organization to a halt to then deliver value extraordinarily slowly because of the massive amount of coordination, as the book correctly indicates. Not surprisingly, it increases cognitive load, fatigue, stress and burnout. We certainly do not want that.

Whereas value stream-aligned teams are organized around products. There is no such thing as projects. This goes beyond technical ownership. This is about owning as a team the vision of a single product. Teams are customer oriented whereas component teams are not. Teams have full end-to-end control of the value delivered, thus limiting handovers and cognitive load. As a result, teams have a better focus due to the lack of harmful team dependencies. Organizations like AWS, Spotify and Netflix have been fairly successful with this organization design. Alright, the UI of AWS is bogus as is its API, I give you that. We can see how the different AWS services have been designed by distinct teams. They completely lack any consistency. But that may potentially be resolved with an organization-wide chief product manager who defines the organization's product vision supported by a corporate UX team that details the UI and API standards.

The book made one remark that resonates. Sooner or later, there could indeed be an unequal importance between the products. One product becomes less important than others. In that case, we do not want to invest in the product anymore or invest less. Because teams are assigned to a product, there is a risk teams are kept unnecessarily busy. The Poppendieck’s shared Spotify solved this by balancing team budgets every quarter. If a product becomes less important, it receives fewer budget. Eventually resulting in dissolving the team.

This is all interesting. Yet, this is only about growing an organization. What about all those existing big corporations with their current entangled teams? How to solve that? Many will advocate the Inverse Conway Maneuver. With great satisfaction, I observed the authors critique the approach. Often, people have the wrong expectations about the Inverse Conway Maneuver. Just reorganizing to solve the problems does not hold true. It might work for greenfield products. It will not work for rigid, long-lived products inside long-lived organizations because of the homomorphic force that is at the heart of Conway’s Law. This force preserves a structure in the product as well as in the organization. If we try to change one, the other will work against it. In this regard, the suggested Fluid Ownership organizational design pattern is interesting. It makes sense as it is based on Systems Thinking and Queueing Theory. However, I have never observed this in the wild. So, it is difficult for me to judge and compare with the value stream approach. Having said that, the author’s argumentation on how Fluid Ownership reduces cognitive load surely holds up. For the same reasons, the value stream approach adds up. Because of the homomorphic force, reorganizing into that direction, whether Fluid Ownership or value stream approach, will be a challenging endeavour requiring many small incremental changes.

Regardless of whether we might disagree on some parts, the book provides a good analysis of cognitive load in delivering IT products backed by research. Additionally, it offers practical approaches on how to reduce cognitive load to enable the fast flow of work through the value stream, a critical practice to adopt in reducing time to market and cost of delay.

Enjoy the read. It is worthwhile.

Thierry de Pauw
Founder of ThinkingLabs
Head of Security and Infrastructure at Abbove
Gent, Belgium, June 2024

Foreword by Ben Nata (Developer)

There's a phrase attributed to Kent Beck: "Make it work, make it right, make it fast." Unfortunately, in software product development, we often stop at "make it work" in pursuit of developing the next new features, unable to afford the effort to make things right. This technical debt makes it harder to adapt to business needs as the number of features grows. Even worse, it might need to perform faster soon.

Instead of viewing this as a technical problem, the authors of this book explores it as an organizational problem, or "organizational debt," if you will. By reducing cognitive load and understanding the product correctly, it's easier to make many things right earlier in the process. I have experienced some of the techniques mentioned in the book firsthand, with guidance from Viktor. It more than helped me; it changed my way of viewing the product development process.

I hope you find this book insightful!

Ben Nata
Programmer at DKatalis
Kediri, Indonesia, June 2024