How to escalate a blocked project without surprising the founder
By Alice Huang, Chief of Staff and operator
Raise a blocked project with facts, impact, options and the decision needed. Separate uncertainty from confirmed delay.
An escalation should make a decision easier. It should not leave the founder asking what you need from them.
Atlassian's dependency guidance names risks, owners and feedback loops. DACI separates who drives a decision from who makes it. Use those distinctions before blocked work becomes a surprise.
Check the actual blocker
Is it missing information, access, capacity, a dependency or a decision? Confirm the current state with the owner. Do not escalate yesterday's status after someone has fixed it.
Record evidence, affected work and the date checked. If a delay is possible but not confirmed, say so. Separate the problem from the worst outcome you can imagine.
Bring a complete request
- Situation: what is stuck and since when.
- Impact: affected work and real time constraint.
- Attempts: what has been tried.
- Options: feasible choices and tradeoffs.
- Recommendation: what you suggest and why.
- Decision: who needs to make which call.
If there is no safe recommendation yet, name the information needed. Do not turn a guess into confidence to shorten the memo.
A fictional escalation
"The pilot cannot start because data access is not approved. The access owner confirmed this today. We can wait or test with an approved synthetic dataset. I recommend the synthetic test for the questions it can answer, without treating it as proof of live readiness. Please confirm the path."
This is invented, not a client event. It separates an approval gap from a technical failure.
Close the loop
Record the decision, inform the appropriate people and update the plan. Give next actions owners. If cost or scope changes, get the required approvals rather than treating escalation as blanket permission.
Raise the issue early enough to preserve options. Match the weight of the message to the actual risk.