Your team doesn't have an incident problem. It has a firefighting culture. Here's how to recognize the loop, rebuild trust, and stop recurring incidents from defining the organization.

Every engineering team has lived some version of this: something breaks, someone restarts it, everybody holds their breath, and two hours later the same thing breaks again. The incident isn't the problem. The loop is.

I spent two years inside a healthcare engineering environment where firefighting had become normal. A 70-person incident chat. Constant escalations. Developers who were technically excellent but operationally exhausted. Trust between engineering and the business slowly disappearing.

What finally changed things wasn't a single technical fix. It was realizing the organization itself had adapted to instability.

This talk walks through the concrete changes we made: how we rebuilt communication during incidents, how we stopped rewarding panic-driven behavior, how we redesigned escalation paths so problems reached the right people before becoming crises, and how post-mortems became less about blame and more about rebuilding trust across teams.

Along the way, we learned something uncomfortable: recurring incidents are often symptoms of deeper organizational patterns — alert fatigue, unclear ownership, escalation driven by anxiety instead of severity, and teams solving problems tactically while the surrounding system keeps recreating them.

You'll leave with practical ways to recognize whether your team is stuck in reactive mode, how to diagnose the patterns underneath recurring incidents, and what early recovery actually looks like before the metrics improve.

The first real sign for us wasn't fewer incidents. It was somebody saying: "Hey... this week actually felt calm."

Target audience: tech leads, new managers, experienced managers. Topics: incident management, managing and leading teams, monitoring & observability.