A major IT incident often appears on paper as a clear sequence: detect, classify, escalate, restore, review. Establish the root cause and decide what needs to improve.
Behind those steps, someone has to keep people, decisions and information moving while the situation is still changing.
This is what that work feels like from where I sit.
The first notification
It usually starts with a monitoring alert, a call to the service desk, or a colleague saying, “Something is wrong with…” followed by a system name.
While that first message is coming in, I’m already trying to establish what has failed, how many people are affected, and whether this is a routine disruption or the beginning of a major incident.
That judgement comes early, when the picture is still incomplete. Wait too long and valuable time disappears. Escalate too quickly and people are pulled away from other work unnecessarily. Experience helps, but it never removes the uncertainty.
Sometimes the working day has already started before I reach the office. Calls and messages are arriving through internal chats or Signal, and I’m mentally working through who needs to know what.
Making sense of the first minutes
The first task is to turn scattered observations into something we can work with.
What is unavailable? When did it start? Who is affected? Is there a workaround? Has anything changed recently? Are we looking at a technical failure, or are there signs of a security incident?
At the same time, people are already asking what happened and when it will be fixed.
Often, I cannot answer either question yet.
“We’re still assessing the situation. The next update will follow in thirty minutes.”
Saying that clearly, while feeling the pressure to offer more, takes practice. So does accepting that an honest update may not be the answer people want.
Bringing the team together
When we are on location, we gather in a separate room. We need somewhere to concentrate, compare findings and speak with colleagues joining remotely, without the interruptions of an ordinary working day.
From there, I coordinate three things at once:
- The investigation: who is working on what, what they need, and where decisions or dependencies are holding up progress.
- The incident log: observations, actions, decisions and timestamps, recorded while they are still fresh.
- The communication: useful updates, at agreed intervals, for people who need very different levels of detail.
The technical fix naturally attracts the most attention. Keeping the record and sending updates can look secondary while everyone is focused on restoring a service.
Yet those updates help the rest of the organisation make decisions. And afterwards, the record helps us reconstruct what happened without relying entirely on exhausted people’s memories.
Translating in both directions
The engineers and DevOps colleagues usually have the deepest technical understanding of the problem. My contribution depends on asking useful questions, understanding the impact, and explaining it in language other people can act on.
That translation works both ways.
Technical findings need to become clear updates for management. Questions from management need to become something an engineer can answer without having to untangle the question first.
Later, those hurried conversations have to become an accurate report. That means going back to check details I could not fully absorb while everything was happening.
Every “Where do we stand?” can interrupt someone halfway through a difficult line of thought. I know that. Sometimes I hesitate before asking.
But another part of the organisation is waiting to make a decision, and I need enough information to help them do it.
The engineer needs time to concentrate. The organisation needs information. I’m trying to make room for both, without becoming an additional obstacle.
When the problem grows
A major incident rarely develops as neatly as the procedure suggests.
A backup that should be available turns out to be missing. A supplier’s support line has a queue. A workaround helps one department and creates difficulties for another. Someone is halfway through a deployment when a change freeze becomes necessary.
Two people may even be investigating the same thing from different directions without realising it.
These are the moments when coordination matters: checking assumptions, making dependencies visible, and ensuring that one person’s discovery reaches everyone who needs it.
Meanwhile, the question keeps returning:
“When will it be fixed?”
A credible estimate is not always available. Giving one too early can turn uncertainty into a promise the technical team never made.
So the update becomes: this is what we know, this is what we are trying, this is the current impact, and this is when you will hear from us again.
The pressure for a deadline does not disappear just because we lack the information to give one.
I repeat what we know and try to keep my voice steady. Some days that takes more effort than others. I’m human too.
After the service comes back
Eventually, something changes. A fix works. A service responds. People can get back to what they were doing.
Sometimes we understand exactly why. Sometimes a restart restores service while leaving important questions unanswered.
The room begins to empty. Calls end. Colleagues return to their other responsibilities.
My work continues.
The timeline needs checking. The report needs writing. Technical findings need to be confirmed with the people who investigated them. There may still be work to do on the root cause and the conditions that allowed the incident to develop.
Improvement actions need owners, usually people whose workloads were already full before any of this happened.
Keeping the review constructive can be difficult when people are tired, frustrated or defensive. I’ve also been on the receiving end of raised voices. That makes an already demanding conversation harder.
A blameless review still needs clear decisions and follow-through. We need to understand what happened, what made it possible, and what we will actually change.
Then, later, the adrenaline drops.
Hours of absorbing frustration, making decisions with incomplete information, and trying to keep everyone moving begin to catch up with me.
On the way home, or later in bed, I replay conversations. Was there a question I should have asked sooner? Did an update leave too much room for interpretation? Could I have given someone more space to concentrate?
By the next morning, the working day has moved on.
Sometimes my head has not.
Why I’m writing this
Incident management is often explained through workflows, priorities and response times. Those things matter. They also leave much of the work out of view.
There is a person coordinating between technical teams and management, carrying questions in both directions, recording decisions and trying to keep an uncertain situation understandable.
If you work with an incident process manager, a request for an update is not necessarily a sign of distrust. Often, it is how we help others make decisions and give the technical team room to work.
Please don’t shoot the messenger.
And if you do this work yourself: there should be room to talk about what it takes out of you, as well as how quickly the service was restored.