Mission blocker response: what should happen next?

A project lead moving task cards across a planning board

A mission blocker response starts by classifying the blocker as a question, dependency, budget envelope, or external wait. Assign its owner, SLA, and escalation path; record the decision that un-halts the mission.

What does a mission blocker response start with?

Start with the work that cannot proceed. State what is missing in terms that someone else can act on. A label such as delayed or waiting does not say what needs to happen next.

Then classify the blocker. A question is something only you can answer. A dependency means another piece of work or another person’s action must happen first. A budget-envelope blocker means the work cannot proceed within the available budget limit. An external wait means progress depends on a response or action from outside the team.

The type helps identify who needs to act next. Do not treat a dependency as a question, or an external wait as a budget problem. That can send the work to someone who cannot move it forward. Brainis describes these four typed blockers, each with an owner, an SLA, and an escalation path; a recorded decision un-halts the mission. See missions.

Who owns the blocker, and what should its SLA say?

Give the next action one accountable owner. Several people may need to contribute, but the team needs one person responsible for making the next step happen. Choose someone who can answer the question, resolve the dependency, act on the budget envelope, or coordinate the external follow-up. If that person cannot resolve it, their next action may be to route it to the right decision-maker.

Write down what the owner is expected to do. Resolve is too vague on its own. Name the action: provide the missing answer, confirm the dependency, seek a budget decision, or follow up on the external wait. That makes it possible to tell whether the blocker has moved.

The SLA should say when the team expects a response or next update. It is a check point, not a promise that every blocker will be cleared by then. Set it to fit the work and the decision needed. If the date passes without movement, the team should know that the blocker needs attention rather than assume it has been forgotten.

Keep the owner, next action, and SLA visible with the blocked mission. When someone reviews the work, they should not have to reconstruct who is waiting on whom.

Two colleagues reviewing a long timeline drawn across a whiteboard

When should a blocker escalate?

Agree on the escalation condition before the blocker stalls. The trigger might be an SLA passing without a response, a dependency that cannot be completed as expected, or a budget limit that leaves no workable next step. The condition should tell the owner when to raise the issue, not leave them to guess how long to wait.

Route the escalation to someone who can change what happens next. For a question, that is the person who can provide the missing decision. For a dependency, it may be the person who can coordinate the handoff or change the order of work. For an external wait, it is the person who can make or manage the follow-up. If the budget envelope prevents progress, take it to the person who can address that constraint.

An escalation is not only a notice that work is late. State what the recipient needs to decide or do, and what work depends on that action. This keeps the escalation tied to the blocked work instead of turning it into a general status update.

Brainis says every consequential action is governed by an authority contract and is auditable. For a consequential escalation, make the decision or action being requested clear, and keep the route consistent with the authority that applies. The autonomy page is where to read more about that product topic.

What decision lets the mission resume?

When the blocker clears, record the decision that addressed it. A note that says the blocker is cleared leaves the team without the reason work can move again. Record the choice or answer, who made it, and what action follows.

Name the person responsible for the next action after the decision. Also say which blocked work can resume and which parts still depend on another step. That distinction prevents the team from treating one cleared blocker as permission to restart everything in the mission.

Keep enough context for someone reviewing the mission later to understand why work moved again. If the decision changed the scope, sequence, or available budget, include that effect in the record. The record should connect the decision to the work it un-halts, rather than leaving the owner to infer what has changed.

Example: A fictional design studio has paused a client handoff because one approval is missing. The owner routes the question to the person who can approve the handoff. That person decides to approve the current draft, while leaving a later revision as separate work. The record names the approval, the next action owner, and the handoff work that can resume; it also notes that the revision still depends on later feedback.

This gives the team a usable trail: what was blocked, what decision changed the situation, and what the owner should do next. For the relationship between plans and mission work, see business plan to mission graph.

A team standing around a table covered with sticky notes

What should you do the next time work stops?

Use the same response whenever work cannot proceed. Name the blocker type as soon as you can describe what is missing. Avoid leaving a blocked task under a broad status such as waiting, because that does not identify the next action.

Record one owner, the action that owner is responsible for, an SLA, and an escalation path. When the blocker is resolved, capture the decision that un-halts the mission and name what work can resume. If another step is still pending, keep that dependency visible rather than treating the whole mission as clear.

When you review blocked work, check whether the next action happened, whether the SLA or escalation condition has been reached, and whether the decision changed what can proceed. If the blocker remains, update its next action and owner rather than carrying forward an old note. If it cleared, make sure the mission record explains why it moved again.

A mission blocker response is useful when it tells the team who acts next and what changes after that action. The review is not about making every delay disappear. It is about making the pause legible, routing it to someone who can move it, and recording the decision that lets work continue.