Send a Status Update or Escalate? Make the Needed Decision Visible

A status update tells people where work stands. An escalation asks someone with the necessary authority or resources to help resolve something the current team cannot settle. If the second is hidden inside the first, a manager may read “waiting on approval” as background information while the team expects a decision.

Make the purpose explicit. “Here is the current position” and “We need a choice between these options by Tuesday” give the reader different jobs. The same message can contain both, but the request should not depend on the recipient discovering it between routine progress notes.

First identify why the team cannot resolve the issue

Not every difficulty needs escalation. A team may be able to choose the next step within its normal authority. It may instead need information, a colleague's response, a priority decision, or permission to change an agreed commitment. Naming the missing element helps route the message.

GOV.UK's governance guidance emphasizes knowing the boundaries of team decision-making and who can help beyond them. The practical question is therefore not “How senior is the person we can copy?” It is “Who can make the decision or provide the resource this work needs?”

An escalation about competing priorities should reach someone who can decide priorities. A request to correct a factual detail may belong with the person who owns that fact. Sending every issue to the same manager can slow work if they then have to find the actual decision-maker.

Compare two versions of the same message

Suppose an internal guide cannot be released until a department confirms its contact details. A routine update says: “Draft complete. Awaiting department review. Release at risk.” That may accurately describe the situation, but it leaves the next action unclear.

A more useful decision request says: “The draft is complete, but the contact details remain unconfirmed. To release Friday, we need the department owner to confirm them by Wednesday. If that cannot happen, please decide whether to move publication or release the agreed sections that do not depend on those details.” This fictional example names the obstacle and the choice without assigning blame.

The alternatives still need to be feasible and within the recipient's authority. Do not offer a reduced release if it would omit essential information, and do not imply that a missing check can simply be ignored. The point is to expose a real decision, not manufacture a convenient option.

Our guide to an estimate and a deadline commitment explains why the dates and deliverables should be explicit before the message is sent.

Include enough context to decide

A concise escalation usually needs four things: the blocked outcome, the reason the current team cannot resolve it, the consequence of waiting, and the decision or help requested. Add relevant evidence and realistic options when those help. The recipient should not have to reconstruct the whole project to understand the request.

Avoid vague urgency. “Urgent” does not say what will happen if the decision arrives tomorrow. A concrete response point and consequence let the recipient assess priority. If the issue involves safety, security, or another established incident process, use that process rather than waiting for an ordinary project update.

Distinguish facts from forecasts. “The review has not arrived” is a current fact. “The release may move” is a forecast that depends on what happens next. Keeping those separate makes the request easier to evaluate and prevents a possibility from sounding like an event that has already occurred.

Keep ownership after asking for help

Escalating does not necessarily transfer all responsibility. The original owner may still need to assemble information, follow the response, and implement the agreed next step. State who is coordinating the issue while the decision is pending.

The distinction between one accountable owner and rotating coordination matters here. A coordinator may send the message and track the response without having authority to accept a changed commitment. Make that boundary visible so an acknowledgement is not mistaken for approval.

Also decide what happens if no response arrives. Use the team's agreed follow-up route rather than silently treating an unanswered message as consent. A reminder should link to the existing request and explain the current consequence, not restart the conversation with a new set of assumptions.

Close the decision back into ordinary reporting

Once a decision is made, record what changed and who owns the next action. If the team moves the release date or narrows the scope, keep a short decision record. The next status update can then show progress against the revised agreement.

GOV.UK's reporting guidance frames reporting as support for useful decisions and an accurate view of progress. A copied list of unresolved warnings is less useful than a clear account of which decisions are pending and which have been settled.

Review recurring escalations too. If the same routine decision repeatedly exceeds the team's authority, there may be an unclear boundary or missing delegation. If the same information is always absent, the request process may need improvement. The immediate message resolves today's obstacle; a later process change may prevent the next one.

Choose a status update when people need awareness. Make an explicit escalation when work needs a decision or resource beyond the team's reach. In either case, tell the reader what action, if any, is expected from them.