Technology is not a toaster.

Somewhere in your kitchen there is a toaster that works exactly as well as it did the day you bought it. It has never asked you for a password. It has not updated itself overnight, it does not need to be told that daylight saving time has ended, and nobody on another continent is trying to break into it. When it finally fails you will throw it away and buy another. The whole relationship, from first slice to landfill, will have taken perhaps three minutes of thought.

That is a perfectly good way to own a toaster. It is a ruinous way to own technology, and yet it is how a surprising number of organizations do it. The platform is selected, the purchase is approved, the implementation is completed, and the asset is capitalized and depreciated. Then the money stops, because the thing has been bought. Some years later the organization discovers, usually at the worst possible moment, that what it bought was never a thing at all.

My argument is that the toaster model is a cognitive error, not a budgeting quirk. It is rooted in the way people reason by analogy. It is reinforced by the way accountants sort spending. And it is punished by three features of technology that toasters lack: technology lives in an environment that changes, it is connected to other things that change, and it has enemies. Understanding why the error comes so naturally is the first step toward not making it.

The metaphors we budget with

People rarely reason about new things from first principles. We reason by mapping them onto things we already understand. The linguist George Lakoff and the philosopher Mark Johnson argued that this mapping is not decoration laid over thought. It is much of the machinery of thought itself.¹ We talk about argument as war ("she attacked my position") and time as money ("we spent too long on this"). The metaphor then quietly decides which conclusions feel obvious.

Experiments show this matters for decisions as well as vocabulary. In a 2011 series of studies, the psychologists Paul Thibodeau and Lera Boroditsky gave people a short report about rising crime in a fictional city. For half the readers the report described crime as a beast preying on the city. For the other half it described crime as a virus infecting it. The statistics were identical. Yet readers of the beast version were more likely to recommend catching and jailing offenders, while readers of the virus version leaned toward diagnosing causes and treating conditions. Very few readers named the metaphor as the thing that had swayed them.²

Technology reaches the boardroom already wrapped in a metaphor, and the metaphor is a durable good. We buy systems, install them and own them, and we record them on the balance sheet beside trucks and buildings. Each of those words invites the inferences that hold for appliances. The purchase is the main cost. The object will perform as specified until it wears out. The prudent owner runs it for as long as possible. Those inferences are correct for a toaster. Figure 1 puts the two objects side by side, and very few of the inferences carry over.

Software doesn't wear out. Its world does.

There is an obvious objection to the comparison. Toasters do degrade. Heating elements burn out and springs lose their tension. Software, by contrast, is made of information, and information does not rust. A program that computed a correct payroll in 2019 will execute the identical instructions in 2029. Why should it need upkeep at all?

The answer was worked out half a century ago by Meir "Manny" Lehman, a computer scientist who studied how IBM's OS/360 and other large programs changed over time. Lehman observed that software used in the real world obeys a set of regularities that came to be called Lehman's laws. The first is the law of continuing change: a system in real-world use must be continually adapted, or it becomes progressively less satisfactory. The second is the law of increasing complexity: as a system is changed, its complexity grows unless work is done specifically to reduce it.³

The insight is that the decay is relative. The code holds still while everything around it moves. Tax tables change. The operating system underneath reaches the end of support, as Windows 10 did on October 14, 2025, for every organization that had put off the upgrade.⁴ The partners it exchanges data with change their formats. The business grows into new states, new service lines and new regulations. A program that stands still in a moving world is, in effect, moving backward.

Evolutionary biologists have a name for this predicament. In 1973 Leigh Van Valen proposed that species must keep evolving merely to hold their position, because their competitors, predators and parasites are evolving too. He called it the Red Queen hypothesis, after the character in Through the Looking-Glass who tells Alice that "it takes all the running you can do, to keep in the same place."⁵ Enterprise technology lives in a Red Queen world. Figure 2 shows what happens to a system that is funded to run on day one and then left standing.

Toasters don't have enemies

The Red Queen analogy turns literal when we get to security. A toaster's environment doesn't care about it. A networked system's environment contains people actively trying to subvert it, and those people learn.

Every month software vendors publish fixes for newly discovered vulnerabilities. Every month the publication itself becomes a map for attackers, who can compare patched and unpatched versions to work out what was broken. The interval between a fix being released and being applied is a window in which an organization is knowingly exposed. Closing that window is a lifecycle activity. A system run on the toaster model has nobody whose job it is to close it, because the lifecycle was never funded.

The best-documented illustration is the 2017 breach of Equifax. A fix for the Apache Struts vulnerability that attackers exploited was published on March 7, 2017. Equifax did not apply it. Attackers got into an online dispute portal in mid-May and went undetected for 76 days, until July 29. Personal data on roughly 148 million Americans was exposed.⁶ The flaw was not exotic, and the fix was free. What was missing was the unglamorous, recurring work of applying it, which is exactly the work the toaster model leaves out.

The accounting illusion

If the toaster model is so costly, why does it persist? Part of the answer lies in how organizations count.

Accounting standards allow the cost of acquiring and implementing software to be capitalized and spread over its useful life, much like a vehicle.⁷ The ongoing costs of patching, support, training and integration repair are generally expensed as they occur. There is nothing wrong with these rules; they describe the money accurately. But they split one economic object into two psychological ones. The purchase appears as a single, deliberated, approved investment. The upkeep appears as a scatter of operating expenses, each too small to debate and, taken together, too large to ignore.

The economist Richard Thaler called this mental accounting. People and organizations sort money into separate mental accounts, then make decisions within each account as if the others did not exist.⁸ A budget committee that would never approve a new system without a business case will happily trim the maintenance line that keeps the existing one alive. In its mental ledger, that system has already been paid for.

A second well-documented bias completes the picture. The planning fallacy, named by Daniel Kahneman and Amos Tversky in 1979, is the habit of forecasting a project from the inside, by imagining the plan going right, rather than from the outside, by asking how similar projects actually turned out.⁹ For technology the outside view is sobering. When Bent Flyvbjerg and Alexander Budzier examined 1,471 IT projects, they found an average cost overrun of 27 percent. Worse, about one project in six was a "black swan," with cost overruns averaging 200 percent and schedule overruns of almost 70 percent.¹⁰ Many of those overruns are, I suspect, the deferred lifecycle arriving all at once, as an emergency migration or a rebuild that should have been a series of upgrades. Figure 4 shows the purchase order an approval committee sees, and the receipt that keeps printing after it.

Objections, considered

An argument that ends in "spend steadily on maintenance" deserves suspicion, especially when a technology executive makes it. So consider the strongest objections.

"This is just a case for bigger IT budgets." It isn't. The lifecycle model does not require spending more in total. Often it means spending less, because a planned upgrade costs a fraction of a forced one. What it requires is spending on a schedule the organization chooses, rather than one imposed by an outage, an auditor or an attacker. The real question is when the money is spent, and who decides.

"Cloud software solves this, because the vendor maintains it." Software as a service moves part of the lifecycle to the vendor, which is often a good trade. It doesn't remove the lifecycle. The vendor's product keeps changing, so your configurations, integrations, reports and training must keep changing with it. Renewal prices change. The data still has to be governed, and one day it will still have to be moved. The receipt keeps printing; some of the lines are simply in another company's ink.

"Running an asset into the ground is sometimes rational." Sometimes it is. A system that is cut off from networks, has few interfaces, faces no regulatory change and supports a stable process can run for years on very little. Treating that system like a toaster is fine. The claim is not that every system is a living thing. It is that each decision should be made deliberately, system by system, based on its connections, its exposure and its rate of change. It should not be inherited by default from a metaphor.

The question for a board isn't what the system costs. It's what it costs to keep it worth having.

Owning technology like what it is

What does the alternative look like in practice? It looks less like buying an appliance and more like keeping a fleet, maintaining a building or, closest of all, sustaining a team.

• Fund capabilities, not projects. A project ends. A capability, such as eligibility verification or patient scheduling, lasts as long as the business needs it. Budget for it across its whole life: acquisition, operation, improvement and retirement.
• Give every system an owner after go-live. The most dangerous day in a system's life is the day the implementation team disbands. Someone must be accountable for its health, with a budget to match.
• Report age and exposure the way you report financial risk. Which systems are within a year of losing vendor support? How many days pass, on average, between a security fix being published and being applied? These numbers belong in front of the board, not only the IT steering committee.
• Plan the exit at the entrance. Every platform will be replaced. Contracts, data models and architectures chosen with retirement in mind turn that replacement into a project rather than a crisis.

Back to the kitchen

Metaphors are not lies. They are tools, and the toaster is an excellent one for toasters. The trouble begins when a metaphor that fits the purchase is allowed to govern the ownership. The systems that run a modern organization are not appliances sitting on a counter. They take part in an environment that changes. They are connected to neighbors that change. They are watched by adversaries who change. They need what every living thing needs: continuing investment, simply to remain what they were on the day they arrived.

Buy toasters like toasters. Own technology like what it is.