Escalation of Commitment

The more a decision belongs to you, the harder it is to let it lose.

October 12, 2026 8 min read

Escalation of commitment is the tendency to keep investing in a failing course of action because you were the one who chose it. The evidence turns, the plan stalls, and the person who backed it asks for one more quarter.

Barry Staw named it in 1976, in a paper titled "Knee-deep in the big muddy." He ran a role-play investment exercise with 240 business school students. Some were made responsible for the initial funding decision; others were not. When the investment then went badly, the students who had made the first call put more money back into it than those who hadn't. Personal responsibility for the loss, not just the loss, drove the extra spending.

That detail separates escalation from its better-known neighbor. The sunk cost effect is about money, effort, or time already spent. Escalation is about who spent it. The same losing project looks different to the person whose judgment it now puts on trial.

A worked case

A team decides to build its own billing system instead of buying one. The rationale is reasonable: the pricing model is unusual, and the vendors on the shortlist can't express it.

Six months in, two things have changed. A vendor has shipped support for exactly that pricing model, and the internal build is a quarter behind. The engineering lead who argued for building is asked whether to continue.

Here is how escalation sounds from the inside:

• "We're too far in to switch now."
• "The last 20 percent is the easy part."
• "Switching would waste everything we've learned."
• "The vendor's version won't handle our edge cases."

Each sentence might be true. The first three answer a different question from the one that matters, which is: knowing what we know today, would we start this build? They defend the past. The fourth bears on that question, but nobody has checked it, because checking it risks the answer.

Is this persistence or escalation?

Persistence and escalation look the same from the outside. Both mean continuing after a setback. The difference is what the continuation rests on. A few questions separate them:

1. Do the original reasons still hold? Persistence can point to the assumptions behind the decision and say they are intact. Escalation changes the subject to effort already spent.
2. Would a newcomer choose this? Ask someone who had no part in the original call. If they would not start the project today, the case for continuing is mostly about the people who did.
3. Was there a point at which we said we'd stop? If the team set a threshold before starting and has now passed it, continuing needs a new reason stated today. If no threshold exists, that is worth noticing too.
4. What does reversing cost the person who decided? If changing course reads as a public verdict on someone's judgment, expect that person to argue for staying. The incentive drives it, whoever holds the role.

None of these questions requires anyone to admit a mistake. They ask whether the decision still stands on its own reasons.

What reduces it

Sixteen years later, in 1992, Itamar Simonson and Staw compared techniques for reducing escalation in the Journal of Applied Psychology. Three worked best: making a negative outcome less threatening to the decision maker, setting minimum target levels in advance that would trigger a change of policy if missed, and evaluating decision makers on their decision process rather than the outcome.

Each one attacks the same mechanism. Escalation is self-justification, so the fixes lower what the decision maker has to justify. A preset target makes the stop an agreed rule rather than a personal retreat. Grading the process means a sound call that met bad facts is not a mark against anyone, which is the argument the Resulting post makes. And a reversal that doesn't read as a confession is one people can actually make.

Where this fits at Brief

All three of those fixes are easier when the original decision is written down, with its reasons, by the time anyone has to question it. Brief is built around that record, and each fix has a place in that record.

Process gets a record to be graded on. Brief stores a decision with its rationale, who logged it, and when, whether it was captured from a Slack thread or created with brief decisions create --decision "..." --rationale "...". In the billing case, the record says the team chose to build because no vendor could express the pricing model. That is the assumption the team can now test. The vendor shipped support, so the reason no longer holds, and the conversation can be about the reason, which is easier to discuss than the engineering lead's judgment. Without the record, the reasoning most people will reach for is the one its author remembers, and that is the version escalation edits first.

Reversal becomes history instead of a confession. When a team changes course, the old decision stays on record, linked to the one that replaced it (see supersession). The build decision stays readable, with the reasoning that made it sensible in its day. The new decision to buy sits next to it, with its own reasoning: the assumption changed. That is close to Simonson and Staw's first technique: it makes changing course less threatening to the person who decided. Reversing adds a dated entry saying the facts moved, and the earlier judgment stays on record beside it.

The stop condition can live with the decision. The second technique, a minimum target that triggers a change of policy, is a tripwire. Brief doesn't set one on its own; it stores the rationale it is given. But a rationale is the natural place to put one: "build, because no vendor supports usage tiers; revisit if a vendor ships them or the build slips past one quarter." Written that way, the decision carries its own exit, agreed before anyone's reputation was attached to staying.

Coding agents meet the same record. A coding agent asked to keep extending the internal billing system can run brief ask --mode check with the planned change. Check mode validates an approach against the team's existing decisions, so if the team has already recorded the switch to the vendor, the check can flag the conflict before the agent builds another quarter on the old plan. If the switch hasn't been recorded, the check has nothing to compare the plan against. Agents don't escalate out of pride, but an agent that checks will build on whatever decision the record still shows.

The limits matter. Brief can only hold the reasons and thresholds someone writes down, and a decision logged with a thin rationale gives a later review little to test. A record also doesn't remove the person. Someone still has to ask whether the reasons hold, and the person who made the call may still find that hard. What the record changes is the question. "Were you wrong?" is a hard question to ask a colleague. "Does the reason we wrote down still hold?" is an easier one, and it can reach the same answer without putting anyone on trial.

Think of a project your team has extended at least twice. Could anyone point to the reason it was started, and say whether that reason is still true?

Frequently asked questions

What is escalation of commitment? The tendency to keep investing in a failing course of action because you chose it. Barry Staw described it in 1976, in a study where people who were personally responsible for an initial investment put more money back into it after it went badly than people who had inherited the decision.

How is escalation of commitment different from the sunk cost fallacy? Sunk cost is about resources already spent. Escalation adds personal responsibility: in Staw's study, the people who had made the original call reinvested more than those who hadn't.

How do you reduce escalation of commitment? In a 1992 comparison, Itamar Simonson and Barry Staw found three techniques worked best: making negative outcomes less threatening to the decision maker, setting minimum targets in advance that trigger a change of policy, and evaluating people on their decision process rather than the outcome.

How does Brief help teams avoid escalation? Brief records decisions with their rationale, author, and timestamp, and keeps a replaced decision as history when a team changes course. That lets a team test whether the original reasons still hold and makes a reversal an added entry that leaves the original in place. Brief stores a stop threshold only if someone writes it into the rationale.