Many new engineering managers spend 90% of their time firefighting and 10% actually leading.
If your day starts with a flood of Slack messages and ends with a sense you’ve achieved nothing but survival, you’re not alone.
The good news? Firefighting isn’t inevitable.
You can create space to think strategically, support your team, and actually lead.
The problem with firefighting
When I first stepped into engineering management, I felt like a firefighter-in-chief.
Urgent pings, last-minute requests, production bugs - everything came to me.
I worked long hours, solved problems on the spot, and thought I was doing the right thing.
But:
- My team wasn’t growing - they were waiting for me to fix things.
- I was constantly exhausted and reactive.
- Long-term improvements never happened because I was stuck in short-term chaos.
This pattern is common for new leaders, especially when they’ve been promoted from individual contributor roles.
You know how to fix things technically, so stepping in feels natural.
But it stops you doing the real job of a manager: building systems that prevent the fires in the first place.
Lessons from The Phoenix Project
In The Phoenix Project, Gene Kim describes four types of work:
- Business Projects – planned work with clear value.
- Internal Projects – things like automation, refactoring, or upgrades.
- Changes - normal and standard changes that need to be carried out frequently.
- Unplanned Work – firefighting.
The book makes one thing very clear:
“Unplanned work is the silent killer of productivity.”
When unplanned work dominates, you:
- Miss delivery commitments.
- Neglect internal improvements that would reduce future fires.
- Burn out yourself and your team.
Eric, a mentor figure in the book, tells Bill that to manage effectively, he must understand the type of work Brent should work on based on business objectives - and protect Brent’s time.
Every team has a “Brent” - that go-to expert everyone depends on.
If you don’t actively manage their workload, they become a bottleneck and fires keep spreading.
Applying it in practice
When I managed squads, firefighting was a weekly reality.
Our “Brent” was constantly pulled into urgent requests.
Without realising it, the entire delivery system was built around them.
Here’s what worked for us:
1. Visualise unplanned work
We added a dedicated column on our board for urgent issues.
This wasn’t just a tracking tool - it gave us data.
After two sprints, we saw that over 40% of our time was spent on unplanned tasks.
When you make the invisible visible, it’s much easier to:
- Push back with stakeholders using data.
- Justify time for internal projects.
- Spot repeat offenders causing the chaos.
2. Protect key people
Just like in The Phoenix Project, we identified our “Brent.”
We rotated triage duty so no one person became a permanent bottleneck.
- One person per day was on point for urgent issues.
- Everyone else focused on planned work without interruptions.
- If triage wasn’t needed, they just got extra focus time.
This simple rotation reduced context switching and gave our expert breathing space to mentor others instead of always being in fire mode.
3. Clarify priorities
Often, firefighting happens because everything feels urgent.
We introduced a simple rule for intake:
If it disrupts planned work, we need to know:
- The impact (user, revenue, reputation).
- The deadline (what happens if it’s not done now).
- The trade-off (what planned work stops to make space).
This created healthier conversations:
- Instead of “Can you just…” we heard,
“This will delay feature X by one sprint. Is that acceptable?”
4. Create agreements in calm moments
Firefighting is emotional.
The time to set rules is not when everything is on fire.
We held a retro focused solely on interruptions and created a one-page Working Agreement.
Example agreements:
- Slack messages after hours are scheduled for the next morning unless Sev-1.
- No “drive-by” requests; everything goes through the board.
- Meetings must have a decision owner and agenda, or they get declined.
This wasn’t about bureaucracy - it was about reducing conflict by deciding together, in advance.
The identity shift: from fixer to designer
The hardest part wasn’t the process changes - it was me.
As an engineering manager, I felt valuable when I personally solved problems.
NLP helped me reframe this belief:
Old belief: “I’m valuable when I fix things.”
New belief: “I’m valuable when I design a system where my team fixes things.”
That shift was freeing.
It allowed me to step back, coach my team, and focus on building an environment where they could succeed without me hovering.
A 7-day starter plan for new managers
- Day 1: Add a visible column for unplanned work to your board.
- Day 2: Identify your “Brent” and discuss triage rotation.
- Day 3: Block two 90-minute focus sessions for yourself each week.
- Day 4: Agree on intake questions for urgent requests.
- Day 5: Hold a short retro to surface frustration points about interruptions.
- Day 6: Draft a one-page Working Agreement together.
- Day 7: Reflect: what changed? What can you keep, kill, or tweak?
Final thought
Firefighting feels heroic in the moment.
But over time, it burns out teams and stops you from doing the work that really matters.
By applying lessons from The Phoenix Project — visualising work, protecting key people, clarifying priorities, and creating shared agreements — you can flip the ratio:
- Less firefighting.
- More leadership.
- A healthier, more resilient team.
Want to reduce firefighting in your team?
I coach tech managers to build systems and mindsets that prevent chaos instead of just reacting to it.
→ Book a free 15-minute discovery chat
Or email me: [email protected]
Supporting tech managers to lead better teams.