When technology leaders in capital markets discover a critical workflow running in Excel, the instinct is usually to eliminate it. The spreadsheet is treated as evidence of failure, proof that the expensive platform isn't being used properly, that governance has broken down, that someone has gone rogue.
That instinct is almost always wrong.
The spreadsheet exists for a reason. It exists because the platform doesn't quite match how the person actually works. It's not a failure of discipline or governance. It's a precise, user-constructed solution to a problem the official system doesn't solve. And that makes it one of the most valuable diagnostic tools available to anyone trying to understand where the real friction in an operation lives.
Stop trying to kill it. Start asking why it exists.
What spreadsheets are actually telling you
I've encountered spreadsheets performing extraordinary functions in firms with seven- and eight-figure technology stacks. Risk calculations running in Excel because the risk system doesn't surface the specific view the trader needs at the speed they need it. Position aggregations happening in a shared workbook because the official blotter doesn't handle multi-asset netting the way the desk thinks about their book. P&L reconciliations running as a daily manual exercise because two systems disagree on valuations by an amount small enough to explain away but large enough to matter.
In every case, the spreadsheet is a diagnostic. It tells you exactly what the official system fails to do. The column structure reveals the information the user needs. The manual inputs reveal where data doesn't flow automatically. The formulas reveal the logic the platform was supposed to encode but didn't. The frequency of use reveals how critical the gap is.
None of this information typically appears in requirements documents or system audits. It lives in the workflow itself, visible only if you're looking for it.
The governance trap
The standard response to spreadsheet proliferation in capital markets is a governance initiative: inventory the spreadsheets, classify the risks they represent, and either integrate them into official systems or mandate that they stop being used.
Governance initiatives of this kind reliably miss the point.
They treat spreadsheets as a compliance problem when they're actually an operational signal. They focus on eliminating the symptom, the unauthorised tool, without understanding the cause, the gap in the official tool. And they're often counterproductive: when you remove a load-bearing workaround without replacing what it does, the operation either degrades or the workaround reappears somewhere else, usually less visible and therefore harder to manage.
I've seen this happen. The governance programme runs. The spreadsheets get reclassified or retired. Three months later, the same workflows are running in a shared drive that nobody's catalogued, or in a communication platform that operates outside the technology perimeter, or in a combination of manual steps that are even harder to audit than the original spreadsheet.
The workaround didn't go away. It went underground.
What to do instead
The right response to a critical spreadsheet is to understand it before touching it.
Map what it does. Map what data it consumes and where that data comes from. Map what decisions it supports and how frequently those decisions are made. Map who uses it and what they would do if it weren't available.
Then ask: why doesn't the official system do this? Is it a capability gap? A configuration gap? A data gap? A workflow gap?
The answer to that question tells you what you're actually dealing with. A capability gap requires a different response from a configuration gap. And none of them can be addressed properly without understanding which one you have.
This is also where the cost of the gap becomes visible. A spreadsheet running a critical daily calculation by a senior trader is not a minor governance issue. It's a risk concentration, a key-person dependency, and an indication that a significant business function is operating outside the systems designed to control it.
The broader principle
Spreadsheets are the most visible manifestation of a broader pattern: the workaround that has become architecture. They're easy to spot because they're tangible. But the same diagnostic principle applies to everything that people do outside the official systems to make their work function — the manual step in the settlement process, the standing instruction in the chat thread, the informal rule that everyone on the desk knows and no system has encoded.
These aren't failures of process. They're evidence of gaps between the operation and the architecture. And the organisations that treat every workaround as a diagnostic rather than a compliance problem are the ones that build technology that actually fits how people work, rather than technology that people work around.
The spreadsheet isn't your problem. The gap it's filling is. Find the gap first.