The Firefighting Trap: Why Reactive Work Feels Productive

The phone buzzes. The Slack notification pops. There's urgency in the message, maybe a tinge of fear. And just like that, the strategic work you planned for today evaporates.

You know the feeling. The elevated emotional state, the adrenaline, the immediate pivot from whatever you were doing to whatever just caught fire. There's no time to assess root cause. There's barely time to think. You just react.

I've been there more times than I can count. And here's the thing that took me years to understand: it feels amazing. That's the trap.

The Dopamine Hit of Saving the Day

Firefighting gives you a rush. It's a dopamine hit, the same neurological reward you get from doom-scrolling and landing on that one video that hits just right. There's this satisfaction, this calm that washes over you when the immediate crisis passes.

The yelling stops. The emails stop. The phone calls stop. And you think: yes, I did this. I got this done.

It feels like productivity. It feels like value. It feels like you're the hero who swooped in and saved everyone.

But feeling productive and being productive are two very different things.

Anatomy of a Firefighting Day

Here's a recent example. We made a change to move some images from a local file system into the cloud. Something wasn't fully tested. The swap wasn't complete. Suddenly we're getting a ton of phone calls because one report doesn't look right anymore.

The immediate knee-jerk reaction: let's hurry up and revert this one change. But you can't just hurry up and revert one change when there's a whole set of changes that went along with it. You need to think about root cause, about dependencies, about what else might break.

But you can't do that in firefighting mode. Someone needs this report right now.

So it becomes five local production releases in a day. Hotfix after hotfix. No time to sit down and figure out what problem we're actually trying to solve. No time to ask what went wrong at a systemic level.

And then the day ends, and you're exhausted, and you feel like you accomplished something. But did you?

The Seen and the Unseen

There's this concept from economics, the seen versus the unseen. It's the broken window fallacy: someone throws a baseball through a window, and observers point to all the economic activity that results. The glazier has work, the window fitter has work, the delivery company has work. Look at all this productivity!

But they never think about what could have been done with that money, those resources, that time. What got crowded out by the window repair?

The same dynamic plays out in software teams. The firefighter who comes in on weekends, who fixes the 2 AM production outage, who saves the day when everything's falling apart: that person gets celebrated. Attaboys all around.

Meanwhile, the person who quietly prevents problems, who forces the team to think through what's going to stop those 2 AM moments from happening in the first place: that person often gets vilified. They're slowing things down. They're over-engineering. They're not a team player.

The system rewards the wrong behavior. And the perverse thing is that sometimes the prevention-focused people aren't just ignored. They're actively punished for not producing as quickly as the firefighter who's kicking the can down the road and creating more tech debt.

A Year of Bugs

I'm on a project right now that illustrates this perfectly. It's old code, VB.NET, written over the past 15 years. Near-constant fires. One developer, incredibly skilled, just maxed out on bugs.

Last summer, we sat down with the client about a really nice new feature. The document team would save time, engineering would save time, the floor would be happy. Everyone was excited. We were going to use this as an opportunity to start modernizing the stack: .NET Core with Vue, something more maintainable.

That was end of summer. We started a repo, committed the initial project setup, had a lot of momentum.

Then some urgent bugs came in.

Fast forward to now, four months later, and we haven't even started on that feature. It's been one bug after another. The same problems keep coming back in new use cases, new workflows. They added a facility for the first time in five years, and nobody knows all the details of what needs to happen because the institutional knowledge is buried in code that requires archaeological excavation to understand.

The developer is doing hero's work. He's such a trooper. But I can tell it's fatiguing him. When I ask how he's doing, he says, tongue-in-cheek, "Well, it's job security."

He's right. But it's also soul-crushing.

And here's the sad part: they don't want to spend the time and resources to really sit down and think through what's causing all these fires. They're not interested in engaging someone at the level needed to solve the underlying problems. So he just keeps grinding, one bug after another, solving the same problems over and over again.

The Competence Paradox

There's a strange dynamic I've observed: sometimes you almost want someone less competent on a project. Because some companies won't change until they hit a crisis. As long as a skilled developer can keep the plates spinning through sheer talent and willpower, leadership never feels the pain that would force them to invest in real solutions.

I've seen this play out. A company kept hiring guru-type developers who could muscle through anything. Each one eventually burned out or moved on, and each time leadership just hired another one. They never had to confront the systemic issues because talent kept papering over them.

It wasn't until they hired someone who couldn't execute at that level that they finally came to us and said: okay, we can't do this ourselves. We need a real technology partner.

That crisis moment, where things got bad enough to force change, was actually the breakthrough. The path to health sometimes runs through hitting bottom.

Coming Up for Air

If I could go back and give myself advice when I was deep in firefighting mode, genuinely believing I was being effective, I'd say this: come up for air as soon as you possibly can.

There's a temptation when you're grinding it out, when you've got all this momentum, to just keep going. Feed the hot hands. Let's knock everything out while we're in the zone.

That's exactly wrong.

The triage metaphor is the right one. Someone comes into the emergency room with blood squirting from their neck: you stop that first. You take care of the immediate thing. But once that's done, it might be all that needed to happen on that patient for a while. Now is the time to step back and ask: what's causing all these injuries in the first place?

Get the immediate fire out. Then stop thinking tactically and start thinking strategically.

The Pushback You'll Get

When you try to implement this "come up for air" moment with a team or client, you'll get pushback. Always. Because users are never satisfied. There's always a backlog. There's always something urgent.

Nobody is ever going to say, "Oh, everything's perfect now. Take two months and pay down tech debt. We'll wait."

That doesn't happen. At least, I've never experienced it.

So you have to get aligned with your product owner on what constitutes acceptable pushback. Has the urgency weakened enough that we can overcome it? Or are we still so deep in crisis that we have to keep going?

You have to triage the patients. Different users have different needs, different urgency levels. Some of them need to hear: "You've had enough attention for now. We're going to tell you to fix your diet and exercise and come back in six months. We have to work on systemic issues rather than just keep chasing symptoms."

It's hard to say. It's harder to enforce. But it's necessary.

The December Reckoning

A whole year will pass you by. I've seen it happen over and over again.

Teams wake up in December doing their end-of-year reports, looking at the goals they set in January, and they realize they didn't accomplish any of their strategic objectives. Just fires, all year long. No forward progress on anything that mattered.

Those meetings are tense. The higher-level stakeholders, the ones who had the vision at the start of the year, they're frustrated. But here's the thing: they're the ones who kept shifting priorities. They pivoted away from the strategic work to handle the urgent stuff. They weren't willing to make the right priorities.

You can't just blame your executive stakeholders. That doesn't go over well. But you have to tell them the truth with enough tact that they can hear it.

If you've been communicating all along, if you've been documenting the consequences of their decisions, then nothing should come as a surprise. "In this meeting we said this. In that meeting we said this. Here we are, reaping what we've sown."

It is what it is.

Breaking the Pattern

The firefighting trap is real because the rewards are immediate and visceral. You feel productive. You feel needed. You feel like a hero.

But a year from now, you'll look back and realize you spent twelve months running in place. The same problems keep coming back because you never addressed the root causes. The strategic initiatives that would have actually moved the needle never got started.

The flashy guy saving the day at 2 AM gets celebrated. The quiet professional who would have prevented the 2 AM incident doesn't.

That's the system. I don't know how to fix it at an industry level.

But I know this: if you're deep in firefighting mode right now, come up for air as soon as you can. Stop the bleeding, then step back and ask what's actually causing all this blood loss.

Otherwise December will arrive and you'll have nothing to show for it but a collection of heroic war stories about fires you put out.

Fires that never should have started in the first place.