A successful entrepreneur once compared creating a company to having a child.
Their point was that once you bring something into existence, you become responsible for it. You have to feed it, nurse it, and continue taking care of it—even when what you created begins demanding far more from you than you anticipated.
I think the same thing happens with Excel workbooks.
Nobody usually sets out to build a mission-critical system.
You start with a problem.
Two reports need to be compared.
A client wants a summary.
Campaign performance needs to be reconciled.
Several fields need to be standardized.
So you create a workbook.
Then you add a lookup.
Then another tab.
Then another data source.
Then a mapping table.
Then a dashboard.
Then someone asks for an exception.
Then another exception.
Before long, the workbook you created to make your job easier has become something you are responsible for keeping alive.
And workbooks can die in a surprising number of ways.
Sometimes the formulas break.
Sometimes the formulas work perfectly against the wrong data.
Sometimes the source file changes.
Sometimes someone inserts a column.
Sometimes a lookup silently stops matching.
Sometimes somebody pastes over a formula.
Sometimes two parts of the workbook develop different versions of the same business rule.
Sometimes the workbook becomes so slow that users begin creating shortcuts around it.
And sometimes nothing technically breaks at all.
The workbook simply becomes so complicated that nobody can confidently explain how the number appearing on the final report got there.
That may be the most dangerous death of all.
Because the workbook is still open.
It is still calculating.
People are still using it.
They just don't completely trust it anymore.
A Workbook Can Die More Than One Death
We tend to talk about Excel failures as if they are formula failures.
Something looks wrong.
So we inspect the formula.
But an operational workbook is rarely just a collection of formulas.
It is a system.
It has sources.
It has inputs.
It has references.
It has transformations.
It has mappings.
It has business rules.
It has calculations.
It has outputs.
It has users.
Each of those components creates another potential point of failure.
That is why the greatest advantage of approaching Excel like a system isn't simply making a workbook cleaner.
It makes the workbook diagnosable.
When something goes wrong, the question becomes:
Where did it go wrong?
That sounds simple.
Inside many workbooks, it is surprisingly difficult to answer.
Death by Source
Everything starts somewhere.
Maybe the workbook receives data from a DSP.
Maybe Meta.
Maybe LinkedIn.
Maybe Salesforce.
Maybe an accounting system.
Maybe someone emails you a CSV every Tuesday.
Then one week something changes.
Campaign Name becomes Campaign.
A column disappears.
A new field is inserted.
Dates arrive in a different format.
Spend that previously arrived as a number arrives as text.
Your workbook still opens.
Your formulas are still there.
But the thing those formulas were designed to consume has changed.
Excel did not fail.
The source contract failed.
That is why I like to treat source data as its own layer.
Bring the data in.
Preserve it.
Inspect it.
Validate it.
Know what arrived before transforming it into something else.
If my system expects 25 fields and receives 24, I want to know that before a dashboard tells me performance suddenly declined by 40%.
Death by Reference
Then there are references.
One of Excel's oldest killers.
Consider a formula such as:
=VLOOKUP(A2,Raw!A:Q,14,FALSE)
The formula assumes the information you need lives in column 14.
That is not really a data rule.
It is a positional assumption.
Someone inserts a column.
Something moves.
Now the formula may break.
Or it may shift.
Or, much worse, it may continue working while returning a perfectly legitimate value from the wrong field.
That last outcome is considerably more dangerous.
A #REF! tells you something is wrong.
A believable number doesn't.
This is why I prefer workbooks that think in field names instead of coordinates.
The system should not care that Spend happens to be column N.
It should care that the field is named Spend.
That can mean structured references.
It can mean Excel Tables.
It can mean MATCH or XMATCH.
It can mean CHOOSECOLS.
It can mean Power Query.
The implementation can change.
The principle doesn't.
Reference what the data is, not merely where it happens to be.
Death by Multiple Sources of Truth
Now imagine your campaign name appears in the source export.
There is another version in a mapping sheet.
Another version exists in a manually maintained reporting table.
Another version appears in a dashboard.
Someone corrects one of them.
Which one is right?
If the same information is independently maintained in five places, you do not have five backups.
You have five opportunities for disagreement.
A system needs authoritative sources.
One value owns the truth.
Everything downstream references it.
If a campaign classification changes, I should not need to update seven worksheets.
I should update one source.
Everything dependent on that source should inherit the change.
One source. Many references.
Death by Copying Instead of Mirroring
This does not mean information can only appear once.
Sometimes the same information needs to appear in many places.
The important distinction is between copying and mirroring.
Copied information becomes independent.
Mirrored information remains connected.
Suppose your source contains:
Campaign ID
Advertiser
Campaign Name
Channel
Impressions
Clicks
Spend
You may need those fields elsewhere in the workbook.
But manually copying them creates another version of the data.
Now the source and destination can disagree.
Mirroring is different.
The downstream representation derives from the authoritative source.
Change the source.
The dependent representation changes.
That dramatically reduces the number of places where a workbook can develop conflicting versions of reality.
Death by Unnormalized Data
Sometimes none of your sources is actually wrong.
They simply speak different languages.
One source gives you:
Campaign
Another:
Campaign name
Another:
Campaign Name
One platform gives you:
Spend
Another:
Amount Spent
Another:
Cost
One calls a tactic:
Online Video
Another:
Video
Another:
OLV
None of them is necessarily incorrect.
But your downstream reporting shouldn't need to understand every dialect spoken upstream.
That is where normalization enters the architecture.
Raw data remains raw.
But between ingestion and reporting, you establish a common structure.
Perhaps your system standard becomes:
DatePlatformCampaignChannelImpressionsClicksSpend
Now your reporting logic doesn't need to know what Meta happens to call spend.
It only needs to understand what Spend means inside your system.
Normalization is not cosmetic.
It reduces the number of assumptions downstream calculations have to make.
And every assumption you remove is one fewer potential cause of death.
Death by Transformation
Sometimes the source is correct.
The references are correct.
The normalized fields are correct.
And the output is still wrong.
Now we have moved further downstream.
Perhaps a campaign identifier was extracted incorrectly.
Maybe rows disappeared during filtering.
Maybe files were appended incorrectly.
Maybe a date was converted incorrectly.
Maybe a channel was grouped incorrectly.
Maybe one transformation unexpectedly duplicated records.
Something happened between ingestion and output.
Traditional spreadsheet design can make this difficult to diagnose because multiple operations often happen simultaneously.
A single formula may:
clean text,
perform a lookup,
apply a classification rule,
handle an exception,
calculate a value,
and suppress an error.
When the final result is wrong, which operation failed?
That is why I want transformations to be observable.
One stage receives the data.
Another normalizes it.
Another transforms it.
Another applies rules.
Another calculates.
Another outputs.
The objective isn't necessarily to minimize the number of steps.
The objective is to make each step understandable.
Death by Business Rule
This one is particularly interesting because Excel may be doing exactly what you told it to do.
The problem is that what you told it to do is no longer correct.
Suppose the original rule was:
If a placement contains CTV, classify it as Connected TV.
Then your reporting requirements change.
Certain streaming placements should now be considered Online Video.
The original formula isn't broken.
The business rule is obsolete.
If that rule exists independently inside twenty formulas, you now have twenty places to change it.
Miss one and the workbook starts producing two definitions of the same thing.
This is why business rules should be centralized whenever possible.
Instead of repeatedly embedding classifications inside formulas, maintain an authoritative mapping.
For example:
CTV → Connected TV
Connected Television → Connected TV
Streaming TV → Connected TV
Change the mapping once.
Every dependent process inherits the change.
Once again:
One source. Many references.
Death by Silent Error
Excel's obvious errors are often the least frightening.
#N/A
#VALUE!
#REF!
#DIV/0!
Those errors are useful.
Excel is telling you something failed.
The more dangerous errors return perfectly reasonable-looking results.
A lookup finds the wrong record.
A join duplicates Spend.
Twenty records disappear.
A date quietly becomes text.
A numeric field contains several text values.
A reference moves to the wrong column.
No error appears.
The dashboard simply becomes wrong.
That is why error handling should mean more than putting IFERROR() around everything.
Consider:
=IFERROR(XLOOKUP(...),"")
Now you see a blank.
But what does the blank mean?
Was the underlying field legitimately blank?
Or did the lookup fail?
Those are two completely different conditions.
A system should make failures observable.
That might mean validation fields such as:
Match Found?
Required Fields Present?
Valid Date?
Mapped Channel?
Duplicate ID?
Spend Numeric?
It might also mean producing a dedicated exception table containing only records that failed validation.
Instead of searching 50,000 rows for the problem, the system can tell you:
147 records failed Channel Mapping.
Now Excel isn't merely calculating.
It is helping diagnose itself.
Death by Manual Intervention
Then there is the human.
Copy this.
Paste that.
Drag this formula down.
But not that far.
Delete these rows.
Rename this tab.
Change this date.
Refresh this pivot.
Paste values into these columns.
Never touch the yellow cells.
Every manual intervention is another opportunity for the process to diverge.
The problem isn't that humans make mistakes.
The problem is designing a process that requires humans to behave perfectly.
If something can be derived, derive it.
If something can be referenced, reference it.
If something can be validated, validate it.
If the reporting period can be calculated from the source data, perhaps the user shouldn't enter it manually.
If a standardized campaign name can be derived from a mapping table, don't ask someone to type it again.
Good system design removes decisions the user should not need to make.
Death by Output
Sometimes everything upstream is right.
And the final report is wrong.
Maybe a PivotTable didn't refresh.
Maybe a dashboard is pointing to an incomplete range.
Maybe a filter excludes one platform.
Maybe a chart references the wrong field.
Maybe two reports use different definitions of the same KPI.
A layered workbook makes this much easier to troubleshoot.
Ask:
Is the source correct?
Yes.
Did validation pass?
Yes.
Is the normalized data correct?
Yes.
Are the business rules correct?
Yes.
Are the calculations correct?
Yes.
Then you probably don't need to tear apart ingestion.
The problem lives in the output layer.
That is what architecture gives you.
Not immunity from failure.
Isolation of failure.
Death by Performance
Then there are workbooks that technically work.
Eventually.
Thirty seconds to calculate.
A minute to refresh.
Several minutes to open.
Entire columns referenced unnecessarily.
Thousands of repeated lookups.
Large datasets copied across multiple sheets.
The same transformation calculated several different ways.
Volatile formulas recalculating constantly.
Eventually the users adapt.
They switch calculation to manual.
They stop refreshing.
They paste values.
They make smaller copies.
They split one workbook into several workbooks.
And those workarounds create new failure points.
Performance isn't merely a matter of convenience.
A workbook that is painful to operate changes user behavior.
User behavior then becomes part of the architecture whether you planned for it or not.
Death by Inheritance
Then the creator leaves.
This may be the ultimate test.
Someone else opens the workbook.
Can that person determine:
Where does data enter?
Which tables contain untouched source data?
What is mirrored?
What gets normalized?
Where do transformations happen?
Where do business rules live?
Which tables are authoritative?
Where do errors appear?
What feeds the final output?
If not, the workbook didn't really have an architecture.
It had an author.
Those are not the same thing.
Build Excel Like a System
This is why I increasingly approach Excel less like an infinite grid and more like a small software system.
Not because every workbook needs to become complicated.
The opposite.
Systems thinking helps contain complexity.
A workbook might conceptually follow a structure like:
SOURCE
↓
RAW / MIRROR
↓
VALIDATE
↓
NORMALIZE
↓
TRANSFORM
↓
BUSINESS RULES
↓
CALCULATE
↓
OUTPUT
↓
EXCEPTIONS
Each layer has a responsibility.
That means each layer also has a limited universe of things that can go wrong.
If a vendor changes an export, inspect Source.
If headers disappear, inspect Validation.
If DSP, Meta, and LinkedIn terminology no longer aligns, inspect Normalization.
If classifications are wrong, inspect Business Rules.
If the normalized data is right but a chart is wrong, inspect Output.
Contrast that with a workbook where ingestion, cleanup, mappings, calculations, exceptions, formatting, and reporting happen across twenty interconnected sheets.
Something is wrong.
Where?
Good luck.
The Goal Isn't to Prevent Every Death
Eventually, something will break.
A platform will change its export.
A new business requirement will appear.
Someone will rename something.
A new data source will arrive.
A classification will change.
A user will paste something into the wrong place.
That is normal.
Building Excel like a system doesn't mean building a workbook incapable of failure.
It means building one capable of telling you how it failed.
There is a tremendous difference between:
“The workbook is broken.”
and:
“The source schema changed. Campaign Name is missing, so 1,842 records failed validation before normalization.”
The second problem is actionable.
You know where to look.
You know what depends on it.
You know which parts of the system did not fail.
That is what architecture gives you.
And it brings me back to the original comparison.
Once you create something useful, you become responsible for keeping it alive.
A workbook is no different.
But there should eventually come a point where taking care of it stops meaning constantly hovering over it.
Feeding it files.
Correcting its classifications.
Remembering which columns can't move.
Remembering which cells can't be touched.
Remembering which errors should be ignored.
A mature workbook should have structure.
Rules.
Boundaries.
Validation.
Error handling.
Authoritative sources.
And a way to tell you when those expectations have been violated.
Because the real measure of a well-designed workbook isn't whether nothing ever goes wrong.
It is whether, when something does go wrong, you can figure out what is killing it.
Pull Quote
The goal of building Excel like a system isn't to create a workbook that can never fail. The goal is to create one that can tell you how it failed.
Secondary Pull Quote
If the same information exists independently in five places, you don't have five backups. You have five opportunities for disagreement.