Sizing solutions around cognitive load and organizational constructs

In today’s fast-paced digital world, complex solutions form an all-time high demand on the cognitive capacity of your team. That is why, in this article, we will introduce a rule of thumb for sizing solutions based on what your organization can handle. We will give a short introduction on cognitive load theory and organizational constructs. We believe that architects must consider these while decomposing their solutions into autonomous parts of a system that continuously and incrementally delivers value to the organization.

Cognitive load theory

The history of cognitive load theory can be traced to the beginning of cognitive science in the 1950s and the work of G.A. Miller. His classic paper “The magical number seven, plus or minus two: some limits on our capacity for processing information”, published in 1956, was perhaps the first to suggest our working memory capacity was inherently limited. His experimental results suggested that humans are generally able to hold only seven plus or minus two units of information in short-term memory.

In extreme summary: cognitive load is the amount of mental effort caused by factors such as domain complexity, the technology needed, and related overhead. Every solution, and every autonomous part, adds ‘cognitive cost’ to the organizational construct responsible for creating/changing/operating/running that solution, or autonomous part thereof. Every organizational construct has a ‘cognitive capacity’, the maximum cognitive load it can handle.

Organizational constructs for the best solutions

We take the three organizational constructs defined by SAFe as a reference for their approach to solutions and sizing of teams:

1. An Agile Team is a cross-functional group of typically ten or fewer individuals with all the skills necessary to define, build, test, and deliver value to their customers.

1. The Agile Release Train (ART) is a long-lived team of Agile Teams that incrementally develops, delivers, and often operates one or more solutions in a value stream. ARTs are composed of Agile Teams that align to a shared business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together.

1. The Solution Train is the organizational construct used to build large solutions that require the coordination of multiple ARTs and suppliers. These solutions often have an unacceptable social or economic cost of failure. Besides this they are usually subject to industry and regulatory standards, and must provide objective evidence of compliance with those standards.

When designing ARTs and the teams composing them, SAFe recommends applying Team Topologies at scale:

The team topologies can be readily extended to help make the right trade-offs in ART design as part of a Solution Train:

Team Topologies also identify three core interaction modes, which explicitly guide inter-team interaction and help create well-defined boundaries that reduce cognitive load for each team.

Rule of thumb for sizing of solutions

As collaboration is expensive in terms of cognitive load, this constrains the size of every organizational construct.

Architects are expected to decompose solutions into autonomous parts intentionally. Domain-Driven Design defines these as bounded contexts, which are isolated from each other and easier to change, test, and incrementally develop. This separation allows teams to autonomously focus on their specific bounded contexts without undue interference or complexity from other bounded contexts, producing solutions that can be independently designed and delivered.

There is a one-on-one relation between an autonomous part and a team, and between a solution and a team-of-teams. The other way around a team can own multiple autonomous parts and a team-of-teams can own multiple solutions!

Whichever problem your organization is solving, your solution should be questioned on how well its ‘cognitive cost’ fits within the ‘cognitive capacity’ of your organizational constructs.

We have a rule of thumb for the sizing of solutions:

• The 'cognitive cost' of every autonomous part of a solution must be, at most, the 'cognitive capacity' of a team (ten or fewer individuals).

• The ‘cognitive cost’ of a solution must not exceed the ‘cognitive capacity’ of a team-of-teams (typically 50 – 125 people).

• The ‘cognitive cost’ of a large solution must not exceed the ‘cognitive capacity’ of multiple team-of-teams and suppliers.

Decompose your next solution into clever bounded contexts and ensure its ‘cognitive cost’ fits within the ‘cognitive capacity’ of your organizational constructs.

Less is more: in a complex problem space, employing multiple smaller solutions reduces the overall cognitive load.