Gene Kim and the folks behind IT Revolution are up to some great things as thought leaders in the tech industry. Their stated goal is to:
Elevate the state of technology work, quantify the economic and human costs associated with suboptimal IT performance, and improve the lives of IT professionals around the world.
It’s a lofty, worthy goal, and they work towards accomplishing this via books, papers, articles, conferences, and a podcast. They have an excellent monthly newsletter that is worth considering a subscribe to. One of their recent articles titled “Minimize Team Cognitive Load To Increase Flow” hits on a topic that I’ve been interested in for a number of years now.
The notion of cognitive load refers to how much of our precious brain power we are using and storing information in our finite working memory resource capabilities. We all have limits on how much information we can process and retain at any given moment. Wikipedia has a good page on the topic if you’d like to read more on Cognitive Load Theory.
We all have had those moments where we hit information overload and need to go take a nap or go for a walk. An analogy came to mind recently when I was watering my houseplants. If I pour in too much too quickly, the soil doesn’t have time to effectively absorb the water and instead it overflows onto the floor. But if I take my time, the soil has time to better and more effectively absorb the water therein giving more life to the plant and not spilling out onto the floor.
We experience moments of cognitive overload in all aspects of our lives. When it’s simply too much to process, and when the cognitive load feels relentless, our stress response is triggered and our ability to process information weakens because of the physiological and psychological effects that stress has on us. We think we’re getting a lot done and maybe we even falsely believe the myth that we’re excellent multitaskers, but instead we’re getting less done and what we actually are getting done is likely of poorer quality than if we lightened the cognitive load. Our flow is interrupted and therefore is damaged.
If it’s true that on an individual level increased cognitive load leads to poorer quality of wellbeing, poorer quality of work, and interrupted flow then we can extrapolate this into the effect it has on teams in the workplace in the realm of software development. Which brings me back to the points this article raises:
A team working with software systems that require too high of a cognitive load cannot effectively own or safely evolve the software.
For the individual, the onus is on us to reduce cognitive load in hopes to have an increased wellbeing and increased quality and flow of the things we wish to accomplish. But this is what we can control. What about the things that are out of our control, say for example at the workplace? Any software organization that cares about the quality and speed of which solutions are built, delivered, and adaptable to change absolutely must focus on reducing the complexity and load for the teams, and the human beings who make up those teams.
By asking the question that the article suggests “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” we can begin to gauge how healthy teams are. I love the simplicity of the question because it brings us the opportunity better understand where load might be too much and too complex. In a fast paced industry that is ever changing, it’s really easy for cognitive load to spike with little warning. Asking that simple question on a regular frequency can help gain insight into what we really need to be paying attention to: domain complexity—how complex the thing is that we’re trying to solve with software.
Assuming cognitive load is indeed a problem for your team, what can be done? Where do we start? When we frame things up around the notion of domain complexity, we get closer to learning how and where we can solve the problem. The earlier mentioned article does a fantastic job at providing heuristics of solving domain complexity, and therefore reducing cognitive load. I’ll quote the article here because it makes so much sense to me as written:
One: Assign each domain a team
Two: A single team should accommodate 2-3 simple domains
Three: A team responsible for a complex domain should not have any more domains assigned to them—not even a simple one.
Four: Avoid a single team responsible for two complicated domains.
If your team is showing symptoms that cognitive load is too much, start with asking “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” and then consider investing in the exercise of going through these four steps. Remember that no matter what path you decide, the team needs to fully own the system or subsystems they are responsible for from soup to nuts. Put another way: you build it, you own it. When teams, and the individuals who comprise them, are working on multiple codebases they lack ownership. Worse yet, they lack the mental space that is necessary in the understanding to keep systems–both socio and technical–healthy. And isn’t it precious mental space that is so crucial for knowledge workers and the systems we create?