/ Library/ Need to Act Fast/ Escalation of Commitment
Decide Bias № 167 · Last updated 6 June 2026

Escalation of Commitment.

"The more we have invested, the harder it is to stop — even when the evidence says we should."

01Overview

Escalation of commitment is the tendency to invest additional resources in a failing decision because of what has already been spent — time, money, reputation, or identity. Each increment makes the next harder to refuse. Stopping feels like admitting the prior investment was wasted; continuing preserves hope.

For designers, escalation appears in zombie features, research programmes that keep running after null results, design systems nobody uses but nobody retires, and rebrand programmes that absorb quarters because stopping would embarrass leadership. The prototype is not just a prototype — it is evidence of a bet the organisation has doubled down on.

02Detailed explanation

Escalation follows predictable organisational patterns:

  • A pilot that misses success criteria gets "one more sprint" repeatedly — scope expands to justify the original thesis.
  • User research continues until it confirms the brief, burning budget after early sessions showed the concept weak.
  • Executive visibility locks teams into public commitments; retreat costs face, not just budget.
  • Cross-team dependencies make sunsetting expensive — escalation through coupling, not conviction.

Escalation of commitment overlaps sunk-cost fallacy but emphasises dynamic increase: each round raises the stake. Design leaders need kill rituals as robust as launch rituals — or failing work consumes the capacity that winning work needs.

03Why it exists

Loss aversion makes realised failure hurt more than incremental spend feels costly. Small additional investments delay the painful accounting.

Social and career incentives reward persistence and punish visible retreat. Escalation protects individuals and teams from shame — at the product's expense.

The short version

If the only reason to continue is what you already spent, you are escalating — not iterating.

04Effects on users

Users suffer when escalation keeps broken flows alive: maintenance burden starves fixes; confusing legacy UI persists because retirement would admit failure.

They also escalate personally — continuing subscriptions, courses, or setups they would not choose fresh — mirroring organisational dynamics at individual scale.

05Effects on designers & teams

Teams escalate through process design gaps:

  • No pre-mortems or kill criteria. Launches without defined failure thresholds invite infinite extension.
  • Public roadmap commitments. Promised features ship regardless of evidence — escalation via reputation.
  • Research as confirmation engine. Studies rerun with tweaked scripts until stakeholders hear yes.
  • Design system mandates without adoption metrics. Investment continues because building felt like progress.

06Practical takeaways

  • Define stop rules before start. Success and failure criteria signed before sunk cost accumulates.
  • Schedule kill reviews. Regular zero-based checkpoints: would we begin this today?
  • Separate experiment from commitment. Label pilots explicitly; avoid branding until evidence supports scale.
  • Make retreat honourable. Celebrate well-evidenced stops; penalise zombie persistence.
  • Track opportunity cost visibly. Show what escalation steals from other user problems.
  • Protect research from brief capture. Allow null results to land without automatic rerun.

07Design examples

Feature bet

One more sprint

A social feature misses engagement targets for three quarters. Each review adds scope — "we need groups first." Engineering headcount equivalent to core checkout fixes is consumed. Escalation preserves launch narrative.

Research

Until they like it

Concept testing shows consistent rejection. The team reruns with new stimuli, new segments, new facilitators. Budget exhausts on the fifth round; one ambiguous quote finally ships the deck.

Rebrand

Too visible to stop

A rebrand programme overruns by eight months. Research shows neutral-to-negative user response. Leadership continues because stopping would embarrass public announcements already made.

Design system

Built, not adopted

A component library reaches 200 components; product teams still ship bespoke UI. Investment continues — documentation, governance — because admitting low adoption feels like waste.

08Ethical risks

Escalation on harmful or exclusionary features — because stopping would admit error — prolongs user harm to protect organisational ego.

Users rarely consent to being subjects of an escalated bet; they experience neglect elsewhere while failing work absorbs capacity.

Self-test: What project on your roadmap would you stop today if past spend were invisible?

10Suggested reading