Somewhere in your organization there is a spreadsheet. It tracks something the system you pay for is supposed to track. One person maintains it, several people quietly depend on it, and it is more accurate than the official record. Every leader who finds one has the same reaction, which is to ask why people are not using the proper system. That is the wrong question, and asking it is how the spreadsheet survives another two years.
The shadow spreadsheet is a bug report
Nobody builds a parallel tracker for fun. Maintaining one is genuinely unpleasant: it is manual, it is fragile, it breaks when the person who owns it takes leave, and everyone involved knows it should not exist. People do it anyway because the cost of maintaining it is still lower than the cost of the thing it is working around.
Which makes it the most reliable diagnostic instrument you have. Survey your staff about your software and you get politeness. Look at what they built next to it at their own expense and you get the truth, itemized, with the priority order already worked out by whoever was in the most pain.
So the useful question is not why people went around the system. It is what specifically the spreadsheet does that the system does not, because that answer is nearly always one of five things.
Five things a shadow tracker is telling you
| What the spreadsheet does | What it means | Usual fix |
|---|---|---|
| Holds a field the system has nowhere to put | Your data model is missing something central to the work | Add the field, or accept the system is the wrong shape |
| Shows one view across things the system keeps apart | The system stores it but cannot answer the question people ask daily | A report or a saved view, not a new tool |
| Tracks a status the system has no concept of | Your real process has a stage the software never modelled | Model the stage, or fix a process that grew a stage it does not need |
| Exists to be shared with people who have no login | A permissions or licensing wall, not a capability gap | Guest access, a public view, or cheaper seats |
| Duplicates the system exactly, in a nicer layout | Nobody trusts the official record, usually with cause | A data cleanup, not a feature |
Notice how few of those are requests for new software. Two are configuration, one is a permissions setting, one is a process problem wearing a software costume, and one is a data quality problem that no purchase will fix. The instinct after finding a shadow spreadsheet is usually to go shopping. The evidence rarely supports it.
Nobody maintains a spreadsheet by hand because they enjoy it. They do it because it is still cheaper than the alternative you provided.
Why telling people to stop does not work
The standard response is a policy: from now on, everything goes in the system. It fails every time, and it fails in a predictable way.
- The need does not go away. Banning the workaround without fixing the gap just moves the tracker somewhere less visible, which is strictly worse. The next version lives on someone’s personal drive.
- The person maintaining it is your best operator. They noticed a gap and closed it without being asked. Treating that as non-compliance is a fast way to teach your most capable staff to stop noticing things.
- Accuracy usually lives in the shadow copy. Forcing everyone back to the official record often means moving to worse data, and people can tell. One round of that and they will never trust the system again.
- It reads as blame for a decision they did not make. The gap was created by a purchase, a configuration, or a licence tier that staff had no say in.
Consolidation is worth doing. It is worth doing as a response to a diagnosis, not as a substitute for one.
Auditing yours in an afternoon
This is a half-day exercise, not a project, and it works best when it is explicitly framed as harmless.
- Ask the question without the judgement in it. The wording matters more than anything else here. Ask what people keep track of outside the official system to get their job done, say plainly that nobody is in trouble and that you are trying to find out where the tools are failing. Ask in a way that allows a private answer.
- Count the ones you already knew about. Leaders typically know about one or two. Most organizations of thirty people have between five and fifteen. The gap between those two numbers is itself a finding.
- For each one, write down the single question it answers. Not what it contains, what it is for. “Which families still owe for camp.” “Which clients are past thirty days.” “Who has a key to the annexe.” One sentence each. This is the entire value of the exercise.
- Sort by blast radius, not by annoyance. Rank by what happens if the owner leaves tomorrow and the file goes with them. A tracker holding safeguarding records, key holders, or outstanding payments is a business risk. A personal to-do list is not.
- Map each one to the five categories. Missing field, missing view, missing status, permissions wall, or trust problem. The category tells you what kind of fix it needs, and it stops every item turning into a software evaluation.
- Fix the two cheapest ones this week. Add the field. Build the saved view. Do it publicly and tell the person who built the workaround that their spreadsheet is now redundant. Nothing else you can do will get you a more honest answer next time you ask.
The ones worth keeping
Not every shadow tool is a defect. A spreadsheet is an excellent piece of software for genuinely temporary work: a one-off analysis, a seating plan for a single event, modelling three budget scenarios you will throw away on Friday. Forcing that kind of thing into a structured system is its own form of waste.
The line is durability and dependency. A file that only its author uses, for a task that ends this month, is a tool. A file that other people rely on, that holds the only copy of something, or that has quietly run for more than a quarter has become infrastructure, and infrastructure maintained by one person in a spreadsheet is a risk with a name and a start date.
- Does anyone else depend on it? The moment a second person reads it to make a decision, it is a system of record.
- Is this the only copy? If the answer disappears when the file does, it needs to live where your backups and permissions already reach.
- Has it outlived its excuse? Anything described as temporary that is older than three months is permanent, and should be treated that way.
- Would a new starter find it? If onboarding requires being told a file exists, you have undocumented infrastructure.
Anything that fails those tests belongs in the system that already holds the people, projects, or money it refers to. The reason a single connected platform reduces this problem is not that it has more features, it is that the field you needed can be added next to the record it describes, and the view you wanted can be built from data that is already there. Whether that is one connected system or a better-configured version of what you own, the fix is the same shape: close the gap, then retire the workaround in public.
Key takeaways
- Treat the shadow spreadsheet as evidence, not disobedience. It is an unprompted, prioritized report on where your tools fail.
- Diagnose before you buy. Most shadow trackers point at a missing field, a missing view, or a permissions wall, none of which need new software.
- Rank by what breaks if the owner leaves. Blast radius, not irritation, is the right priority order.
- Retire workarounds by making them redundant. Fix the gap first, publicly, and the spreadsheet closes itself.
Questions to ask your team
How do I get honest answers when I ask what people track on the side?
Say explicitly that nobody is in trouble, ask what they keep outside the system to get their job done rather than what rules they are breaking, and allow a reply in private. Then fix something small within the week, visibly. The second audit is only as honest as what people saw happen after the first.
Is this an argument for consolidating onto one platform?
Often, but only after the diagnosis. If most of your findings are missing views and permissions walls across four disconnected tools, consolidation genuinely fixes them. If they are all one underused system with dirty data, a migration will move the mess rather than solve it.
What if the spreadsheet really is better than the software?
Then say so out loud and write down exactly which three things it does better. That list is the most valuable input you will have at renewal, and it is far more persuasive to a vendor than a general complaint.
Who should own this audit?
Whoever can actually authorize a configuration change, not whoever owns the software relationship. An audit that produces findings nobody can act on teaches people that raising them is pointless.
