The Spreadsheet That Runs Your Company (And Why That Should Worry You)

Every growing company seems to have one spreadsheet that matters far more than anyone wants to admit.

Maybe it calculates pricing.

Maybe it decides commissions.

Maybe it tracks project profitability.

Maybe it tells the team who has capacity.

Maybe it controls purchasing.

Maybe it is the only place where someone can answer:

Can we afford this?

The problem is not Excel.

The problem is that the spreadsheet may have quietly become part of your production system.

A Spreadsheet Can Become Business Logic

Developers usually think of business logic as something that lives in code.

But in many companies, critical logic lives here:

pricing.xlsx
commission-final-v7.xlsx
resource-plan-master.xlsx
project-profitability-new.xlsx

And somewhere inside:

=IF(B17>0.35, "APPROVE", "REVIEW")

That looks harmless.

But it may encode a real business rule.

Maybe 0.35 is the minimum margin.

Maybe someone changed it from 0.30 six months ago.

Maybe nobody documented why.

Now the spreadsheet is not just calculating.

It is making policy executable.

That is when things get interesting.

The File Is Usually Not the Real Dependency

The obvious risk is losing the spreadsheet.

The deeper risk is losing the person who understands it.

You hear things like:

"Ask Priya, she knows how that sheet works."

or:

"Don't change column H."

or:

"There is a manual adjustment we do for enterprise deals."

That person has become part of the runtime.

The architecture now looks something like this:

Input data
↓
Spreadsheet
↓
Undocumented formula
↓
Person who understands exceptions
↓
Business decision

If that person is unavailable, throughput drops.

If they leave, knowledge leaves with them.

That is key-person dependency disguised as process.

The Company May Not Actually Own the Decision

This is the part I find most important.

Suppose the spreadsheet determines pricing.

Who owns pricing?

Not who edits the file.

Who owns the decision?

Those are different things.

A finance person may maintain the workbook.

Sales may consume the result.

A founder may approve exceptions.

But who owns:

the rule
the inputs
the threshold
the exceptions
the review cycle

If nobody can answer that clearly, the company does not really own the decision process.

It owns an artifact.

That is fragile.

Version Control Is Not Just a Git Problem

Developers understand versioning instinctively.

Business teams often experience a much less controlled version of it.

pricing-final.xlsx
pricing-final-2.xlsx
pricing-final-updated.xlsx
pricing-final-use-this-one.xlsx

Everyone laughs at this until two teams use different versions for real decisions.

Then it stops being funny.

If one version says a deal is profitable and another says it is not, which one is authoritative?

If the answer is:

Ask the person who created it.

you do not have a source of truth.

You have a human resolution layer.

Hidden Rules Are Hard to Audit

A spreadsheet can produce the right number for months while still containing the wrong assumption.

That is what makes this dangerous.

Consistency can look like correctness.

For example:

labor cost = 50/hour
commission rate = 8%
margin threshold = 30%
capacity factor = 0.85

Those values may have been correct when the model was built.

Are they still?

Who checks?

Who can change them?

Who should approve the change?

If nobody formally owns the logic, stale assumptions can quietly keep driving current decisions.

Spreadsheets Are Great at Exploration

To be clear, I am not anti-spreadsheet.

I use them.

They are excellent for:

testing ideas
modeling scenarios
comparing options
exploring data
building an early process

The problem is when exploratory tooling becomes permanent infrastructure without anyone deciding that it should.

The lifecycle often looks like this:

temporary analysis
↓
useful model
↓
shared file
↓
critical workflow
↓
unofficial system of record

Nobody planned the last step.

It just happened.

Not Every Spreadsheet Needs to Become Software

This is where technical teams can overreact.

You find the critical spreadsheet and immediately think:

We should build an app.

Maybe.

But software is not automatically the right answer.

A spreadsheet may still be perfectly adequate if:

usage is low
risk is limited
ownership is clear
inputs are controlled
rules are documented
one version is authoritative

The question should not be:

Can we replace this with software?

It should be:

Does the current system match the importance and frequency of the decision?

That is a better engineering question.

Treat Critical Spreadsheets Like Systems

If a spreadsheet is business-critical, treat it with some of the same discipline you would apply to software.

At minimum, clarify:

Owner
Inputs
Rules
Outputs
Access
Change control
Exception handling
Source of truth

You do not need enterprise governance around every workbook.

But if a file influences money, commitments, staffing, or customer outcomes, it deserves more than tribal knowledge.

A Practical Dependency Test

Here is a simple audit I would run.

1. What decision does this spreadsheet influence?

If nobody can answer quickly, that is already useful information.

1. How often is the decision made?

Daily decisions deserve more structure than occasional analysis.

1. Who understands the logic?

If only one person does, you have key-person risk.

1. Where do the inputs come from?

Manual copying increases error risk.

1. Is there one authoritative version?

If not, different teams may be making different decisions.

1. Who can change the rules?

If anyone can edit a critical formula, that is a control problem.

1. Can someone reproduce the decision?

If not, the process is not really transparent.

1. What happens if the file disappears tomorrow?

That question usually reveals the actual severity.

The Same Problem Exists With Dashboards and Internal Tools

This issue is not limited to spreadsheets.

A dashboard can become a hidden decision system.

So can:

Notion page
shared Google Doc
internal admin panel
Slack workflow
one senior employee's memory

The tool is secondary.

The important thing is whether a recurring business decision depends on undocumented logic or one person.

That is the operational smell.

Where an Integrator Fits

This is where I think the Integrator role becomes useful.

Not as the person replacing spreadsheets.

The job is to surface hidden decision infrastructure.

A useful sequence looks like:

Hidden tool or person
↓
What decision is happening here?
↓
Who owns it?
↓
What rules produce the answer?
↓
Where does the data come from?
↓
Who can change the rule?
↓
What happens on exceptions?
↓
Document / simplify / automate / integrate

That is much more useful than saying:

"We need better software."

Sometimes the spreadsheet stays.

Sometimes it gets replaced.

Sometimes only the inputs need automation.

Sometimes the actual problem is missing ownership.

The Goal Is Organizational Ownership

The real goal is not eliminating spreadsheets.

It is making sure the company owns the decision process.

That means the organization knows:

why the decision is made
who owns it
what rules apply
what data is required
who can change the rules
how exceptions work

At that point, the tool becomes replaceable.

That is a good sign.

If the business cannot make the decision without one file or one person, the tool is not supporting the company.

The company is depending on the tool.

And that is worth fixing before it becomes an incident.

I wrote a longer version of this idea here: The Spreadsheet That Runs Your Company (And Why That Should Worry You)