Escalation Threshold Detection¶

Why It Matters¶

Organizations have limited managerial attention. Not everything can reach the CEO or senior leadership. Escalation thresholds determine what breaks through: what problems surface, what opportunities get consideration, what information shapes strategy. But thresholds are often poorly calibrated—too high and critical problems don't escalate until catastrophic; too low and leadership drowns in trivial escalations. Worse, thresholds are frequently implicit and inconsistent, creating random variation in what escalates. This means organizational responses are determined not by problem importance but by whether problems accidentally cross escalation thresholds. Making thresholds explicit allows calibrating them appropriately.

The Key Move¶

For any organizational level or decision-maker, ask: "What are the criteria for something to escalate here? Are they explicit or implicit? What gets filtered out before reaching this level?" Map the actual thresholds: dollar amounts, customer tiers, project phases, incident severity levels, approval chains. Then test: are important things being filtered out? Are unimportant things escalating? Is the threshold consistent or does it depend on who's asking? Explicitly set thresholds based on actual importance, not tradition or accident.

Classic Application¶

Risk management failures in financial institutions (2008 crisis). Risk reports existed showing excessive exposure to subprime mortgages and overleveraged positions. But escalation thresholds were calibrated around normal market conditions. Risks that were extreme but within "normal" volatility bands didn't escalate to senior leadership or boards. When market conditions changed, risks that seemed moderate became catastrophic, but the escalation threshold hadn't updated. By the time risks crossed the escalation threshold under old criteria, it was too late. The threshold was optimized for peacetime, not crisis.

Surprising Application¶

Bug triage in software development. Every bug is logged, but only some reach product managers or executive attention. Escalation thresholds: user impact estimates, customer tier, revenue at risk, severity classifications. But thresholds are often poorly calibrated: cosmetic bugs from major customers escalate immediately; critical security issues affecting free-tier users don't escalate until exploited. Or thresholds are gamed: engineers inflate severity to get attention; PMs demand everything be "P0" making the priority meaningless. The result: critical issues buried in noise while trivial issues consume leadership attention. Explicit, well-calibrated thresholds based on actual impact (security impact, user pain, revenue risk) aligned across the organization would filter appropriately.

Failure Modes¶

Setting thresholds too rigidly—sometimes legitimate exceptions need pathways to escalate. Ignoring that thresholds get gamed—people learn to manipulate severity classifications or present information to trigger escalation. Creating too many escalation paths that bypass thresholds—defeats the filtering purpose. Setting thresholds without feedback loops—they need periodic recalibration based on outcomes. Treating escalation as admission of failure—creates incentive to hide problems until they're catastrophic.

Go Deeper¶

March & Simon, Organizations (1958), Chapter 7; Perrow, Normal Accidents: Living with High-Risk Technologies (1984).