TBM 321: "Reducing Complexity"

Should we be trying to “reduce complexity?”

An executive walks into a meeting room, clearly exasperated. It's been a long day of back-to-back meetings, conflicting priorities, and a growing sense that everything is becoming unmanageable. Normally, they don't attend this meeting but need answers for the CEO.

Twelve peering heads stare down from the Zoom meeting. Five more people are in the room. The whiteboard is filled with a web of boxes, arrows, and scribbled notes. The project lead reads through a series of detailed updates from all the dependent teams—flipping through a dense deck while their Zoom audio cuts in and out.

"By the end of Q [audio drop], we expect to be nearing completion of [audio drop], unless, of course, [audio drop]"

“Wait, could you repeat that?”

No one in the room seems to be tracking. The executive cracks. "This is too complex!" they exclaim. "We need to simplify this!"

But what does "too complex" really mean at this moment?

To the executive and many people in the room, everything feels harder than it needs to be. The mental effort needed to understand how all of these pieces fit together is simply too high. They see a tangled web of bureaucracy and friction—an endless maze of dependencies, handoffs, reviews, and people waiting on other people. It feels like sludge.

The executive's gut-level response is that:

• The team is adding unnecessary process layers.

• The team is somehow avoiding doing the work.

• There is unclear ownership—no one has taken charge. Everyone is waiting for someone else to make a decision.

• The team is overcomplicating something that should be straightforward. They're indulging in making things harder than they need to be.

But here is what they (the executive) don't see:

Everyone on the call is overwhelmed by competing priorities. The project lead has spent hours coordinating between teams, chasing down answers, and trying to align moving parts. It's virtually impossible to get more than three people on a call at any time—everyone's calendars are packed with back-to-back meetings, each tied to a different P0 project.

And it's not just the meetings. Everyone on the call works 60-plus hour weeks, pushing through weekends, yet it never feels like enough. They're doing everything they can to manage the workload, but there's always something more—a dependency, a misalignment, a problem cropping up from somewhere else that demands their time.

OK. Let's break this down.

Product Work is Inherently Complex

Product work, by its nature, is complex. It involves uncertainty, collaboration across multiple functions, and novel problems. Complexity emerges because product work requires adapting to changing conditions, integrating new information, and solving problems without obvious solutions. This type of complexity is neither good nor bad—it simply is. It's part of what makes the work challenging, rewarding, and meaningful.

The Company is a Complex Adaptive System

Any group of humans in a company will be part of a complex adaptive system. The constraints, habits, processes, decisions, and power dynamics that have evolved over time are a result of this system adapting to changing conditions, people, and goals. Emergent properties of this complex adaptive system include too many competing priorities, unsustainable workloads, an anxious executive, a growing sense of unmanageability, unstable Zoom audio, high cognitive load, and siloed structures.

High Cognitive Load (My Head Hurts)

When the executive says that everything is too complex, they are describing the mental burden of trying to make sense of all the moving parts, juggling competing priorities, and piecing together fragmented information is too high. This isn't about the complexity of the work itself—it's about the burden placed on individuals due to how work is structured and communicated and how people are organized. It is how the work feels and not how it is. 

We use the word “complex” as a shortcut for a lot of ideas.

Why is this an important distinction?

I've been reading a lot of articles recently about executives wanting to "reduce complexity." But if product work is inherently complex and groups of humans form complex adaptive systems, then reducing complexity in this case is impossible (and undesirable).

The key way the executive can "simplify" is to focus on reducing the drag and friction caused by too many priorities and other things that make it difficult for people to come together and do productive, complex knowledge work. From the outside, it looks simple—even if all the complex goodness is happening on the inside. 

Alternatively, the executive can advocate for creating conditions where teams can do complex work without needing constant, tight collaboration—where teams have bounded bubbles of complexity with simple interfaces between them. Clear boundary-setting allows teams to handle their complexity internally while minimizing the need for constant cross-team coordination.

But you often see, as in our story, a sort of knee-jerk reaction to blame the people in the room for why things are the way they are. Because, as an outsider, things look like a mess, it is easy to make the mental leap from mess to "these people are making this too complex" to "they are dropping the ball!" This kind of thinking is counterproductive—it puts undue pressure on the people already trying their best to navigate an overloaded system.

When leaders try to simplify without this in mind, they tend to push the cognitive load into the shadows because team’s fear getting on leadership's bad side. Teams pretend everything is going swimmingly with their nice, simple slides, but it is the same drag to get anything done.

The job of leadership isn't to "reduce complexity" in the work itself but to create an environment where people can work effectively with complexity—where the right practices and boundaries reduce drag and make complex work fun, challenging, and productive.

You can’t cheat the nature of the work.

---

Like the newsletter? Support TBM by upgrading your subscription. Get an invite to a Slack group where I answer questions.

---