The Spreadsheet That Runs Your Company Is a Signal, Not a Crime

Somewhere in your company right now, a spreadsheet is doing the work of a database. It has a name like Q3_tracker_FINAL_v4_use_this_one. It pulls from three systems that were never supposed to talk to each other. Exactly one person knows how the formulas work, and she's on vacation next week.

That spreadsheet is shadow IT. So is the Zapier account on a marketing manager's personal credit card, the Python script that reconciles invoices every Friday at 6 a.m., and the little dashboard a support lead built over two weekends because the official reporting tool takes eleven clicks to answer one question.

The standard corporate response is a compliance email. The more useful response is to treat this stuff as what it actually is: an unfunded, unsupervised, surprisingly effective R&D department that has been quietly telling you what's broken for years.

Nobody Builds a Workaround for Fun

Here's the thing about people who build their own tools: they almost never wanted to. They wanted the official path to work. They filed the ticket, sat through the training, tried the sanctioned tool, and then hit a wall that nobody was going to move for them.

So they built the thing themselves, on their own time, with whatever was within reach.

That's a behavioral signal you can't buy from a consulting firm. It's a person telling you, in the most concrete terms available, this process costs more than it should and I have proof. Every workaround is a small, self-funded experiment that already has a user, a use case, and a track record.

What the Compliance Deck Leaves Out

To be fair to the security folks: they're not wrong. Shadow IT creates real problems. Data ends up in places nobody is backing up. Dependencies go unpatched. When the builder leaves, an undocumented process leaves with them — and in a bad case, so does access they shouldn't have had.

But risk assessments measure what's visible. They don't measure the cost of the official process being slow, or the revenue sitting in a spreadsheet nobody sanctioned, or the fact that a five-person team has been running on duct tape and goodwill for eighteen months.

A shadow IT inventory is, almost by accident, a map of unmet needs. Read it that way and it stops being a list of incidents and starts being a backlog.

Treat It as an Intake Funnel

The interesting part isn't the tools. It's the people who built them. Someone who understands a business process deeply and can build something is a rare combination, and in most orgs they're sitting three levels down from anyone who would notice.

A lab is well positioned here. You already have the skills to evaluate a scrappy prototype on its merits. Point that at your own company's back alley and you get a pipeline of experiments with built-in product-market fit, because the market is one floor away and already using the product.

Surfacing It Without Starting a Panic

A few things that work better than an audit:

• Run an amnesty week. Ask people to show what they've built, explicitly promise no consequences for the first pass, and mean it. If the first person who raises a hand gets a security review and a lecture, nobody else raises a hand, and you learn nothing.
• Ask three questions per find. What does it do? Who depends on it? What breaks the day it disappears? Those three answers tell you more than any technical review.
• Log it in one place. Status, owner, dependencies, and a decision date. One row per tool. (More on that in our piece on experiment registries — the mechanics are the same.)
• Look for clusters. Three teams independently building invoice reconciliation isn't three incidents. It's one missing platform feature with three proofs of concept attached.

Triaging What Comes Back

Most finds fall into four buckets, and the sorting is quicker than you'd expect.

Absorb. The need is real and recurring. Rebuild it inside the supported stack, but take the requirement, not the code. Interview the builder before you abstract anything, because the script's edge cases are the actual business rules.

Adopt. It's already load-bearing and reasonably sound. Give it a budget, an owner, and a security review — in that order, ideally, but at least all three.

Retire. The official tool can do this now, or the process died. Shut it down cleanly and tell the people who depended on it, with a date.

Document and leave alone. Low risk, low blast radius, one user. Not everything needs to be centralized. Sometimes the right answer is a note in the registry and a better password.

The Awkward Question Underneath

If a marketing coordinator with a weekend and a free tier built something better than the platform you spent six figures on, that's not primarily a story about a rogue employee. That's a verdict.

Labs are fond of running innovation programs to find out what people want. Most of them could save the money and read the shared drive instead.

The Goal Isn't Zero Shadow IT

People will always build workarounds. The friction that creates them is a moving target, and the sanctioned tool will always be a step behind someone's actual Tuesday.

The realistic goal is zero undocumented shadow IT. Know what's out there, know who's holding it together, and have an opinion about which pieces deserve a real budget. Everything else is just hoping the person with the formulas doesn't quit.