A few years ago, I faced a very typical situation. I was running my team’s day-to-day rituals, but at the same time someone in leadership decided I was the best candidate to make a deep investigation on a tool. The research would have benefited from deep context about our code (context I did not yet have) but apparently nobody else was a good fit for the task. Then, as if that was not enough, a project budget was cut in half and I had to descope work, reorganize the team and try to mitigate the budget limits.

It almost seems like one problem comes with another one.

The inevitable crisis

Ever wondered when, as a manager, you become the one putting out all the fires, as if nobody else is doing the same thing? You're not alone. Literally, a lot more people are in the same position as you, even in the same company.

It comes in many shapes: a crash in production, an impossible deadline, an investigation nobody picked up, a project that went out of budget, it could even be a real fire in your data center. "Everyone, stop right there, shift the focus to whatever is the emergency".

Except sometimes everyone means you. It may sound unfair, but people tend to rely on the same people that already solved a similar problem before.

"The reward for toil had been more toil. If you dug the best ditches, they gave you a bigger shovel." Terry Pratchett, Carpe Jugulum

Obviously, it's not your fault (at least most of them, right?), but you're the one accountable for the success, so in essence, you become the point of contact for them. So, let's get to work.

There's always another fire

Solve the fire. Good, time to rest. Except you don't know how, but there's another one waiting for you. Best case scenario, they go one after the other. Worst case, you have a few at the same time. Many of them will even require urgent meetings with people more knowledgeable in the topic than you, but it almost feels like all the problems point to you.

Most will require you to juggle a few priorities at the same time.

Everything is critical

Your manager will probably come to you to tell you a few of those emergencies. They have more visibility after all when a new problem comes from other departments.

But actually, some urgent problems will raise from your team reports as well. If almost feels like you're in the middle of a crossfire, right?

Being the default firefighter is exhausting. It is not a sign that you are indispensable; more often, it is a sign that ownership, context, or escalation paths are unclear.

Stop putting out, start preventing

Framing what's critical from what's not

Not every urgent request is important, and not every important problem is urgent. When someone arrives with adrenaline and a deadline, it is easy to inherit their sense of urgency.

Instead of reacting immediately, run the problem through FIRE:

• Fact-finding: What do we actually know? Is it verified, measured, and clearly defined?
• Impact: Who or what is affected? Does it affect customers, revenue, safety, reputation, or a critical path?
• Risk: Is it getting worse? Could it cascade? What is the cost of waiting?
• Escalation: Can your team handle it, or do you need specific expertise, more capacity, or leadership visibility?

The goal is not to build a perfect analysis. It is to replace panic with a decision. Sometimes the answer is: contain it now, investigate tomorrow. Sometimes it is: this is serious, but it can wait until the next planning cycle. And sometimes it is: we need help now, so escalate.

Then make the decision visible. “We will stabilize this today and schedule the root-cause work for Thursday” is much better than silently absorbing another emergency. If everything is critical, nothing is.

Overcommunicating

Firefighting fails quietly when people assume someone else has the context. Overcommunicate the state of the emergency: what is happening, who owns it, what has been tried, what the next checkpoint is, and what you need from others. Use short, repeated updates rather than trying to send one perfect message. A good cadence looks like:

At the start: "Production errors are elevated for EU customers. Maria is investigating; no customer data appears affected. Next update in 30 minutes."

While it's happening: "We identified a bad deploy and rolled it back. Error rates are recovering. We'll confirm stability at 16:00."

After it's under control: "Service is stable. Root cause was X. Follow-ups are A, B, and C, owned by Y, due by Z."

This does three things: it reduces duplicate investigation, prevents stakeholders from inventing worse narratives, and makes ownership visible. It also gives you an exit ramp: when the update says the incident owner is someone else, people stop routing every question to you.

Finally, communicate the trade-offs. If preventing the next fire means delaying a feature, say so early and plainly. Managers who hide the cost of reliability work end up paying for it during the next outage.

Taking advantage of new fires

Every fire is expensive, but it is also a diagnostic. Something in your system, process, ownership model, or communication allowed it to happen. Treat the aftermath as an investment opportunity.

After the immediate pressure drops, run a blameless postmortem:

• What was the earliest signal, and why did we miss it?
• Which alert, runbook, test, or decision would have prevented or shortened it?
• Who had the context to fix it, and were they empowered to act?
• What recurring pattern does this reveal?

Then convert findings into small, owned improvements. Add the missing alert. Write the runbook. Fix the flaky deployment step. Clarify who owns on-call for that service. Automate the manual rollback. None of these will make headlines, but together they reduce the number of times you get called.

Most importantly, delegate the follow-up. If the person closest to the problem owns the prevention work, they gain context and agency (and you gain a team that can handle the next one without you).

The best managers are not the ones who extinguish the most fires. They are the ones who make the organization less flammable.

When the next fire starts

Remember, next time a fire starts:

1. Run FIRE before committing the team.
2. Assign an owner who is not automatically you.
3. Contain first; schedule the real fix.
4. Communicate status, ownership, and the next update.
5. Once stable, turn the cause into one owned prevention improvement.