Q-Day Is Coming
A recent cyber security roundtable led me to read more about Q-Day, quantum computing, and why the future of encryption may be a business issue long before it becomes a technical crisis.
Read →Most splinter spreadsheets do not begin with bad intentions.
They begin with urgency.
A missing report.
A delayed system change.
A customer needing an answer now.
A process nobody officially owns.
So somebody exports data, adds a few columns, and creates a spreadsheet “just for tracking.”
And then the business continues around it.
Databases are designed to create consistency.
They enforce:
They aim to establish a single operational reality.
A customer has one account.
An order has one status.
A stock item has one quantity.
At least in theory.
The database becomes the system of record; the place the organisation agrees reality exists.
But operational pressure rarely waits for perfect system design.
Spreadsheets thrive because they solve problems quickly.
No development cycle.
No project board.
No change request.
No approval process.
Just:
That flexibility is precisely why spreadsheets are so valuable.
And also why they become dangerous.
The spreadsheet is not the villain. In many organisations, it is the fastest tool available to people trying to solve real problems.
But once spreadsheets begin collecting operational data independently from the source system, something subtle starts to happen.
Reality begins to fork.
Most businesses do not notice the moment it happens.
A spreadsheet originally created for temporary tracking slowly becomes embedded into operational process.
Extra columns appear.
Manual statuses are added.
People begin updating it directly instead of the system.
New reports start depending on it.
Copies get emailed around.
Local versions emerge.
Eventually, different teams begin operating from slightly different datasets.
Sales has one version.
Operations has another.
Finance has a third.
All technically “correct.”
All producing different answers.
At that point, the problem is no longer:
“Which number is right?”
It becomes:
“Which reality are we operating in?”
Databases expose structure.
Spreadsheets often conceal it.
Inside a mature database system:
In a spreadsheet, logic quietly hides itself inside cells.
A critical calculation may exist only in:
One incorrect paste operation can silently alter outcomes for weeks.
And unlike structured systems, spreadsheets rarely announce when integrity has been compromised.
They simply continue producing answers.
A spreadsheet copied onto a desktop immediately detaches itself from most organisational controls.
No validation.
No enforced permissions.
No central ownership.
No guaranteed backup.
No audit trail.
Yet because the file still opens, still calculates, and still gets emailed around, the operational risk remains largely invisible.
That invisibility is what makes splinter spreadsheets so dangerous.
They often feel reliable right up until the moment they fail.
Many operational shadow systems begin with the same sentence:
“This is only until the system gets updated.”
But businesses are busy.
Priorities shift.
Projects get delayed.
Processes adapt around workarounds.
And over time, the temporary spreadsheet becomes infrastructure.
Entire reporting processes start depending on it.
Management meetings reference it.
Teams reconcile against it.
People trust it.
Even when nobody is entirely sure how it works anymore.
Eventually, ownership collapses into individuals.
“There’s only one person who understands that file.”
That sentence should concern any organisation.
Because it means operational continuity no longer exists within systems; it exists inside human memory.
The spreadsheet becomes:
People become afraid to touch formulas.
Macros become untouchable artifacts.
Columns survive long after their original purpose has been forgotten.
At this stage, the spreadsheet is no longer a tool.
It is an unofficial application.
Just without the engineering discipline normally required to support one.
One of the clearest warning signs of fragmented operational truth is when teams spend more time explaining numbers than acting on them.
Mature organisations can spend surprising amounts of time reconciling:
This creates organisational drag that rarely appears on any KPI.
Energy shifts away from:
and toward:
The business becomes slower, not because data is missing, but because too much disconnected data exists simultaneously.
Spreadsheets do not appear because employees enjoy creating operational risk.
They appear because the business needed something faster than the system could provide.
A missing workflow.
A reporting gap.
Poor usability.
Slow change processes.
Lack of ownership.
Operational urgency.
And often, they appear because people genuinely believe they are helping.
A team starts capturing “extra useful information.”
Someone adds a tracker to improve visibility.
A department creates its own status column because the official system does not reflect operational reality closely enough.
Individually, these decisions are usually sensible.
People are trying to:
But when multiple teams begin capturing their own versions of operational data independently, fragmentation begins to spread quietly across the organisation.
The splinter spreadsheet is usually a symptom before it is a problem.
And organisations that attempt to ban spreadsheets entirely often discover they are treating the outcome rather than the cause.
The goal is not to eliminate spreadsheets.
That would be unrealistic.
The goal is to understand why they appeared.
Because every splinter spreadsheet tells a story:
Some spreadsheets should remain lightweight tools.
Others are signals that the business has already outgrown part of its operational design.
The danger is not the spreadsheet itself.
The danger is when unofficial systems quietly become the place the business truly operates from, while the database merely becomes where the data originally came from.
A recent cyber security roundtable led me to read more about Q-Day, quantum computing, and why the future of encryption may be a business issue long before it becomes a technical crisis.
Read →Confusion is rarely accidental. It’s often the result of deferred decisions, vague ownership, and flexible definitions. Clarity doesn’t emerge by chance; it is deliberately designed.
Read →Leadership isn’t only visible in large programmes and budgets. The ability to design and maintain small, stable systems close to real work is often the clearer test of operational maturity.
Read →