After a serious mistake, I want two things to be true: people can tell me what happened, and they know they are responsible for what happens next.

I know how difficult that can be. I’ve been exhausted and frustrated, personally writing code to get things working again, and thinking: “I’m a senior leader. Why am I the one fixing this?” I was willing to help. I was also upset about how much of the recovery had fallen to me, and I wasn’t at my best.

Even as I write this, I’m catching up on sleep and finding the calm I need to debrief properly. The concerns still need to be addressed. I want to be rested enough to understand what happened and fair enough to hear the answers.

When you feel that way, it is easy to take over because it feels quicker, soften the message because someone is already upset, or make your disappointment so clear that the person spends the meeting trying to survive it.

None of those responses necessarily helps them become better at the work. The question I want to keep in front of me is: when the next problem starts forming, will this person recognise it, act on it, and tell me early?

Make it possible to bring you bad news

While service is disrupted, help the response. Keep people informed, make room for the people who can fix it, and contribute where you are useful. The conversation about how the team got there can wait until the immediate pressure has eased.

What cannot wait is your reaction to the truth. If someone admits they do not understand a system, that is information you need. If you humiliate them for saying it, you may get a more reassuring answer next time. You will not necessarily get a more reliable system.

Simon Sinek’s writing on the Circle of Safety puts trust and mutual support at the centre of leadership. The application I take from that is practical: I want people to spend their effort dealing with the problem, rather than managing my reaction to it.

That still leaves room for disappointment, concern, and a difficult conversation. People should be able to admit a gap without being written off. They should also expect us to do something about the gap.

Work out what you are actually asking them to change

A serious outcome does not, by itself, tell you whether someone was careless. A small mistake in a fragile system can have an enormous impact. A long-standing failure to prepare can produce the same result. Those situations need different responses.

Start with the facts: what did they expect to happen, what did they understand, what checks existed, and when did the uncertainty become visible? Google’s guidance on postmortems is useful for examining the conditions around a failure and turning the findings into concrete improvements.

Then ask three separate questions. Did they know what was expected? Were they equipped to meet it? Did they follow through on what they had agreed to do?

If the expectation was unclear, make it explicit. If capability or capacity was missing, arrange training, help, or a decision about priorities. If someone understood the responsibility, had reasonable support, and repeatedly left it unattended, say that plainly. Another general request to “be more careful” will not resolve it.

I need to include myself in those questions. Did I accept confident updates without looking at the work? Did I call something a priority while filling every available hour with something else? Did I leave a known gap unresolved because we had not yet had an incident?

A leadership reflection with two dimensions: practical support and clear expectations. With neither, people are left to guess. Support without clear expectations offers comfort without progress. Clear expectations without support create pressure without help. Combining both helps people face the gap and agree how to close it.
Where does your response land?

Have the conversation you may be avoiding

Once you understand the facts, talk privately and be specific. Do not ask someone to guess the seriousness of your concern from your tone. Name the impact, the responsibility, and the gap between what was expected and what happened.

For a hypothetical service that the team could not recover, I might open with:

“People depend on this service, and we were not ready to recover it. You are responsible for keeping it operable. I want to understand what got in the way, and agree on what needs to change.”

Then listen. Do not turn the question into a pause before the speech you already prepared. There may be facts that change your judgement. There may also be explanations that clarify the failure without excusing it.

The next part needs commitments from both sides: “What will you do differently? What help do you need from me? How will we know the gap is closed?” Agree on the work, a realistic date, and what the team will demonstrate.

It is reasonable to say, “I believe you can meet this expectation, and the current arrangement is not good enough.” Belief in someone should give you a reason to invest in their improvement. It should not require you to pretend the improvement is optional.

Help without quietly taking the job back

Sometimes you do need to step in. I would rather help restore a service than protect a neat division of responsibilities while people cannot work. But once the immediate need passes, the work has to return to the people responsible for it.

Sinek makes a useful distinction between assigning tasks and assigning responsibility. If every meaningful decision comes back to the leader, the team can end up waiting for instructions even while carrying the title of owner.

My job is to help them become capable of making those decisions. That might mean working through the repair together, making time for training, or bringing in expertise. Then I want the team to explain the design, test the safeguards, and practise recovery with another capable person.

“The documentation is updated” tells me an activity happened. Seeing someone use it to recover the service tells me much more. In security work, that demonstration should happen in an appropriate test environment, with boundaries that protect live operations.

If I keep fixing every difficult part myself, I should not be surprised when the team continues to need me for every difficult part.

Let follow-through rebuild confidence

An apology matters. So does the effort people put into recovery. Neither settles whether the underlying responsibility is now being met.

Look for changed behaviour: uncertainty raised earlier, agreed work completed, checks that hold up, and more than one person able to operate the service. Give credit when you see it. People need to know that a mistake does not permanently disqualify them from your trust.

If commitments keep being missed despite clear expectations and reasonable support, the response needs to change. That may mean closer oversight, a different assignment, or a formal performance conversation. Be fair, be private, and be clear about why. The rest of the team should not have to keep carrying an unresolved gap.

I want to be a leader who stands beside people on a bad day. I also want them to leave the conversation knowing what they own, what help they can count on, and what they must do next.

The best outcome is a team that can handle more without you, and still knows when to call you.

References & further reading

Primary guidance for the concepts and controls discussed here.