Exponential Leadership: Foundation #3 — Respecting Cognitive Load
I believe technology leaders can have an exponential impact on their company, and by extension, the world. Achieving the integration between people, process, and technology is THE job technology leaders have, and doing it well results in an exponential impact. I call this exponential leadership.
This is the third installment of my blog series on the foundational elements of exponential leadership. Today, I’ll cover the importance of respecting cognitive load. Here are links to the previous installments on Foundation #1- Empathy and Foundation #2 — Fast Feedback
Foundation #3 — Respecting cognitive load
Discern your system architecture
Reduce toil
Understand your bandwidth limits
If you read my first two installments on the foundations of technology leadership, you may have noticed they are light on the technology side. That’s about to change. Let’s talk about cognitive load, but first, let’s define it.
Cognitive load is the amount of information a person can process at any given time (at least, that’s how I define it). If you think of information as fill dirt, and the brain as a dump truck, you can only throw so much information in before the truck is overflowing.
This is a relatively intuitive concept at a personal level. You can’t open three web pages and read all three simultaneously. However, leaders often struggle at structuring work in a way that respects cognitive load. That’s because it’s natural to optimize for personnel utilization, ignoring the mental effort involved. Knowledge work is invisible, so you can’t directly observe the effects of information overload like you can with a dump truck. It’s real though, and it’s important to respect the limits.
As a technology leader, the three main areas of cognitive load to consider are:
- Your system architecture
- The amount of toil required to get things delivered
- The amount of bandwidth you and your team possess
Your system architecture
I’ve heard a joke that if you need 200+ people in the same room to plan a release, you don’t have a planning problem, you have an architecture problem. While I’m not entirely opposed to agile scaling frameworks, I think they are often a crutch for gnarly architecture problems (amongst other abuses).
There is not a quick fix for architecture problems, so this is where bold leadership is required. The solution will almost always include reducing output for a time, which requires you to have credibility and a well-reasoned approach towards improvement.
One thing I’ve seen in architecture circles is perfect becoming the enemy of good. From a leadership perspective, getting a broad understanding of how work flows through the system, how various teams and their supported components dependent on each other, and feel for the technical acumen of those teams will give you a sense of where to start. Here’s a hint though- rewriting everything into decoupled microservices running in kubernetes probably isn’t your starting point.
A more likely entry point is finding a way to decouple two major components via an integration layer, or helping a specific team remove business logic from a frontend webservice. Concepts like Team Topologies and Domain Driven Design can give you a contextual framework for how to think about things, but it will take well placed questions and challenges to your team to dig yourself out of whatever architecture hole you are in.
It’s worth it, though. An architecture that supports independently changing components results in much less cognitive load and planning overhead. Instead of requiring ‘scaled’ agile, you can just have agile teams delivering independently. No scaling required!
Reduce toil
Zooming in a bit, another aspect of cognitive load that often goes unaddressed with technology delivery teams is how much toil the group experiences. This is usually the summation of a bunch of ‘papercut’ problems.
These are things that don’t take a lot of effort or time to resolve, but when taken in aggregate, reduces the overall effectiveness of your team. In DevOps circles, the delivery process for software is the primary culprit. Often times, there are many repetitive manual tasks required to deliver software into production. In the case of DevOps, there is often security compliance controls that need to be revisited and automation software for people to learn. This takes time and energy, and this is where technology leadership is required. It’s your job to challenge the status quo. It’s your job to have enough confidence in the desirability of the future state to overcome the naysayers.
DevOps aside, there are many dimensions to toil that leaders can address. Sometimes, the toil might look like requiring folks to enter the work they do into more than one system. Are they tracking their time in a billing system, entering notes into story tickets, and updating leadership with emails? This is duplicative effort and another manifestation of toil.
While part of being a manager is holding the line with some of these more tedious activities, the leadership portion is finding ways to reduce how much they suck. These solutions might have a technology component, but often, it’s understanding the various activities your team performs in a given week and finding ways to de-duped and deprecated low value ones.
A natural consequence of complex systems is that they become more complicated over time. Part of your job as a leader is to be a countervailing force. In some circles, this might be referred to as continuous improvement. Others might refer to it as leaning things out. Whatever this looks like for you and your team, it’s your job as a leader to ensure that it’s happening. If it’s not, your team will get worse over time.
A good test on whether your architecture or toil is a major problem is to measure how long it takes a technically capable new hire to become proficient. The greater the complexity, the longer it takes to become productive. I’ve seen ‘hire date to first commit’ as a measure of developer productivity, but similar measures can be used in other contexts. How long until your network admin can implement changes? How soon until a help desk admin is able to take calls on their own? These are good proxy measures for the cognitive load required to do work in your system.
Your bandwidth
Finally, the other important aspect of cognitive load to consider is you and your team’s personal bandwidth. How many things are you personally leading? How many business domains and technology widgets does your team work with in a given month? These are important things to gauge in life and in work. Getting into a ‘flow’ state with work requires minimal context switching. The more balls you are juggling, the fewer things you will do well.
I had a mentor tell me years ago that we only have so many ‘energy units’ we can use in a day, so it’s best to focus those energy units on what’s important. I’ve actually found that I also have a natural limit to the number of things I can effectively lead in a given time period. There was a period in my professional career where I changed employers and moved back into an individual contributor role. While I worked as an individual contributor, I found other outlets for leadership, which included becoming the president of a neighborhood association and starting a running club.
Leading these things were going well. However, when I moved back into a leadership role at work, I started having trouble switching leadership contexts. Basically, the creative energy necessary to envision an idealized future is a limited resource within me. My hypothesis is that everyone has a natural limit to the number of things they can lead. To me, this highlights the importance of work-in-progress limits for initiatives. As a leader, you can only lead so many things. Make sure the things your people are working on are the most important things and that there are not too many things in flight at once.
Briefly diving into ‘work-in-progress’ (i.e. WIP), if you have too many things going on at once, it will naturally increase how long it takes to get anything done. This impacts your ability to get fast feedback AND increases the cognitive load for you and your team. There’s a lot of great literature on the evils of WIP, but boy is it easier to say ‘yes’ to things rather than ‘no’. As a leader, it’s best to develop an intuition (or better yet, a system) about how much work you and your team has in progress, and limiting things so you are balancing throughput and turnaround time. If you don’t, you’ll likely end up sucking at both.
Finally, when it comes to cognitive load, there is a natural limit to the size a working group can be. Counterintuitively, as you add more people to an assignment, you may end up slowing things down. I’ve found this number to fluctuate based on the type of problem you are facing. Generally speaking, if you have more than seven people assigned to a particular task, you will run into trouble. The reason is that the communication overhead and people’s natural desire to not look stupid in a large group begins to outweigh the value of the added brainpower. With seven people approaching the upper limit of effective teams, this means you want your architecture, work breakdown, and organization structure to support smaller teams. There’s a lot to unpack in that last sentence, but just check out Team Topologies if you’re curious.
To wrap up, there isn’t really a hard and fast rule for respecting cognitive load. When it comes to WIP limits, team size, reducing toil, and system architecture, it is usually trial and error mixed with experience. Adding to the complexity, there is the constantly evolving landscape we all operate within.
Whatever the specifics of the landscape you operate within, the guiding principle is that you and your team only have so much cognitive load available.
Don’t overfill the dump trucks.
