The Stale-Assumption Failure Mode: When Yesterday's Right Decision Becomes Today's Liability

TL;DR

• The failure mode is real and well-documented: rigorous technical due diligence produces a decision that was correct given the facts at the time, but the underlying assumptions silently expire as the market, team, technology, or business model shifts—and in most organizations nobody is structurally responsible for noticing. Mark Keil's research found that 30–40% of all IS projects exhibit escalation of commitment to a failing course of action.
• Two distinct bodies of knowledge converge here: (1) the psychology of why we don't revisit (sunk cost fallacy, escalation of commitment, status quo bias, loss aversion, lock-in economics) and (2) the governance toolkit that exists to counter it but is rarely installed (kill criteria, tripwires, RAND's assumption-based planning signposts, architecture fitness functions, Type 1/Type 2 decision triage, Wardley mapping).
• The fix is structural, not exhortatory: knowing about these biases does not protect against them. The organizations that succeed assign explicit ownership, set pre-committed review triggers ("signposts"/"kill criteria") at the moment of the original decision, and schedule recurring assumption audits—because the default state is drift.

Key Findings

1. The psychology: why sound decisions don't get revisited

• Sunk cost fallacy / Concorde fallacy. The tendency to continue a course of action because of resources already invested. The "Concorde fallacy" label comes from the Anglo-French supersonic jet that British and French governments kept funding for decades despite knowing it was uneconomic. Annie Duke's framing: "The sunk cost effect causes people to stick in situations that they ought to be quitting," and crucially, "knowing about the sunk cost effect doesn't keep you from falling prey to it."
• Escalation of commitment. Barry Staw's foundational concept; Mark Keil applied it specifically to IT. Keil, Mann & Rai (MIS Quarterly, 2000) found 30–40% of IS projects escalate, drawing on self-justification theory, prospect theory, agency theory, and approach-avoidance theory.
• Status quo bias. Formally described by William Samuelson and Richard Zeckhauser, "Status Quo Bias in Decision Making," Journal of Risk and Uncertainty, 1988. Subjects systematically stick with the status quo when one is offered, and the bias strengthens as the number of alternatives increases.
• Endowment effect & loss aversion. Kahneman, Knetsch & Thaler ("Anomalies: The Endowment Effect, Loss Aversion, and Status Quo Bias," Journal of Economic Perspectives, 1991) connect these: losses weigh roughly twice as heavily as equivalent gains (loss aversion coefficient ~2.0). Switching away from an existing platform is framed as a certain loss, biasing toward continuation.
• Lock-in economics. Carl Shapiro & Hal Varian, Information Rules (1999): "once you have chosen a technology, or a format for keeping information, switching can be very expensive." Their key insight: the profit a vendor can extract from a customer is roughly equal to the total switching costs. "The magnitude of switching costs is itself a strategic choice made by the producer of the system."

2. Technical lock-in mechanisms and switching-cost data

• Cloud egress fees as deliberate lock-in. AWS charges roughly $0.09/GB for the first 10TB tier of internet egress (Azure ~$0.087/GB, GCP ~$0.12/GB); ingress is free. This asymmetry is widely described as an intentional lock-in mechanism. A company with 100TB on S3 pays roughly $8,000 just in egress to migrate it; moving 50TB costs $3,500–$7,000 in egress alone.
• Egress accounts for roughly 6–12% of typical cloud bills (CloudZero analysis, 2025).
• Hidden transfer costs compound it: NAT Gateway processing at $0.045/GB, cross-AZ transfer at $0.01/GB each way.
• Regulatory response: AWS globally removed data-transfer-out fees for customers leaving its platform in March 2024, motivated by the European Data Act's requirement to remove "obstacles to effective switching."
• The a16z "Cost of Cloud" thesis. Sarah Wang & Martin Casado, "The Cost of Cloud, a Trillion Dollar Paradox" (Andreessen Horowitz, 2021): across 50 top public software companies, an estimated $100B of market value is lost due to cloud's impact on margins; "if you're operating at scale, the cost of cloud can at least double your infrastructure bill." Per Wang & Casado, "cloud spend ranging from 75 to 80% of cost of revenue was common among software companies," and they model that "cloud repatriation drives a 50% reduction in cloud spend, resulting in total savings of $4B." Their memorable line: "You're crazy if you don't start in the cloud; you're crazy if you stay on it." They note repatriation is hard precisely because it comes late: "a rewrite to the significant restructure needed to dramatically improve efficiency can take years, and is often a non-starter."
• Dropbox: saved nearly $75M over two years by shifting the majority of workloads from public cloud to custom-built infrastructure in co-location facilities (cited by Wang & Casado).
• 37signals (Basecamp/HEY): its 2022 AWS-era cloud spend was exactly $3,201,564 ($266,797/month), including $759,983 on EC2/EKS compute. DHH led an exit, spending ~$700,000 on Dell servers; per The Register (May 9, 2025), "cloud bills fell by some $2 million a year," and the company projects ~$10M in savings over five years. On exit, per DataCenterDynamics, DHH said: "Fair play to AWS for comping the quarter of a million-dollar egress bill, per their public commitments. It took a while to get it approved, but in the end, we got it." The key point for this post: the cloud decision was correct when 37signals was small and spiky; it went stale once workloads became stable and predictable—the assumption "we need elastic scaling" expired.

3. The "right then, wrong now" frameworks

• Type 1 vs Type 2 decisions (Jeff Bezos, 2015/2016 Amazon shareholder letters). Type 1 = "one-way doors," consequential and nearly irreversible, decide slowly. Type 2 = "two-way doors," reversible, decide fast. Key insight relevant here: organizations drift toward treating everything as Type 1 as they grow, producing "slowness, unthoughtful risk aversion, failure to experiment." Notably, AWS and Amazon Prime were treated as two-way doors at launch. Bezos also advocates deciding at ~70% of the information you wish you had.
• Annie Duke — Quit (2022) and "kill criteria." Set, in advance, the specific signals ("states and dates") that will tell you to walk away, because "it is hard to make a good choice about whether to stick or quit when you are facing down the decision to walk away." Duke (Special Partner for Decision Science at First Round Capital) recommends a "quitting coach"/stop owner independent of the project sponsor. Reframes "waste": the waste isn't behind you (sunk), it's ahead of you if you continue.
• Pre-mortems (Gary Klein). Imagine the project has failed and work backward to causes—surfaces kill criteria before commitment.
• Heath brothers — Decisive (2013), the WRAP process and "tripwires." "Without tripwires, we may just go merrily on our way, assuming that our original decision was correct." They invoke the "Andy Grove question": ask "what would my successor do?" to attain distance.

4. Formal assumption-review triggers (the most important and rarest part)

• RAND's Assumption-Based Planning (James Dewar et al.). A five-step methodology: (1) identify assumptions, (2) identify load-bearing AND vulnerable assumptions, (3) define signposts (warning signs that an assumption's vulnerability is changing), (4) shaping actions, (5) hedging actions. This is the most direct match to the user's topic: signposts are explicitly designed to monitor whether planning assumptions still hold. Dewar's diagnostic trick: count uses of the word "will" in a plan—in one 47-page document "will" appeared 470 times vs. "may"/"can" 45 times each—each "will" is a buried assumption.
• Andy Grove — strategic inflection points (Only the Paranoid Survive, 1996). "A strategic inflection point is a time in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end." Driven by a "10X" change in one of six forces (competition, technology, customers, suppliers, complementors, regulation). Intel's 1985 exit from the memory/DRAM business to focus on microprocessors is the archetype: Grove asked Gordon Moore what a new CEO would do, Moore said "He would get us out of memories," and Grove replied, "Why shouldn't you and I walk out the door, come back, and do it ourselves?" Grove's warning on stale data: "Data are about the past, and strategic inflection points are about the future."
• Architecture Decision Records (Michael Nygard, 2011). Lightweight markdown records of "architecturally significant" decisions, capturing context, decision, and consequences, stored in the repo. ThoughtWorks moved ADRs to "Adopt" on its Technology Radar. Crucially for this topic: ADRs are immutable snapshots; when context changes you mark the old one "superseded" and write a new one. Nygard's own warning: a decision may need revisiting "if the context has changed"—and "the time to change old decisions will be clear from changes in the project's context." But standard ADRs capture the decision, not a scheduled trigger to revisit it—the assumption-monitoring layer is usually missing. ^[1]
• Evolutionary architecture & fitness functions (Neal Ford, Rebecca Parsons, Patrick Kua, ThoughtWorks). A fitness function is "an objective characterisation of how well a particular system reflects a desired behavioural characteristic," baked into the deployment pipeline to automatically verify the architecture still meets its goals as it changes. This is the closest engineering analog to continuous assumption monitoring. ^[2]
• Lean Startup (Eric Ries). Validated learning, innovation accounting, and the explicit "pivot or persevere" decision driven by actionable metrics—a structured trigger for re-examining the core hypothesis. ^[3]
• Wardley Mapping (Simon Wardley). Plots components by visibility (to user) and evolution (genesis → custom → product → commodity). Its power for this topic: components inexorably move left-to-right over time, so a build-vs-buy decision that was right when a component was "genesis" becomes wrong once it commoditizes. The map makes the staleness visible. ^[4]

5. Cautionary examples — with the specific stale assumption identified

• Kodak. Engineer Steve Sasson built the first portable digital camera in 1975 (0.01 MP, recorded to cassette tape, 23 seconds to save an image). The stale assumption: that customers would always want prints and that film was the durable business. Note the nuance for a technical audience: Kodak did NOT simply "hide" it—the device wasn't market-ready and no market existed in 1975. Kodak held valuable digital patents and later built digital cameras, but always subordinate to film. At its mid-1990s peak Kodak had ~$28B market cap, 140,000+ employees, ~90% of US film and 85% of camera sales; it filed for bankruptcy in 2012. The assumption was correct in 1975 and wrong by the late 1990s, and the structure rewarded film. ^[5]
• Blockbuster. Declined to buy Netflix for $50M in 2000. At the time Blockbuster had ~9,000 stores and $6B revenue; per NBC News, "In 2000 Blockbuster collected nearly $800 million in late fees, accounting for 16 percent of its revenue," and by 2009 those fees had "plunged to $134 million, or just 3 percent of the company's revenue." The stale assumption: that physical-store rental and late fees were the durable model and online was a niche. Note: ex-CEO John Antioco disputes that serious acquisition talks occurred. Bankrupt 2010; remnants sold to Dish for $320M. ^[6][7]
• Nokia. Per S&P Global Market Intelligence, Nokia "reached the 40% mobile devices market share" with 437.1M units shipped in 2007; in smartphones specifically its share was 50.8% in Q2 2007, falling to 3.1% by Q2 2013. Stale assumption: that phones were a hardware business and that proprietary Symbian OS (genuinely the best mobile OS in the early 2000s) would remain adequate. They clung to Symbian as the world shifted to software/app-ecosystem competition, chose Windows Phone over Android in 2011, and sold the phone business to Microsoft for $7.2B in 2013. INSEAD's framing: "Success breeds conservatism and hubris which, over time, results in a decline of the strategy processes." ^[8]
• Denver International Airport automated baggage system. Documented in Montealegre & Keil, "De-escalating Information Technology Projects: Lessons from the Denver International Airport," MIS Quarterly, 2000. The stale/unchallenged assumption: that the largest, most complex fully automated baggage system ever attempted could be built in ~2 years (consultants explicitly warned there was insufficient time), and that the airport opening was contingent on it. Original automated-system budget $193M; the delay cost Denver $33.3M/month ($1.1M/day) in debt service. The airport opened ~16 months late (February 1995 vs. planned October 1993). De-escalation only came when external shocks (a Moody's bond downgrade, federal investigations) forced problem recognition and the mayor hired independent consultants and authorized a manual backup—reframing the goal from "fix the system" to "open the airport." United scrapped the automated system entirely in 2005. Keil's retrospective: "The plug should have been pulled in 1994."

6. Governance: who owns assumption review (and why it falls through the cracks)

• The structural gap: due diligence has a clear owner (whoever makes the decision), but ongoing assumption monitoring has no natural owner. It's nobody's job. Architecture review boards, CTOs/chief architects, and post-implementation reviews exist, but post-implementation reviews are typically one-time and backward-looking, not recurring assumption audits.
• Duke's structural prescriptions map directly: write kill criteria before you fund/launch; instrument leading indicators tied to those criteria; hold dedicated "quit reviews" on a fixed cadence, separate from standard operations; assign a stop owner independent of the project sponsor; maintain an opportunity-cost ledger of unfunded high-value bets.
• The deepest research finding for a credibility anchor: awareness is necessary but insufficient. The Concorde continued for decades even as officials privately acknowledged it was uneconomic. This is why the answer must be structural (triggers, owners, cadence), not "be more vigilant."

7. Supporting statistics

• Standish CHAOS: In the original 1994 report, only 16.2% of software projects succeeded (on time, on budget, full scope); 52.7% were challenged; 31.1% cancelled; cost overruns averaged 189%. Large-company projects succeeded only ~9% of the time. More recent CHAOS data: ~31% successful, ~50% challenged, ~19% failed; large projects succeed <10% of the time while small projects ~90%. ^[9]
• McKinsey–Oxford study of 5,400+ projects (Michael Bloch, Sven Blumberg & Jürgen Laartz, "Delivering large-scale IT projects on time, on budget, and on value," McKinsey, October 2012): "17 percent of IT projects go so bad that they can threaten the very existence of the company"; large projects on average ran 45% over budget, 7% over time, and delivered 56% less value than predicted.
• BCG (2020 study, 825 senior executives plus 70 of its own client projects): "only 30% of transformations met or exceeded their target value and resulted in sustainable change"—i.e., 70% fall short.
• Keil escalation losses: US companies incurred an estimated $59B in IT cost overruns in 1995 (against ~$250B/year in IT application development spend). Example escalations: California DMV ($49.4M abandoned); California Statewide Automated Child Support System (budgeted <$75.5M, cancelled 1997 at est. $345M).

Details

The two halves of this story—psychology and governance—are mirror images. Every cognitive bias has a corresponding structural countermeasure:

• Sunk cost / escalation → kill criteria set in advance (Duke), de-escalation triggers (Keil)
• Status quo bias / loss aversion → tripwires (Heath), signposts (RAND)
• Treating reversible as irreversible → Type 1/Type 2 triage (Bezos)
• Lock-in / switching costs → Wardley mapping (notice commoditization), multi-sourcing (Shapiro & Varian)
• Architectural drift → fitness functions (Ford/Parsons), ADR review cadence (Nygard)
• Stale market assumptions → strategic inflection point scanning (Grove), validated learning (Ries)

The recurring theme across the literature is that the original decision is rarely the problem. As one analysis of Blockbuster put it, the failure is "how organizations lose the ability to evaluate futures that contradict their own operating assumptions." ^[10]

Recommendations

For a Director of Technical Strategy at a healthtech company, staged and concrete:

1. Attach an expiry date and named owner to every major technical decision now. In your ADR template, add two fields Nygard's original doesn't require: "Assumptions this depends on" and "Revisit trigger / review date." This is the single highest-leverage, lowest-cost change. Threshold to escalate: any ADR whose load-bearing assumption is flagged should trigger a review within 30 days.
2. Adopt RAND's signpost discipline for the 3–5 biggest in-flight commitments (cloud provider, core framework, key vendor contracts, build-vs-buy bets). For each: write down the load-bearing AND vulnerable assumptions, then define a measurable signpost. Example for cloud: "Egress + cross-AZ transfer exceeds X% of total cloud spend" or "monthly workload variance drops below Y%, indicating we're paying a flexibility tax we no longer need."
3. Triage decisions Bezos-style. Explicitly label major decisions Type 1 vs Type 2. Resist the organizational drift toward treating everything as irreversible; for genuinely reversible choices, decide fast and instrument them. In healthtech, regulatory/compliance and data-residency choices are genuinely Type 1—spend the rigor there.
4. Install a recurring "assumption audit" on a fixed cadence (semi-annual), separate from project status reviews, owned by a named person (you, or a rotating architect). Borrow Duke's separation principle: the reviewer should not be the original decision's champion. ReversingLabs' practice of re-evaluating its self-hosting vs cloud strategy every two years is a concrete model.
5. For the architecture, encode assumptions as fitness functions where possible so drift is caught automatically in the pipeline rather than in a meeting that may never happen.

Benchmarks that should change the recommendation: If your workloads are still spiky/unpredictable and you're pre-product-market-fit, the cloud-elasticity assumption still holds—don't repatriate. The 37signals/Dropbox math only flips once workloads are stable and predictable AND cloud spend is a material fraction of cost of revenue (a16z observed cloud spend of 75–80% of cost of revenue was common among scaled software firms). For healthtech specifically, weigh egress/repatriation math against HIPAA/compliance tooling maturity, which often favors staying on a hyperscaler.

Caveats

• Hindsight bias in the cautionary tales. Kodak, Blockbuster, and Nokia are told as obvious failures, but each decision was defensible at the time. Use them to illustrate assumption expiry, not stupidity. The Kodak "hid the digital camera" story is an oversimplification (Snopes rates it "mixture"); the Blockbuster $50M offer is partly disputed by ex-CEO Antioco.
• Cloud repatriation is contested. a16z's thesis was rebutted by FinOps practitioners who argue the analysis ignores the revenue/ROI side and that "cloud is not a data center"—repatriation savings often come from workloads that were poorly architected or lift-and-shifted. Present repatriation as "re-examine the assumption," not "leave the cloud."
• Standish CHAOS data has methodological critics (definitions of "success," sampling). Cite directionally, not as precise truth. Note also that 2020 CHAOS controversially found projects without a highly-skilled manager sometimes succeeded more often—treat the dataset with care.
• Source-date precision: the "17% of large IT projects threaten company existence" figure is from McKinsey's 2012 (not 2020) study with Oxford. Conflicting cost figures appear for Denver (the ~$193M automated-system budget vs. inflated secondary figures of >$1B that conflate the whole airport) and for 37signals (savings reported variously as ~$2M/year and ~$10M over five years as the project progressed). I've used the most authoritative/primary figures.
• Several framework sources (kill criteria, tripwires, ABP) are books and consulting frameworks, not peer-reviewed studies; the empirical anchors are Keil's MIS Quarterly work, Samuelson & Zeckhauser, Kahneman/Knetsch/Thaler, McKinsey–Oxford, and Standish.

1. Red Hat + 3 — https://www.redhat.com/en/blog/architecture-decision-records
2. InfoQ — https://www.infoq.com/news/2023/03/evolutionary-architecture-2025/
3. Book Assess — https://www.bookassess.com/index.php/2025/08/30/the-lean-startup-by-eric-ries
4. Stratrix — https://www.stratrix.com/learn/frameworks/wardley-mapping
5. Snopes + 2 — https://www.snopes.com/fact-check/kodak-digital-camera-invention/
6. Stratrix — https://www.stratrix.com/vault/blockbuster-netflix-disruption
7. Newsweek — https://www.newsweek.com/fact-check-did-blockbuster-turn-down-chance-buy-netflix-50-million-1575557
8. Gizoom Consulting + 2 — https://gizoom.com/demise-nokia-the-rise-fall-and-missed-opportunities-of-a-mobile-giant/
9. OpenCommons — https://opencommons.org/CHAOS_Report_on_IT_Project_Outcomes
10. Headcount Coffee — https://www.headcountcoffee.com/blogs/corporate-legends-lost-empires/blockbuster-s-acquisition-system-and-the-netflix-miss