It started as a favor. One tab. A few formulas. You emailed it once, then again with “_v2,” then “_final,” then “_final_USE_THIS.” Six months later it is the unofficial ledger for a whole team, it only opens correctly on your laptop, and three executives just quoted three different totals from three different copies. That is not a spreadsheet. That is a liability with a grid.
This is Part 1 of From spreadsheets to real data, a series for people who live in Excel or Google Sheets and want habits that scale without pretending you must become a full-time engineer tomorrow. We start with the honest question: when does a handy file become something you should not trust with a real decision?
What you’ll learn
- The liability ladder: from handy tool to decision risk
- Red flags that the sheet has outgrown its design
- Who owns “truth” when copies multiply
- What to do Monday morning without a warehouse project
- How this series connects to SQL (and later, cleaner tables)
Spreadsheets are not the villain
Sheets are excellent at exploration, small models, one-off analyses, and personal tracking. The problem is not the tool. The problem is using a personal calculation surface as a multiplayer system of record without the habits that multiplayer systems need: one definition, one owner, one place to look, and a way to recover when something breaks.
If you already work through problem framing from Analytics foundations, you know a fuzzy decision plus fuzzy data is expensive. A fuzzy spreadsheet multiplies both. You get speed early and confusion later, paid for in meetings that argue about which file is right.
The liability ladder
Example:
Most disasters do not start evil. They climb a ladder.
| Stage | What it looks like | Risk |
|---|---|---|
| Handy | One tab, one owner, clear purpose | Low |
| Popular | Copies emailed; “latest” is ambiguous | Medium |
| Sacred | Called source of truth; many tabs; few understand all of it | High |
| Fragile | Broken links, macros, tribal knowledge | Very high |
| Liability | Wrong number drives hiring, pricing, or board narrative | Existential for trust |
Your job is not to ban spreadsheets. Your job is to notice when you have left “handy” and still treat the file like a notebook only you use.
Red flags: past “handy”
- Multiple “latest” files in email or Drive with no single link.
- Tab archaeology: final, FINAL, use_this, archive_old, don’t_delete.
- Formula chains nobody can explain in one sentence.
- Environment dependency: only works on one machine, one locale, one offline copy.
- Fear of sorting or filtering because “something breaks.”
- Systematic disagreement: two teams cannot reconcile totals within a known tolerance.
Who owns truth?
When a sheet becomes multiplayer, ownership is the first missing field. “We all own it” means nobody owns it. Put a name on the contract:
| Role | Responsibility |
|---|---|
| Metric owner | Defines what the number means in plain language |
| Data steward | Keeps the file/link, access, and refresh process |
| Consumer | Uses the number; may not edit definitions |
| Escalation | Who decides when two versions conflict |
If you cannot name those four for a “sacred” sheet, you already know why people argue. Ownership is not bureaucracy. It is a fire extinguisher label.
A worked scene: the board total that would not sit still
Ops tracks weekly orders in a shared sheet. Sales keeps a personal copy with “adjustments.” Finance pulls a PDF export from last Tuesday. In the board prep meeting:
- Ops: 12,400
- Sales: 13,100 (includes verbal commits)
- Finance: 11,950 (excludes a region mid-migration)
All three can be “correct” relative to their silent definitions. The liability is not math. It is the absence of a single agreed grain, exclusion list, and source link. The fix for Monday is not “build a warehouse.” The fix is stop pretending three files are one number.
What to do Monday (before any migration)
- Pick the canonical link. One Drive/SharePoint/Sheets URL. Retire email attachments as “official.”
- Write the one-sentence definition of the main metric at the top of the file.
- Name the owner and last-refreshed date in cell A1-ish (visible, not buried).
- Freeze a weekly snapshot tab or export so history is not only “whatever the cells say today.”
- List known lies: filters people forget, regions missing, manual overrides.
These steps are boring. They also prevent the liability stage more often than a shiny new tool does.
When to leave the grid (signals, not snobbery)
Move toward structured data (database, warehouse, proper tables) when several of these stack:
- Multiple concurrent editors need reliability
- Row counts grow past comfortable human review
- You need joins across systems regularly
- Auditors or customers will ask how the number was built
- The same “clean” work is repeated every week by hand
That path is what the rest of this series is for: tables instead of freeform cells, keys and IDs, cleaning habits, clean exports, and a one-page table contract. SQL skills from the SQL series become useful once the sheet stops being a secret second database.
A tiny “truth log” you can paste into the sheet
TRUTH LOG (keep on a tab named _meta)
Canonical URL: ________________
Metric (1 sentence): ________________
Grain (one row = ): ________________
Owner: ________________
Steward: ________________
Refresh cadence: ________________
Last refreshed: ________________
Known exclusions: ________________
Known manual overrides: ________________
Do not use for: ________________
Escalation if conflict: ________________If filling that block feels hard, the sheet is already carrying more load than its documentation admits.
Common mistakes
- Blaming “Excel” instead of ownership and process
- Adding more tabs instead of one clear definition
- Protecting the file with obscurity (“only I understand it”)
- Jumping to a warehouse project without fixing definitions first
- Treating email attachments as version control
How to practice this week
- Inventory three “important” sheets. Place each on the liability ladder.
- For the worst one, write the one-sentence metric and grain.
- Create or clean a single canonical link. Tell consumers in writing.
- Add a _meta truth log tab. Fill it with an owner in the room.
Why “we will clean it later” rarely happens
Every fragile sheet has a story about the future: we will rebuild it after the quarter, after the hire, after the migration. Later is where technical debt goes to become culture. The sheet keeps working just well enough that pain is intermittent. Intermittent pain does not fund projects. It funds heroics.
So design for the world you are in. If the file is already multiplayer, invest in ownership and definition now. If it is still personal, keep it personal on purpose. The liability is pretending a personal tool is institutional infrastructure.
Language that helps in the meeting
- “Which URL is canonical, and who owns the definition?”
- “What does one row mean in this tab?”
- “What are we silently excluding?”
- “If two copies disagree, who wins?”
- “Is this decision reversible enough for a fragile number?”
These questions sound simple. They are how you stop treating spreadsheet chaos as a personality trait and start treating it as a design problem. The rest of this series gives you concrete table habits. This part only asks you to stop climbing the ladder with your eyes closed.
Personal tool vs institutional infrastructure
A useful distinction: personal tools optimize for the person holding the keyboard. Institutional infrastructure optimizes for strangers who will use the number next quarter without you in the room. Spreadsheets can be either. Trouble starts when a personal tool is treated as infrastructure because it is convenient, not because it was designed for that job.
Ask: if you went on vacation for three weeks, could someone reproduce the number from written rules alone? If the answer is no, you do not have infrastructure. You have a performance. Performances are fine for exploration. They are expensive when they appear in board packs and customer commitments.
Copy-paste culture and silent forks
Email attachments and Drive “Make a copy” create silent forks. Each fork starts honest and then diverges: a filter left on, a row deleted, a manual override for one customer. Nobody intended fraud. Everyone intended speed. The organization now has three truths and no protocol for reconciliation.
Version control for code exists because forks are inevitable. Spreadsheets in the wild often skip that lesson. A canonical URL plus a dated snapshot tab is not glamorous. It is how you stop arguing about which attachment won.
How this series will help (map ahead)
- Part 2: tables, not freeform cells
- Part 3: keys and IDs in plain English
- Part 4: cleaning in Sheets before analysis
- Part 5: exporting cleanly toward SQL or a warehouse
- Part 6: a one-page table contract
You do not need all six tomorrow. You need to stop calling a fragile multiplayer file “just a sheet” when it already runs part of the business. Liability starts as a habit of language. Fix the language and the next technical step becomes obvious.
Quick recap
Spreadsheets become liabilities when they act as multiplayer systems of record without ownership, definition, and a single place to look. Watch the ladder from handy to sacred to fragile. Red flags are social as much as technical: copies, fear of sorting, irreconcilable totals. Monday fixes start with a canonical link and a written definition, not a platform RFP.
Next in this series: Tables, not freeform cells (headers, one value per cell, tidy vs wide in plain language). Related: foundations on problem framing and good enough data.
Sources
- European Spreadsheet Risks Interest Group (EuSpRIG) research and case studies on spreadsheet risk in organizations: https://eusprig.org/
- Panko, Raymond R. work on spreadsheet error rates (widely cited overview papers on end-user computing error rates)
- Analytics Made Simple: Analytics foundations series; SQL series for structured query habits after sheets stop scaling
