Dr. Wallace's Favorite Mental Models

The Tyranny of Small Decisions

How a string of individually sensible choices can add up to an outcome nobody actually wanted.

1The 30-Second Overview

The tyranny of small decisions happens when a series of choices, each one reasonable on its own, quietly adds up to a result that none of the people making those choices would have picked if they'd voted on the big outcome directly.

Where it comes from

Economist Alfred E. Kahn named it in a 1966 paper after watching passenger rail service in Ithaca, New York die one small choice at a time: travelers kept picking buses or flights for individual trips, and the train lost riders in increments until it no longer covered its costs.

Why it matters

No single decision looks like the one that "killed" the option. That makes the pattern almost invisible while it's happening, and nearly impossible to pin on any one person after the fact.

The core mechanism

Every time you pick option X over option Y, you're not just choosing X for today. You're casting a small vote to make Y less viable in the future. Kahn put it directly: choosing X over Y "constitutes also a vote for eliminating the possibility thereafter of choosing Y."

The giveaway sign

Decisions are being made at a different time horizon than the outcome they add up to. People choose trip by trip, sprint by sprint, request by request — while the real question (keep the train, keep the clean architecture, keep the marshland) is a single long-run, nearly irreversible call that nobody is actually being asked.

2Mental Model Compass

This compass places Tyranny of Small Decisions against three related models on two axes: how visible the mechanism is while it's happening, and how reversible the resulting outcome tends to be. Click a dot to see why it sits where it does.

Mental Model Compass: visibility versus reversibility A two-axis chart. Tyranny of Small Decisions sits low on visibility and low on reversibility, meaning it is hard to notice while happening and hard to undo once it has happened. Tragedy of the Commons sits slightly higher on visibility but similarly low on reversibility. Path Dependence sits low on visibility but moderate on reversibility. Sunk Cost Fallacy sits high on visibility and moderate on reversibility, because the trap is usually obvious to an outside observer even though the person inside it struggles to reverse course. Easy to notice Hard to notice ← visibility reversible ↑ Tyranny of Small Decisions Tragedy of the Commons Path Dependence Sunk Cost Fallacy

Click or focus any point on the chart to read why it's placed there.

  • Low visibility + low reversibility is the danger zone this model describes: nobody notices until the option is already gone.
  • Models further right (more visible) are easier to catch in the act, even if the underlying trap is similar.
  • Models higher up (more reversible) still cost time and money to undo, but the door isn't fully closed.

3Learn It Step by Step

Picture a passenger rail route between two small cities. On any given morning, a traveler compares the train to driving or flying and picks whichever is faster or cheaper that day. Each of those choices is completely reasonable — nobody is trying to shut the railroad down.

But the railroad doesn't get to choose passenger by passenger. It faces one lump decision: keep running the full schedule, or cut service. As ridership erodes trip by trip, ticket revenue eventually stops covering costs, and the line closes. The travelers who occasionally wanted the train never got to cast that vote directly — it was decided for them, one small trip at a time.

The trap works because of a mismatch in time horizons. The traveler is deciding about one trip. The real question — "should this option continue to exist at all?" — is a long-run, nearly all-or-nothing question that nobody is actually being asked in the moment.

That mismatch means the person making each small choice has no way to see, and often no reason to care, that their choice is a tiny vote against an option they might genuinely want to keep available for later.

Ecologist William Odum extended Kahn's idea to the environment in 1982: roughly half the marshland along the Connecticut and Massachusetts coast disappeared between 1950 and 1970, not through one dam or one law, but through hundreds of separate, small conversions — a filled lot here, a drainage ditch there.

The same shape shows up in software (a codebase degrades one "quick fix" at a time), in budgets (a department's total spend balloons through many individually small requests), and in group spending (a shared restaurant bill rises because each diner's extra appetizer only costs them a fraction of its price).

The fix isn't to distrust every small decision — most of them really are fine on their own. The fix is to occasionally ask the bigger question directly, on purpose, at the right level: "If we totaled up a year of these small choices, is this still the outcome we'd pick?" That single reframe is most of what using this model well looks like.

4Examples Across Different Worlds

A product team approves a dozen "quick" scope additions across a quarter, each one a reasonable favor to a customer or a sales team. No single addition would have been rejected if proposed as "should we triple the original scope of this release?" — but that's the question the additions, summed up, actually answered.

5Worked Application: A Shrinking Product Roadmap

Here's how a product lead might actually use this model when a backlog of "small" feature requests keeps growing.

  1. Notice the shape, not the size. No single incoming request this month looks dangerous — each is a two-day build a reasonable customer asked for.
  2. Name the aggregate question. Instead of asking "should we build this one thing," ask: "If we build everything currently requested this way, what does the product look like in twelve months?"
  3. Total the actual cost. Add up engineering time, support burden, and QA surface area across the full set of small requests from the last two quarters, not just the next one in line.
  4. Surface the irreversible vote. Identify which small yeses are quietly voting against something valuable — here, a clean, learnable product — the same way each train rider's choice voted against the railroad.
  5. Create a higher-level checkpoint. Require that requests above a cumulative monthly threshold get reviewed together, as one roadmap decision, rather than approved one at a time by whoever received the request.
  6. Decide on purpose. Either accept the aggregate outcome deliberately (sometimes it really is fine) or cut the backlog with the big picture in view — the goal is just to make sure a real decision was made, instead of one accumulating by default.

6Common Mistakes

Mistake

Treating every instance of "many small decisions led to a big outcome" as this model, even when the outcome was exactly what everyone wanted (e.g., a company growing one satisfied customer at a time). The model is specifically about undesired aggregate outcomes nobody would have chosen directly.

Correct Use

Reserve the label for cases with a real time-horizon mismatch: individual choices at one scale, an irreversible or hard-to-reverse outcome at a bigger scale, and a result that would likely have been rejected if it had been put to a direct vote.

Mistake

Confusing it with the Tragedy of the Commons, which is about competing self-interest exhausting a shared resource. Tyranny of Small Decisions doesn't require competing interests at all — the Ithaca travelers weren't competing with each other, they just each made a reasonable individual call.

Correct Use

Use Tragedy of the Commons when the driver is each actor grabbing a shared resource before someone else does. Use Tyranny of Small Decisions when the driver is a mismatch between the scale of the decision and the scale of the outcome, with or without any competition.

Mistake

Using it after the fact as a blameless shrug — "nobody could have seen this coming" — when in fact someone with aggregate visibility (a manager, a planning board, a platform owner) could have asked the bigger question and chose not to.

Correct Use

Treat the model as a diagnostic that creates a responsibility: once you can name the pattern, the honest move is to build a checkpoint that asks the aggregate question on purpose, not to use the pattern as an excuse.

7When Not to Use It

Skip this model when a single, identifiable decision actually caused the outcome — that's just a bad decision, not a tyranny of small ones, and naming it this way can let the real decision-maker off the hook. Skip it also when the aggregate outcome is genuinely fine and nobody but a critic has decided retroactively that it shouldn't be — organic, incremental growth that stakeholders are happy with isn't evidence of a trap. Finally, be careful applying it to competitive, zero-sum situations where each actor truly is racing the others for a shared resource; that pattern is usually better described by the Tragedy of the Commons, where the fix (property rights, quotas, coordination) looks different from the fix here (an aggregate checkpoint).

9Try It Yourself: Prompt Builder

Fill in your own situation and generate a ready-to-use prompt for checking whether you're inside a tyranny of small decisions.

10Save as Skill

Turn this mental model into a reusable skill file you can hand to an AI assistant, so it checks your decisions for this pattern going forward.

Copied!

Apply to My Problem

Describe a decision you're currently facing, and generate a prompt that asks an AI assistant to check it against this model specifically.