Using teams to get work done in all walks of life is undeniable.  The concept of teams in business began in the 1920s or 30s (https://bit.ly/43Wu8RW). Whether the idea of “team” emerged a century ago or last week is less important. What is important is the knowledge that very little work happens without teams. Team-first thinking makes simple sense.  

The main theme that struck me during this read of Chapter Three was the need to reduce the cognitive load on teams. Cognitive load is the amount of mental effort required to complete a task or process information. As we have noted before all work even if it is on hold generates cognitive load. The load any person can handle well is different and not easily predictable. Coming up with a common load limit or even an effective measure is out of reach of most organizations. As leaders, we are stuck with assessing situations and using rules of thumb. Every leader, coach, and manager needs to have a good understanding of cognitive load.

The concept of cognitive load entered our consciousness of the business world in the 1980s. Studies of the impact of mental workload on learning and problem-solving provided a reason to pay attention. Anything that reduces the ability to solve business problems is very important for knowledge work. The bottom line is that a high cognitive load leads to problems. Those problems include mental fatigue, decreased performance, and difficulty in learning and retaining information. These “side effects” lead to crappy work. I could have used the more comfortable term “technical debt,” but that is the same as calling a landmine an “unscheduled disassembly device.”

Cognitive load as we have noted accumulates for a wide range of reasons. As I read this chapter I thought about conversations with teams and leaders from the last few weeks. I identified several common (real-life) situations that generate cognitive load. These include:

1. Poor control of work entry. This scenario occurs when the work keeps coming and is started and then juggled, causing tons of neglected WIP.

2. Functional silos. This situation occurs when a team starts work and then has to transfer it to complete a specific task. After completing the task, the work returns to the original team for completion. A few years ago I watched a team begin to build/provision a high-security server. Part way into the process they had a separate team acquire several software licenses. While waiting they had to report on their status on a daily basis (cognitive load).  Once they had the licenses, the team completed the build and deployed the server. The defense for the flow problem was “that is the way it is” – fatalism. This type of horrid organizational design is EXTREMELY common.

3. Application overload. Another common scenario occurs when teams become dumping grounds for applications. I know several teams that are “responsible” for a list of applications that exceeds the number of states in the United States. This is not hyperbole. Every person on those teams is in constant terror of the time when one of the applications they don’t know anything about goes belly up.

4. Big application, big team. Another common issue I see occurs when big applications have big support teams. I recently had lunch with a team lead supporting a large HR system. Their team size was 25 people — they almost needed a separate zip code. The team lead had sleep issues trying to stay on top of everything that was going on at once. This is a reflection of the amount of cognitive load.

Two root causes of these four issues jump out based on my re-read of Chapter Three. The two are application architecture and organization design. Add a healthy helping of inertia and myopia to add complexity. An understanding of Conway’s Law makes these issues plain.

Chapter Three provides several ideas for reducing cognitive load. One of these is the concept of limiting the number and complexity of the domains a team supports. This is powerful because it requires re-thinking application architecture AND organization design. The power of the concept means that without a huge amount of political will,  the chances of large-scale application is small. You need a proverbial burning platform. It is best to avoid the problem, to begin with. If not possible try sorting it out on a smaller scale to gain credibility in the C Suite.

For example, in the scenario where the team had a list of supported applications noted above. We addressed the load issue at a single-team level. We did a census of the application users and found interesting data. The organization retired several applications because no one used them. Two of the retired applications had recently gone through upgrades. Further analysis found several applications that did the same thing. The team consolidated user bases retiring 17 applications along the way. None of this work was simple. In the end, the team was in better shape and reduced the cost to the organization.

Chapter Three tells every organization to get its architectural house in order and to organize people in a way to optimize communication and collaboration. Do not fall prey to the “one size fits all” approach. Every person and team is different. Experiment with flow and value delivery in mind.

Buy a copy and upgrade your coaching skills – Team Topologies: Organizing Business And Technology Teams For Fast Flow

Previous Installments:

Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4 

Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf 

Week 3  Conway’s Law and Why It Matters – https://bit.ly/3muTVQE