Leaders must not ignore alarms

Ignoring a fire alarm does not put out the fire. As leaders, we must never ignore an alarm.

Topics:

- Over the years, I often encounter this weird behaviour of teams deciding to disable alarms, rather than fixing the root causes of those alarms.
- The classic example of this anti-pattern is the disabling of unit tests on a software build, because one or more of those tests are failing.
- Rather than taking the time to fix the code that is breaking the test, the team decides to disable the tests instead in order to push the release through.
- I witnessed another example recently, when a team decided to disable a security layer on an API, because a client did not support the required protocol.
- Rather than waiting until the client was fixed, they disabled the security on the server side, which was complete madness!
- So why do team feel pressured into carrying out such poor decisions?
- There can be a number of reasons:
1. They are under pressure to hit a deadline, no matter what.
2. They are undervaluing quality.
3. They don’t understand the root cause of the issue causing the alarm.
4. They don’t feel enabled to delay a release because of quality issues.
- On occasion, it can be valid to disable an alarm because the alarm itself is no longer required, or no longer relevant. But in general there needs to be SOME alarms in place.
- Apart from automated alarms like unit tests or production monitoring systems, there is another major source of alarms: people!
- Everyone in your team should feel enabled to raise the alarm on any given topic that causes them concern.
- If they bury or ignore their concerns instead, those issues can take on a life of themselves, and grow into much bigger issues down the line.
- I also encourage my team to raise red flags whenever they spot them, to reduce the amount of blind spots I have.
- Rather than “shooting the messenger”, you need to encourage people to report issues, in an open environment that is free of blame.
- If you think about the metaphor of a ball rolling off a table in a meeting room, with a group of people watching it, there are three possible reactions:
1. Some will ignore the ball and let it fall.
2. Some will raise the flag, and ask “who owns the ball?”.
3. Some will grab the ball to prevent it falling, regardless of ownership.
- Category 3 people are potential leaders, category 2 are raising the alarm, while category 1 are sadly all too common, but you don’t want those guys in your team if you care about performance.
- The bare minimum response to witnessing an issue is to raise an alarm, and the bare minimum response from a leader is to not ignore the person raising the alarm, but instead to thank them and identify corrective actions.
- Alarms are there to warn us of unexpected, exceptional outcomes: ignoring such outcomes for too long will lead to failure.

Episode link: https://techleader.pro/a/696-Leaders-must-not-ignore-alarms-(TLP-2025w23)

#leadership #tech #leader #team #management #manager #teamlead #techlead #software #stoic #stoicism #risk #monitoring #alarms