Senior stakeholders do not need real-time updates on normal release turbulence. They need to know about unplanned impact. Those are different things, and confusing them is expensive for everyone involved.
In my previous role, I was the person deciding whether to escalate to senior management at 6.54am on a payment page release morning, when the logs were showing errors and nobody yet knew what they meant. I waited. It was the right call. But it did not feel obvious at the time, which is why I wrote down the framework I used, and why I have applied it the same way ever since.
The message senior stakeholders want is not “there are errors but it is probably fine.” It is “it resolved at 7.18am with no confirmed customer impact.” Those two messages arrive at different times, and the second one is worth far more.
What was actually happening
A payment page release is not a quiet event. The first 30 minutes after go-live are always noisy: cache warming, first-time requests, log entries that look alarming and mean nothing in isolation. This is not unexpected behaviour. It is planned turbulence.
The 6.54am errors were elevated response times on the payment processor callback endpoint. Not failures, elevated times. Within the range we would expect for a cold-start deployment. But the range is uncomfortable to sit with when you are watching a live graph and wondering whether to pick up the phone.
The question I was asking myself: is this release noise, or is it a real incident? And underneath that: if I escalate now and it resolves in 20 minutes, I have introduced anxiety and context-switching into someone’s morning for nothing. If I do not escalate and it becomes a real incident, I have withheld information they needed.
The two questions
I have since made this explicit as a two-question test. When I am unsure whether to escalate to senior stakeholders:
1. Is this planned or unplanned?
Elevated response times in the first 30 minutes of a deployment are planned turbulence. We knew this would happen. It is in the deployment runbook. It does not need to go anywhere. Downtime that takes the payment page fully offline is unplanned. That escalates immediately, regardless of how confident I am that it will resolve quickly.
2. Is there confirmed customer impact right now?
Not theoretical impact. Not elevated error rates that might correlate with customer impact. Confirmed, measurable customer impact: failed transactions, a checkout abandonment spike, support tickets arriving. If the answer to both questions is yes, unplanned and confirmed customer impact, escalate immediately. Not when you know the cause. Not when you have a fix. Immediately, with what you know.
If the answer to either question is no, hold, monitor, and set yourself a resolution checkpoint. Ours was 7.30am. If it had not resolved by then, the conversation was happening regardless. It resolved at 7.18am.
What holding actually looks like
Holding is not passive. In the 24 minutes between 6.54 and 7.18, I was monitoring the error rate and response time graph in real time, confirming there were no failed transaction alerts in the support queue, keeping the developer who ran the deployment updated, and writing the escalation message I would send if I needed to, without sending it.
That last point is worth keeping. If you are preparing the escalation message, you are forcing yourself to articulate what you actually know and what you do not. Often that process makes it clearer that you are not ready to send it yet. You do not have enough to give them something actionable. Writing the message is a useful diagnostic, not just a contingency.
The message I sent at 7.20am was: “The release completed cleanly. We had elevated response times in the first 30 minutes, consistent with a cold-start deployment. Resolved at 7.18am with no confirmed customer impact. Full summary to follow.” That message took 30 seconds to send, and it was the only one they needed.
Why senior stakeholders thank you for this
The instinct to over-communicate comes from a legitimate place. You do not want to be the person who withheld information. You want to be seen as on top of things. But a 7am message that says “there are some errors but it is probably fine” does something specific to a senior stakeholder: it makes them anxious without giving them anything to act on.
They will ask questions you cannot answer yet. They will spend the next hour checking in. You have created work and worry in equal measure, and the situation has not changed.
Google’s Site Reliability Engineering framework makes a useful distinction here between incident management and incident communication: the people managing the incident need different information at different cadences from the people who need to know about business impact. A senior stakeholder on a release morning is not part of the incident team. They are a business impact receiver. Give them business impact information when you have it, not technical updates as you go.
The broader principle
This framework applies beyond release day. Any time you are managing a situation that might require escalation, the same two questions apply: is this planned or unplanned, and is there confirmed impact on something that matters to the person you are considering telling?
If you can answer both clearly, you know what to do. If you cannot answer both clearly, you are probably not ready to escalate yet, and the right move is to find out before you pick up the phone.
Communication discipline under pressure is not about withholding information. It is about giving the right information to the right person at the right moment. That is a skill, and it is one that senior leadership notices, usually because they have experienced enough of the alternative to know the difference.
TL;DR: Before escalating to senior stakeholders on release day, ask two questions: was this planned, and is there confirmed customer impact right now? If yes to both, escalate immediately with what you know. If not, monitor, set a checkpoint, and prepare your message before you need to send it. The message that builds trust arrives after the situation resolves, not while it is still unfolding.
Written by Delphine Ragazzi, Product Owner with 20 years in digital product, analytics, and CRO.
