Engineering Management Nugget #6: From Firefighting to Architecting

The proportion of time a team spends firefighting — responding to incidents, fixing urgent issues, and reacting to last-minute escalations — is an important signal for an EM. While some level of firefighting is inevitable, living in this mode usually points to deeper system gaps.

Firefighting often feels productive because problems get solved quickly and it feels like we saved the day. However, firefighting pulls effort away from planned work and slowly builds a heroic culture. Over time, constant firefighting hides root causes such as:

• unclear requirements and expectations
• weak ownership
• lack of in-depth system knowledge
• missing or fragile processes

The cost eventually shows up as burnout, fragile delivery, and repeated issues.

An EM can influence this by architecting the system to keep firefighting at a minimum.
This is not about designing code — it’s about designing how work flows through the team.

This includes:

• clear ownership and responsibility boundaries
• predictable planning and review cycles
• explicit decision-making frameworks
• shared definitions of “done” and quality
• guardrails that prevent common failure modes

The goal is not to eliminate problems, but to make them visible earlier and easier to handle.

How This Works in Practice

• Track recurring incidents and ask why they repeat
• Invest time in preventing the next failure, not just fixing the current one
• Use retrospectives to adjust systems, not assign blame
• Gradually shift time from urgent tasks to structural improvements

Takeaway

Firefighting solves today’s problem.
As systems improve through thoughtful architecting, emergencies reduce — and when they do happen, time and effort are used more effectively.