What Is the System Protecting?

This series within The Load is about the kind of problems that have already been “fixed” once… or twice… and are somehow back again. It’s not for lack of caring or effort. Usually the opposite. Smart teams, real exertion, good intentions… and still, the same issue finds its way back into the room. At some point, it stops being about the problem itself and starts being about what’s underneath it.

That’s where we’ll spend our time. Looking at what pressure is revealing, where things are quietly straining, and what actually has to change so the fix sticks.

The goal isn’t more activity. It’s fewer repeats.

Thanks for being with us! -Tate

Last issue we looked at repetition as a signal. If something keeps happening despite real effort to stop it, the system is producing it for a reason, and the fix-it-and-move-on approach isn't going to get there. But that raises an obvious next question: if the system keeps producing the same problem, what's it actually doing?

The answer, more often than most leaders expect, is that it's protecting something.

That's a loaded way to put it, so let's get specific about what it means. Organizations aren't conscious, so they can’t make decisions to protect things. But they do develop patterns over time, and those patterns tend to persist, even when they're also causing visible harm. The repeating problem isn't just a malfunction. It's often a side effect of something the organization was doing on purpose, or at least something it has come to depend on, whether anyone planned it that way or not.

Here's a version of this that shows up constantly. A company has a senior leader, call him David, who's been there a long time. David knows everything. He knows the history, the clients, the exceptions, the reasons certain decisions got made the way they did. He's genuinely valuable. He's also a bottleneck. Decisions that should take a day take two weeks because they're waiting for David. Junior people have stopped trying to move things forward without him because it's faster to wait than to have him undo it later. Everyone knows this is a problem. David probably knows it too. But the problem keeps persisting because David's involvement is also doing something useful. It's providing quality control in a system where the written rules and processes aren't good enough to produce the right outcomes without him. Remove David from the loop and things might move faster, but they'd also go wrong in ways that are hard to predict. So the organization keeps waiting for David, even while complaining about it, because the alternative feels riskier than the delay.

The bottleneck is compensating for the fact that quality hasn't been built into the process itself. That's a structural gap, and the system found a human solution for it. An expensive, slow, unsustainable human solution.

This pattern shows up in different forms across almost every organization. The team that insists on reviewing everything before it goes out is probably not being territorial for the sake of it. They've probably been burned before, and the review is protecting against a class of errors that nobody has figured out how to prevent another way. The process that requires six approvals isn't bureaucratic out of spite. Each approval was probably added after something went wrong, and nobody ever went back to ask whether the underlying risk had been addressed. The cross-functional meeting that everyone dreads but nobody cancels is likely the only place where a particular kind of coordination actually happens. Cancel the meeting and the coordination doesn't find a better home. It just doesn't happen.

None of this means these patterns are good. A bottleneck that compensates for a broken process is still a bottleneck. A six-step approval chain that exists because the root problem was never fixed is still slow and frustrating. But understanding what the pattern is protecting changes the diagnosis completely. If David is the bottleneck because the process underneath him isn't trustworthy, the fix isn't to tell David to delegate more. He'll try and it won't hold, because the process still isn't trustworthy and he still knows it. The fix is to make the process trustworthy, and then David's involvement becomes optional rather than load-bearing.

That concept, of being load-bearing, is critical to this work.. Some things in organizations look like problems but are actually holding weight. They're uncomfortable and everyone complains about them, but they're doing real work. When you remove them without replacing what they were doing, things don't get better. They get better briefly and then something else breaks, often something harder to see. That's the pattern that makes leaders cynical about change initiatives, because they've tried things that worked for six months and then quietly fell apart. Usually what fell apart is that they removed the symptom without replacing what the symptom was compensating for.

So when you're looking at a problem that keeps repeating, especially one where previous fixes provided temporary relief, it's worth asking a direct question. “What would break, or get worse, or become more uncertain, if this problem disappeared tomorrow?” Not what would get better. What would get harder. If the answer is truly "nothing," the fix might be simple. But if you think through it fully and something comes up, that thing is probably what the system is actually protecting. And that's where the real work is.

This is also where organizations start to feel the difference between pressure and normal conditions. When things are calm, a bottleneck like David is annoying but manageable. People work around it. Timelines flex. The cost of the workaround stays low enough that nobody demands the underlying fix. But when the organization gets busy, the cost of every workaround multiplies. The bottleneck doesn't just slow one thing down. It slows everything that touches it. The six-step approval process doesn't just add a week to a project. It can add a week to every project, or even cascade into multi-week delays for lower priorities, right when speed matters most.

That's when the repeating problem stops being a background annoyance and becomes a crisis. And that's when you can see most clearly what the system is actually doing, because everything that was hidden in the slack of normal operations becomes visible when there's no slack left.

We'll talk about that directly in the next episode, because the load the organization is trying to carry, and whether it's built to carry it, turns out to be the right question at the center of most persistent problems.

Get The Load directly in your inbox