Every Company Has a Load-Bearing Spreadsheet. Name Yours.

Every Company Has a Load-Bearing Spreadsheet. Name Yours.

fragilityspreadsheetsrisk

Somewhere in your company, a spreadsheet is in production. Not a model somebody is playing with. A file that, if it stopped working on a Tuesday, would stop a number that somebody acts on by Wednesday.

You probably know which one. Most people do, if they're honest. They just don't say it out loud, because saying it out loud creates an obligation.

Two that got named in public

In early October 2020, Public Health England disclosed that 15,841 positive COVID tests recorded between 25 September and 2 October had never made it into the daily case count. The labs had sent clean CSV files. The step that fed the national dashboard loaded them into an Excel template saved in the old .xls format, which stops at 65,536 rows. Each test result took several rows, so the template filled up at roughly 1,400 cases and silently dropped the rest. On 30 September the country was told it had 7,108 new cases. The corrected figure was 10,157. Contact tracing for those people started up to a week late, while cases were climbing.

The file didn't crash. Nothing went red. The dashboard rendered a number every day, and the number was wrong by a third.

Three years earlier, a different spreadsheet had already done its damage. In 2010, two prominent economists published a paper finding that countries with public debt above 90% of GDP grew far more slowly, a result cited in budget fights across Europe and the US. In 2013 a graduate student trying to replicate it got the authors' working file and found that a formula range had skipped five countries. With the rows restored and a couple of other choices undone, the average growth for the high-debt group went from negative 0.1% to positive 2.2%. The authors disputed how much the correction changed the conclusion. Nobody disputed that the number governments had been quoting came out of a cell range that stopped too early.

Neither of these was a spreadsheet problem, exactly. Excel did what it was told. Both were a case of a file quietly promoted from "something someone put together" to "the thing the number comes from," with nobody signing off on the promotion.

Why it persists

I'll concede the obvious objection first: spreadsheets are great. They are the most successful end-user programming tool ever built, and a lot of them are doing exactly the job they should. The problem isn't the tool. It's the one file that has stopped being a tool and started being infrastructure.

That file stays in place because every incentive points at leaving it alone.

The person who built it has no reason to flag it. Flagging it means admitting that the Monday number depends on a VLOOKUP they wrote in a hurry two years ago, and the reaction to that admission is rarely gratitude.

The people who consume the number have no reason to ask. The number arrives. It has arrived every week for two years. Asking where it comes from is a question that can only make your week worse.

And replacing it costs visible money. Somebody has to rebuild the logic in a system with an owner, test it, run both in parallel, and explain the differences when they don't match. That's a line item. The cost of leaving it alone is zero, right up until the week it isn't, and when that week comes the damage shows up somewhere else: a missed forecast, a late contact trace, a budget argument built on a wrong average. It gets booked as a bad quarter, not as a spreadsheet failure.

So the file sits there, load-bearing, unnamed, with a single row limit or a single formula range standing between the company and a number that is wrong by a third.

The money, roughly

Say an analyst spends four hours a week keeping the file alive. Refreshing the extract, fixing the one tab that breaks, pasting the output somewhere. At a loaded cost of $75 an hour that's about $15,000 a year, which nobody sees because it's inside a salary.

Now say the file fails the way PHE's did: quietly, for a week, in a direction that makes a decision look better than it is. The cost of that week depends entirely on what the number feeds. If it's a pricing decision on a product line doing $5 million a year, a week of acting on a number that's 30% off is worth more than the whole rebuild. If it's a vanity metric on a slide, it's worth nothing.

That's the point. The expected cost of the file isn't the four hours. It's the four hours plus the probability of a silent failure times what the number is attached to. Most companies know the first term and have never written down the second.

How to find yours

You don't need an inventory of every spreadsheet. You need the one or two that matter, and there's a fast test.

Ask: if the person who maintains this went on leave for three weeks with no handoff, which number would stop shipping, or ship wrong, without anyone noticing? Whatever file comes to mind first is the load-bearing one. There's usually a second.

Then ask what it feeds. Not "who looks at it," but which decision would be made differently if it were wrong by a third for a week. If the answer is "none," leave it alone and go back to work. If the answer has a dollar figure attached, that file has just become a project, and the project is small: move the logic somewhere with an owner, a test, and a row count that gets checked.

I'd guess most companies have exactly one of these that matters and a dozen that don't, and that the one that matters is the one its owner is least eager to talk about. That's the tell. The silence around a file is a better indicator of its importance than anything in a systems diagram.

My bet is that the next public number to fall over will fall over the same way: not from a crash, but from a file that kept rendering a plausible figure after it stopped being right. The question isn't whether you have one. It's whether you'll name it before it names itself.

Your data, our problem.

Work With Us