Stop Fighting the Same Fire Twice

As leaders, we don’t wake up in the morning thinking, “Today we’re going to solve the wrong problem.” Yet despite our best intentions, many organizations end up doing exactly that.

They invest in new software when the breakdown is actually in coordination. They mandate more training when the issue is structural. They push teams harder instead of redesigning the work so it can flow. And then, usually within weeks or months, the same fire breaks out again — in the same place, with the same intensity — and the cycle repeats.

The reason this happens isn’t a lack of effort or intelligence. It’s a failure of diagnosis. Most organizations, under pressure and short on time, act on what they can see — the symptom — rather than on what’s actually driving performance. The root problem keeps generating the same downstream fire, invisibly and reliably, while the team exhausts itself putting out flames.

Getting out of that cycle requires something most organizations don’t make time for: stopping long enough to ask whether the problem you’re solving is actually the problem.

The Fire That Wouldn’t Die

I once worked with a small nonprofit whose donation campaign process played out like Groundhog Day.

Every campaign — regardless of size or complexity — ended with a crisis at the handoff between donor relations and accounts receivable. The timeline slipped. Relationships got strained. Leaders intervened. And then, without fail, the same breakdown appeared in the next campaign.

The organization’s response was always the same: more training, more reminders, stricter follow-through. Staff were coached, processes were documented, checklists were created. It didn’t help. The fire kept returning because no one had looked closely enough at what was actually causing it.

When I came in, we did something simple: we pulled the donor relations staff and AR team into a room together, rolled out a whiteboard, and mapped the entire workflow step by step. What became visible almost immediately was something no one had seen before. Two steps in the process were working directly at cross-purposes. Every week, the system was structurally generating the very problem the team was being asked to solve.

No one had spotted it because no one had gone to see it. Reports, dashboards, and meeting summaries had described the symptoms accurately. But they had obscured the actual mechanism. The work itself revealed it in about ninety minutes.

Once we redesigned those two conflicting steps, the crisis evaporated — not because people changed, but because the system changed. The staff who had been blamed, coached, and retrained for months hadn’t been the problem. The design had been the problem. And the design had never been examined.

Single-Loop and Double-Loop Learning

Chris Argyris, the organizational theorist whose work on learning and organizational behavior remains foundational decades after it was written, described two fundamentally different ways that organizations respond to problems.

Single-loop learning is the reflexive attempt to correct errors inside the existing model of work. Something goes wrong; you adjust the inputs — more training, tighter process, clearer instructions — and try again. The underlying assumptions about how the work should be designed are never questioned. If those assumptions are correct, single-loop learning works fine. If they’re wrong, single-loop learning just produces the same error more efficiently.

Double-loop learning goes deeper. It questions the model itself — the underlying assumptions, norms, and structures that generated the error in the first place. Instead of asking “how do we do this better?”, it asks “should we be doing this at all, and if so, is this the right way to design it?”

Most organizations under pressure default to single-loop responses. They’re faster, they’re more familiar, and they produce the reassuring appearance of action. But when the problem is structural — when the design itself is generating the outcome — single-loop responses don’t fix anything. They just keep the team busy.

The nonprofit I worked with had been stuck in single-loop learning for years. The question they kept asking was: how do we get people to follow the handoff process correctly? The question they needed to ask was: is the handoff process itself the problem?

Solving Problems vs. Dissolving Them

Russell Ackoff, the systems theorist, drew a distinction that I’ve found genuinely useful in transformation work. He distinguished between solving a problem — fixing it within the existing system — and dissolving a problem: redesigning the system so the problem no longer arises.

Solving is faster and requires less disruption. It’s also often temporary, because the conditions that generated the problem remain in place. Dissolving is harder and takes more time upfront, but it addresses the mechanism rather than the symptom. When you dissolve a problem, it doesn’t come back.

The distinction matters because most recurring organizational problems aren’t personality problems or skill problems or discipline problems. They’re design problems. The process doesn’t support the work the organization is actually asking people to do. The structure creates conflict between teams that are supposed to cooperate. The incentives reward behavior that undermines the stated goal. These are systemic conditions, and they generate symptoms reliably and predictably — no matter who is doing the work.

When leaders treat design flaws as people flaws, they don’t fix the problem. They demoralize the people, exhaust the team, and leave the condition intact to generate the next round of fires. When they see design flaws as design flaws, the path forward becomes much clearer — and usually more tractable than it appeared when the problem looked like a human failing.

Why We Miss the Real Problem

None of this is inevitable. But there are several patterns that reliably pull leaders toward the wrong diagnosis, and recognizing them is useful.

Visibility bias. Leaders act on what’s most visible — escalations, complaints, errors that surface in reports — rather than on what’s most causal. The most visible problem is almost always a symptom. The causal problem is usually quieter, embedded in the structure of the work, and only apparent when you look at the work itself.

The firefighting loop. Operational pressure leaves no capacity for investigation. Teams are so busy responding to the current fire that they can’t afford the time to understand why fires keep breaking out. This is self-reinforcing: the absence of investigation ensures the fires keep coming, which ensures there’s never time to investigate.

Familiar solutions. Organizations reach for tools they already know — training, coaching, process documentation, reorgs — even when those tools have nothing to do with the actual problem. Familiar solutions are comfortable and defensible, even when they don’t work.

Structural blindness. Most persistent problems present as people problems — someone didn’t follow the process, someone dropped the handoff, someone didn’t communicate. The structural condition that made those failures likely, or even inevitable, stays invisible until someone examines the work itself.

Toyota’s production philosophy addresses the last of these directly through a principle called Genchi Genbutsu — “go and see for yourself.” The discipline of going to where the work actually happens, rather than receiving reports about it, is what surfaces the structural reality that dashboards and meeting summaries can’t show. It’s what the whiteboard exercise revealed in the nonprofit: the actual mechanism of the problem, visible in ninety minutes, invisible for years.

The Shift: From Blame to Design

There’s a leadership disposition that underlies all of this, and it’s worth naming directly. The default attribution for recurring problems — people not following the process, lack of discipline, poor communication, skill gaps — locates the problem in people. That attribution is sometimes correct. But more often, when a problem recurs despite repeated intervention, the issue is that the process doesn’t support the work the organization is asking people to do.

The shift from blame to design isn’t just a matter of being kinder or more generous. It’s a matter of being more accurate. Systems drive behavior. When the system generates a predictable outcome, coaching the individuals within that system changes nothing. Redesigning the system changes everything.

Leaders who make this shift consistently tend to exhibit three recognizable behaviors. They go see the work — not the meeting about the work, not the dashboard that summarizes the work, but the actual sequence of steps as they happen. They treat variation and workarounds as information rather than failure; when people develop informal workarounds, that’s a diagnostic signal that the formal process doesn’t fit the real work. And they redesign the system rather than coaching people harder, because they understand that behavior is largely a function of structure, and structure is something leaders can change.

Are You Solving the Right Problem?

Before committing to a solution, it’s worth running through a set of diagnostic questions honestly. Not as a checklist, but as a genuine inquiry into whether the problem you’ve identified is actually the problem.

What problem do we think we’re solving — and what evidence do we have? If you can’t articulate the mechanism causing the problem, you’re working with a symptom.

What symptoms keep recurring, no matter how often we ‘fix’ them? Recurring fires are almost always a signal of structural misalignment, not individual failure.

Where are people creating workarounds? Workarounds aren’t bad behavior. They’re diagnostics. They tell you exactly where the formal design doesn’t fit the actual work.

What assumptions are we making about how the work should flow? Assumptions age faster than systems. The logic that made sense when a process was designed may no longer reflect how the work actually needs to happen.

When did we last observe the actual work? Not the meeting about the work, not the dashboard recap — the work itself. What would a direct observation reveal that reports are hiding?

Where are two parts of the process working at cross-purposes? Almost every recurring problem has a structural conflict buried somewhere. The whiteboard tends to find it quickly.

Bearing Check Question

The organizations I’ve seen break out of the firefighting cycle aren’t necessarily smarter or better resourced than those that stay stuck. The difference is usually a willingness to stop, look at the work itself, and ask a question that feels almost too simple to be useful:

Is the problem we keep solving actually the problem?

That question, asked seriously and followed honestly, leads somewhere different than the training plan or the performance conversation or the reorg. It leads to the work itself. And the work, when you look at it directly, usually tells you what’s actually going on.

Where in your organization are you fighting the same fire repeatedly — and what would you learn if you went to see the work instead of the reports about the work?