21 / 57 · 21 Communication & Stakeholder Management · Saying No to Releases← prev⊞ allnext →☰ Read as one page
3.5Escalation Patterns
When to Escalate and to Whom
| Situation | First Escalation | If Unresolved |
|---|---|---|
| Critical bug, team disagrees on severity | Engineering Manager | Director of Engineering |
| Security vulnerability, team wants to ship anyway | Security Lead | CTO / CISO |
| Compliance issue | Compliance Officer | Legal / VP of Engineering |
| Team pressure to skip testing | QA Lead / Engineering Manager | VP of Engineering |
| Release decision above your pay grade | Your direct manager | Let them escalate further |
Escalation Principles
- Escalate the decision, not the blame. "We have a disagreement about release readiness and need someone with broader context to make the call" is appropriate. "The developers are trying to ship broken software" is not.
- Bring the data with you. Never escalate without the evidence package -- the bug list, the impact assessment, the alternatives.
- Escalate early, not late. Raising a concern at 2 PM gives options. Raising it at 11 PM when the deployment is in progress gives none.
- Document the escalation. Send a follow-up email: "As discussed, I raised concerns about issues X, Y, and Z. The decision was made to proceed with the release. I have documented the known issues and the mitigation plan in [link]."