In 1985, the behavioural scientists Hal Arkes and Catherine Blumer sold theatre season tickets at full price to one group of buyers and at a random discount to another, then tracked who actually turned up. The full-price group attended noticeably more plays over the season. The only thing separating them from the discount group was how much they had already paid — money none of them could get back, and money that had no bearing on whether the next play was worth the trip. That is the sunk-cost fallacy, and four decades later it still shapes a decision mid-market CEOs face constantly: whether to fix an expensive operational problem after an earlier technology investment has already disappointed.
The reasoning that traps them usually sounds responsible. We’ve already put £200,000 into the system — we should get value from that before we spend more. Said aloud in a board meeting it passes for prudence, but in financial terms it does the opposite of protecting the business: the £200,000 is gone whether anyone acts or not, and it tells you nothing about whether the next fix will earn its keep. The only figures that belong in the decision are the ones still ahead — what the current problem costs each quarter it goes unsolved, and what a fix would return.
This trap shows up most often in CEOs already carrying digital transformation fatigue — the weariness that sets in after a project that cost a great deal and changed very little. Fatigue and sunk-cost reasoning reinforce each other: the fatigue makes every new proposal feel like a gamble, and the last invoice supplies a respectable reason to decline it. Breaking the loop starts by separating the money that is already gone from the decision that is still open.
Why doing nothing has a price the sunk cost hides
The process eating four salaries a year does not pause while the decision sits unmade. It keeps eating them, quarter after quarter, and the longer a broken workflow runs, the more people get hired into it, trained on its workarounds, and woven into its daily operation. That is precisely how the Manual Wall — the point at which a growing service company can only add capacity by adding headcount — becomes more expensive to take down the longer it stands.
It is worth being honest about why the fatigue exists at all, because the caution underneath it is not stupid. The failure rate is real. The Standish Group’s long-running CHAOS research has tracked stubbornly low success rates for large IT projects for decades, and McKinsey has reported that most digital transformations fall short of the value they set out to capture. A CEO who has been burned once is reading the base rates correctly; the projects genuinely do fail more often than they succeed. Reasonable caution curdles into something costly the moment a number that can never be recovered starts deciding where the next pound goes.
What the sunk-cost fallacy actually does to a technology decision
A sound technology decision looks forward. It asks what a fix will cost and save from today, and how quickly that return shows up on the P&L. The money spent on the previous system does not belong anywhere in that calculation, because no choice available now can bring it back. What makes that so hard to act on is wiring rather than weakness — Daniel Kahneman and Amos Tversky’s prospect theory established that a loss is felt roughly twice as keenly as an equivalent gain. Writing off the old system registers in the mind as a loss to be avoided, so the business keeps feeding it instead.
“We’ve already spent £200,000 — we should get value out of that before we spend anything more” sounds like financial discipline, but it ties a new decision to a figure that has no bearing on its outcome. For a CFO, the cleaner way to see it is as two separate questions. The first is what to do with the existing asset, judged purely on what it costs to operate from here rather than what it cost to buy. The second is whether a new initiative earns its keep on its own forward numbers. Treating fresh spend as a betrayal of old spend is how a business ends up pouring operating budget into a system precisely because it was expensive.
Why a failed project makes the next decision harder, not easier
A single failed project tends to produce two failures rather than one, and they pull in opposite directions. The first is over-attachment to the dead system: the company keeps funding licences and workarounds for a platform that never delivered, because abandoning it would mean admitting the original spend is lost. Public-sector projects show the pattern at full scale — the FBI spent in the region of $170 million on its Virtual Case File system before scrapping it. Private mid-market companies rarely disclose the number, but the dynamic is identical, only quieter.
The second failure is the one that compounds. Once a CEO’s scepticism becomes a known quantity, the organisation adapts to it. Operations managers stop bringing automation proposals forward because they can predict the response, and the absence of proposals then gets read as the absence of problems. The business persuades itself it has finished investing in operations at exactly the moment its operational costs are climbing fastest. This is the mechanism described in detail in our piece on why six-figure tech projects fail; the sunk-cost trap is what happens in the years afterward, when the lesson learned is “don’t try again” rather than “try differently.”
How to tell sensible caution apart from sunk-cost paralysis
From the inside, the two feel identical. Both sound measured, and both can be defended in a board meeting. The difference is in the direction the questions face, and it is worth learning to hear it.
Every question in the left column points at the future and can be answered with a number. Every line in the right column points at money that is already gone. A useful self-test for any CEO or CFO sitting on a decision: write down the reason you are hesitating and check whether the figure inside it is one you have already paid or one you have yet to earn. If everything in your reasoning sits in the past, the hesitation is the fallacy talking rather than your judgement.
How to take the past spend out of the decision
The practical fix is a rule that refuses to look backward. At Digital Forms we use the 0.5 FTE gatekeeper rule: no initiative gets funded unless it can show, before any build begins, that it will save at least half a full-time employee’s worth of effort a year in a specific, named workflow. The rule is deliberately blunt, and the bluntness is what makes it work — it judges a proposal entirely on what it will return from today forward, and offers nowhere for last year’s invoice to be entered.
Getting to that number means measuring what the business is paying right now, not what it paid before. A cost-mapped diagnostic puts a loaded annual payroll cost against each recurring manual process, then ranks them by what they consume — the costing the Manual Wall Calculator is built to produce. The exercise resets the whole conversation, because it puts a live, present-tense figure next to the problem — the four salaries, not the £200,000 — and a present-tense figure is the only kind anyone can act on. Once that ranked list exists, the costliest items become Quick Wins: targeted fixes built and delivered inside six weeks, structured so the business sees a verifiable saving before it is asked to commit to anything larger.
What this looks like when a company gets it right
Consider the pattern we commonly see in mid-market professional-services firms that have already been through a painful technology write-off. The brief, when they finally restart, is rarely “implement a new system.” It is closer to “find out what is actually costing us money, and fix the things that can be fixed quickly.” The first phase is a process diagnostic rather than a technology audit: where is the most skilled time being spent on manual work, and what is each of those steps costing in payroll every year?
In engagements that follow this shape, the early work typically lands on a handful of processes that clear the 0.5 FTE threshold comfortably, and the first automations go live within the quarter rather than eighteen months out. The systems involved are usually unremarkable; the discipline is what carries the result. Diagnose the P&L impact first, build only what the numbers justify, and put a measurable saving in front of the business before asking it to extend any further trust. It is, from the operational level up, what a credible digital transformation strategy actually looks like — and a firm working this way is no longer making decisions against the ghost of its last project, but against the cost of its current one.
What to do before the next vendor conversation
If a fix has been sitting on your desk while the memory of the last project keeps it there, three questions are worth answering honestly before anyone calls a vendor. Can you name, in payroll terms, what the current problem costs you each year it goes unsolved? Does the proposed fix have a forward saving attached that a CFO could verify? And can the first proof point arrive within a quarter rather than at the end of a multi-year programme?
A Profit Leak Diagnostic — a short, costed map of where operational money is actually going, ranked by return — is one structured way to produce those answers, but the questions matter more than the format. What they have in common is that none of them can be answered with a figure from the past. They force the decision onto the only ground where it can be made well: what the problem costs now, and what the fix returns from here.
The number that should weigh most
The next time a fix lands on your desk and the instinct is to point at what the last one cost, notice which direction your reasoning is facing. The cost that should weigh most is rarely the one already on an old invoice — it is the one nobody has calculated yet: what the unsolved problem quietly takes out of the business for every quarter the decision waits.
