The Two Conversations Happening During Every Major Incident - And Why One of Them Is Being Ignored

Every major incident involves two conversations happening simultaneously.

The first is the one inside the room. Engineers diagnosing the problem. Teams coordinating across Slack channels. The incident commander working through the technical response. This conversation is intense, focused, and consuming every available unit of attention from the people involved. It is also the conversation that is visible - the one that feels like the work.

The second conversation is the one outside the room. Clients who can't access a service they depend on and don't know why. A customer service team fielding calls with no information to give. A CEO being asked by a board member what is happening and having no answer. Stakeholders forming their own conclusions in the absence of information from the people who actually know.

This second conversation happens whether you participate in it or not. The difference is whether you shape it or whether it shapes itself without you.

In most incidents I've been involved in or close to, the second conversation is being almost entirely ignored while the first one is happening. And the damage it causes is frequently larger, and longer lasting, than the technical incident that started it.

What the Silence Sounds Like From the Outside

I want to describe what a major incident feels like from the client's perspective. Not from the engineering team's perspective - from the person on the other side who is trying to run their business and finding that a service they depend on is not working.

At first, there is confusion. Is this a problem on their end or yours? They check their own systems, restart things, try again. Time passes.

Then there is the realisation that it's not them. The service is down. They try to contact your support team. The line is busy, or the response is slow, or the person they reach has no information to give them.

More time passes. Still no communication from you. They start to wonder whether you know about the problem. Whether anyone is working on it. Whether they should be making alternative arrangements. Whether they should be informing their own clients.

If they have a relationship with someone senior at your company, they call them directly. That person - your CEO, your account manager, your founder - is now fielding a client call about an incident they may not have been briefed on. That conversation does not go well.

By the time your first communication reaches them - even if the incident has been technically resolved - they have spent an hour or more in that silence. And the silence has already told them something. It has told them that when something goes wrong, they won't be kept informed. That they'll have to chase. That the communication, in a crisis, is not something your company has under control.

That conclusion is very difficult to reverse with a competent technical resolution.

What Was Happening in the Room During That Silence

I want to be fair to the engineering team here, because the silence is almost never deliberate. It is the predictable consequence of a structural problem.

The people who have the information - the technical team running the incident - are completely absorbed in the work of resolving it. Every minute spent writing a client communication is a minute not spent on the fix. The instinct, which is entirely understandable, is to fix first and communicate after.

The problem with that instinct is that the second conversation doesn't wait. It proceeds in real time, with whatever information is available - which is none. And none, as I've described, is its own form of communication. It communicates absence, disorganisation, and loss of control, regardless of what is actually happening in the engineering team.

The only solution to this is structural. Communication cannot be an afterthought that happens after the technical work. It has to be a parallel workstream that runs simultaneously and is owned by a separate person from the moment the incident is declared.

That person's job is not to resolve the incident. Their job is to make sure the second conversation - the one happening outside the room - is being shaped by accurate, calm, structured information from your side rather than by anxiety and assumption from theirs.

What a Good Incident Communication Plan Actually Looks Like

The communication conversation requires: a clear picture of what clients need to know at what intervals, pre-written templates that can be adapted quickly rather than drafted from scratch under pressure, and someone with the authority to send communications without requiring sign-off from the incident commander, who is busy running the technical response.

It also requires a decision, made in advance, about what the communication looks like at different stages of the incident.

At fifteen minutes: an acknowledgement. We are aware of the issue. We are working on it. We will update you at [time]. That communication does not require a resolution. It does not require a root cause. It requires only the honesty to say that something is wrong and someone is on it.

At thirty minutes: a brief update. What we know so far. What we're working on. When the next update will come. Still no resolution required - just evidence that the situation is being actively managed.

At resolution: what happened, what was fixed, what we're doing to prevent recurrence. Clear, plain language. No technical detail the client doesn't need. An acknowledgement of the impact. A point of contact for any follow-up questions.

That structure - fifteen minutes, thirty minutes, resolution - is not complicated. It is also almost never in place in organisations that haven't deliberately built it.

The Relationship Cost of Getting This Wrong

Client relationships in B2B environments - which is the space most companies of 15 to 200 people operate in - are built on trust. Specifically, on the trust that when something goes wrong, the supplier will handle it professionally. That the client will be informed. That the situation will be managed.

A major incident is a test of that trust. The technical resolution is one part of the test. The communication is another, and arguably the more important one - because the client cannot evaluate the quality of your engineering response, but they can absolutely evaluate the quality of your communication.

Companies that communicate well during incidents - that keep clients informed, that are honest about what they know and don't know, that structure their updates calmly - frequently come out of major incidents with stronger client relationships than they went in with. The incident revealed that the company handles pressure well. That is a meaningful and positive data point for a client.

Companies that go silent - that leave clients to form their own conclusions, that send a first communication only after the incident is resolved - frequently find that the technical resolution is not sufficient to repair what the silence damaged.

The second conversation is happening. The only question is whether you're in it.

Frequently Asked Questions

What should an IT incident communication plan include?

An effective incident communication plan covers: who is responsible for client communication (separate from the technical team), pre-written acknowledgement and update templates, a defined timeline for updates (15 minutes, 30 minutes, resolution), an escalation path for internal stakeholders including senior management, and a clear sign-off process that doesn't require the incident commander's approval.

How quickly should you communicate with clients during an IT outage?

Within 15 minutes of declaring an incident. This does not require a resolution or a root cause - it requires an acknowledgement that you are aware of the problem and working on it, with a commitment to the next update. The speed of the first communication matters more than its content.

What should an outage communication template say?

A basic outage acknowledgement should include: a clear statement that you are aware of the issue, confirmation that the team is actively working on resolution, a time for the next update, and a contact point for urgent queries. Avoid technical jargon, speculation about causes, and promises about resolution times you cannot guarantee.

Why is silence during an outage so damaging?

Because clients interpret silence as disorganisation. In the absence of information from you, they form their own conclusions - and those conclusions are almost always worse than the reality. A client who receives a calm, structured acknowledgement within 15 minutes is in a fundamentally different emotional position from one who has heard nothing for 90 minutes. The technical resolution is the same; the relationship impact is not.