Your Most Fragile Production System Is Probably a Spreadsheet

Everybody in operations knows this pattern.

A spreadsheet gets built to cover a gap for two weeks. Six months later, it still runs quarter-end, while an inbox rule nobody documented routes escalations and a shared login keeps a critical task moving.

The spreadsheet usually isn't the problem

The useful way to read a workaround is as a process map. If a team built a side spreadsheet, there's usually a handoff, approval, or tool boundary that the official workflow doesn't handle well.

Teams don't invent friction for fun, and they usually don't choose shared logins or mailbox rules because they love bad practice.

A hack that survives for a year isn't a hack anymore. It's a production dependency with no owner, no SLA, no change control, and usually no backup plan.

You notice how serious that is when the one person who understands it goes on leave, exits the company, or changes one formula and breaks the chain. That's when "temporary" gets expensive.

Hidden dependency is the real risk

The broader data points in the same direction.

In operations, that debt often shows up first in unofficial systems people rely on every day.

And teams keep using those systems for understandable reasons.

That's why they spread. They solve the immediate problem, then the work outgrows the controls.

What makes a workaround dangerous?

• No clear owner
• No access hygiene
• No monitoring or alerting
• No backup plan when it fails

Classify by blast radius, not by formality

Most companies miss the threshold. If a workaround survives one quarter, stop calling it temporary.

At that point, ask the same questions you'd ask of any production system:

• Who owns it?
• What breaks if it disappears tomorrow?
• Who has access?
• What are the failure modes?
• Is it backed up?
• Should it be hardened or replaced?

You don't need a giant transformation program to start. You need a blunt inventory.

Ask "What breaks if this sheet, mailbox rule, or login disappears tomorrow?" That usually surfaces the real dependency map faster than polished architecture diagrams do.

Then classify by blast radius, not by formality. If a spreadsheet controls billing exceptions, it's production. If a mailbox rule routes revenue-impacting requests, it's production. If a shared credential is required to complete a regulated workflow, it's production.

Treat it that way.

Different environments. Same pattern.

The scariest production system in many companies isn't the one in the cloud console. It's the one nobody admits is production at all.

Usually it sits in a shared drive, a mailbox rule, or a credential three people shouldn't be using.