Escalation Path
Define when a decision must escalate beyond the team — to avoid both stuck decisions and rogue decisions.
Why
Some decisions are bigger than the team — they affect other teams, the company's cost, or are irreversible. Without an escalation path, these decisions either stall (the team can't decide) or get made unilaterally (the team decides something that hurts the company). Escalation path defines the triggers (cross-team impact, cost > $10k/mo, irreversible) and the route (tech lead → architect → CTO) so big decisions get the right eyes. The art is escalating enough (not every $500 decision) but not too much (every decision going to the CTO creates a bottleneck).
When
Define once per org. Takes 1 hour. Apply to every decision at proposal time.
How
1. Define the escalation triggers: - Cross-team impact (changes an API another team uses) → architect review - Cost impact > $10k/mo → finance + architect review - Irreversible (DB, cloud provider) → principal + CTO sign-off - Affects on-call across teams → SRE review 2. Define the route: team tech lead → architect → principal/CTO 3. For each ADR, check triggers at proposal time; escalate if any fire 4. Escalation is for review, not permission — the team still writes the ADR 5. Set a SLA on escalation review (3 days) so decisions don't stall at the next level 6. Document the escalation in the ADR (who reviewed, when) for auditability
Example
ADR-023: "Switch from S3 to GCS for all storage" Triggers fired: - Cost impact: -$8k/mo (savings) but > $10k threshold → finance review - Cross-team: 4 teams use the storage abstraction → architect review - Irreversible: no (S3 API compatible, can switch back) → no CTO sign-off Escalation: Day 1: team writes ADR-023 Day 2: architect reviews cross-team impact (approves with migration plan) Day 3: finance reviews cost impact (approves) Day 4: ADR-023 Accepted, escalation recorded Without escalation: team switches, breaks 4 teams' integrations, incident.
Common Problems
- ⚠Escalating everything — the architect becomes a bottleneck and decisions stall; escalate only on the defined triggers.
Best Practices
- ✓Make escalation a review, not an approval — the team owns the decision; the escalator checks for blind spots, doesn't substitute their judgment.
- ✓Review the escalation triggers annually — as the team matures, more decisions can stay in-team; as the company grows, more need to escalate.