Brainforge Knowledge

escalation-standards

3 min read

Escalation standards

Purpose: This document defines how Brainforge surfaces, frames, and routes delivery risk so that issues are caught early, owned clearly, and acted on before they become surprises.

This is the operational expression of the shared standard: no surprises.

1. Literal statement

We escalate on yellow, not only on red. Escalation should be early, structured, and owned.

2. Why it exists

Healthy escalation is not a sign that the team is failing. It is a sign that the system is still in control.

The goal is not “fewer problems.” The goal is fewer surprises and better intervention timing.

3. Analogy

The strongest analogy here is a risk-managed operating environment: issues move upward while they are still manageable, not after damage has already been done.

There is also a Michelin-style lesson: the second something is off, the system should know, because the quality gate is only useful if the truth reaches it in time.

4. What good looks like

Good escalation looks like:

  • risks are raised at yellow, not buried until red
  • one person owns the escalation thread
  • facts, impact, and decision need are explicit
  • leadership hears a coherent view, not conflicting fragments
  • the escalation leads to a decision or next owner

5. Principles

5.1 Escalate on yellow

Examples:

  • capacity risk
  • slip risk
  • sponsor tension
  • dependency risk
  • feasibility change

Do not wait for the situation to become a fire.

5.2 One thread

The escalation narrative should be owned by a clearly identified CSO or SL, with internal alignment before the message fragments across multiple channels.

5.3 Facts + impact + decision

Every escalation should make it easy to answer:

  • what is true?
  • what is at risk?
  • what decision or action is needed?

5.4 Head of Delivery governs material intervention

Head of Delivery is the key approver for:

  • cross-account priority changes
  • material model changes
  • major delivery intervention

6. Escalation path

Default path:

  • IC → SL → CSO → Head of Delivery

References:

This path should not become rigid theater. The purpose is clarity, not bureaucracy.

7. What should trigger escalation

Examples:

  • likely milestone slip
  • unresolved dependency that threatens timing
  • sponsor concern or declining confidence
  • scope conflict that cannot be resolved locally
  • resourcing mismatch
  • repeated standards misses that affect the account

8. Common misses

  • escalating only once the problem is already public
  • sending multiple conflicting stories upward
  • escalating emotion without facts or impact framing
  • keeping the issue informal too long because the team hopes to quietly solve it

9. What we should eventually measure

This doc should inform future KPI design. Useful measures may include:

  • volume of escalations caught in Project Review Meeting or leadership sync
  • volume of surprise sponsor escalations
  • time from first known risk signal to formal escalation
  • percentage of escalations with explicit owner and next step

Those metrics belong in the Head of Delivery KPI layer as it matures.

Last updated: 2026-03-24

Graph View

Backlinks