TBM 23b/52: Cognitive Load

Doubling up this week to keep up my "ship on Thursday" habit.

Check out yesterday's off-schedule post: The Mediocrity Trap

And some thoughts today, inspired by writing from Matthew Skelton and Manuel Pais. Check out their book Team Topologies.

Imagine for a moment that we can keep track of organizational cognitive energy. Where is it going? What is the impact? Are we recovering? At what rate? Maxed out? How often? What do levels look like over time? When two people work together, what happens?

Picture the impact of things like:

• An intense meeting about a complex, intractable problem

• A recurring production issue with "no easy fix"

• Context switching, frequent interruptions, "starting over"

• The challenge of learning how to collaborate with new team members, in a new domain

• Rapidly shifting priorities and strategic direction

• Long feedback loops. Waiting for clarification and/or validation

• When and how you spend your "magic focus hour" each day

• Trying to adhere to a process that clashes with your local needs

• End of day decision fatigue (and Zoom fatigue)

• Prolonged uncertainty with no clear paths to learning

Doing so makes it clear why "visualizing the work" as a series of tickets is too simplistic. Tracking time is also problematic. Where I spend my 2hrs of focus time, is more important than where I spend my 6hrs of less-able-to-focus time. The energy required to make strategic decisions may far outweigh the energy required to "do the work". Decision quality is far more important than shipping velocity.

We're also good at automatic self-preservation. We can't will ourselves into good decisions without taking a break. We go through the motions, operating at 50%, but decision quality suffers. The hero "rocking it" by juggling a million plates, will have no energy left to mentor, and coach. Managers seeking to "protect" a team from an onslaught of complexity and load, don't make that complexity go away. It goes somewhere (e.g. less context, locked in their head, lower decision quality, as a "no" back to partner teams).

The point?

I've always been a proponent of "visualizing the work". I still am. But we have to do far more than that. Knowledge work is not rote left-right assembly work. A kanban board might give us clues about where to start asking questions, but the answers will often have nothing to do with the work. Our organizations are networks where cognitive energy moves around to make sense of things. And visualizing that is a good deal harder (if not impossible, as it looks nothing like the org chart).

As a start, we need to make it safe to discuss, and not constrain management to what can be easily visualized and measured. “My head hurts” is valid. It is a signal.