By Hiran de Silva
There is something I have been thinking about for a long time.
It concerns the things we perceive to be difficult when they are not difficult at all.
And, perhaps more importantly, the things we perceive to be easy when they are not.
That distinction matters because the way we perceive a problem influences the solution we choose.
And choosing the wrong solution can be extraordinarily expensive.
Not just in money.
It can cost time, introduce unnecessary complexity, create disruption, and — perhaps most importantly — cause us to miss opportunities that would have been available had we understood the problem properly in the first place.
The lawnmower
Let me start with something obvious.
Suppose you have a large lawn and the grass has grown six inches high.
You want to cut it.
But you have only got a pair of garden shears.
So you start cutting the grass with the shears.
Nobody needs to be an expert to recognise that this is a poor solution.
You could cut the grass with garden shears. There is nothing technically impossible about it.
But if you have a large lawn, the obvious solution is a lawnmower.
Why?
Because we understand the relationship between the task and the tool.
Garden shears are perfectly adequate for cutting a few stems.
A lawnmower is designed to cut a large area of grass efficiently.
The same principle applies to screwdrivers, drills, power tools and countless other things.
We have a mental model that tells us:
If the task has become too large for the tool, find a tool designed for the larger task.
And usually, that is perfectly sensible.
But there is a problem.
That mental model can be exploited.
The car that stopped
Imagine that your car has stopped.
You are sitting in the driver’s seat wondering what has gone wrong.
Another motorist stops to help.
“What’s the problem?”
“The car has stopped.”
He looks at the car and says:
“Ah. You need a new car.”
Conveniently, he owns a car dealership just around the corner.
“Come with me. I’ve got some lovely cars. You need a new one.”
So you buy a £30,000 car.
Nobody has asked why the first car stopped.
Perhaps the engine has failed.
Perhaps the car really is beyond economical repair.
Or perhaps it has simply run out of petrol.
In which case the appropriate solution isn’t a £30,000 replacement.
It is a few litres of fuel.
The crucial question is not:
“What is the appropriate replacement for this thing?”
It is:
“Why has this thing stopped working?”
Look at the dashboard.
The fuel gauge is on empty.
Problem solved.
This is a very simple example, but it illustrates something important.
A solution cannot sensibly be selected until the problem has been properly diagnosed.
And if the person advising you has a vested interest in a particular solution, you should be especially careful.
The Reg Call Handler
This is exactly what happened when I posed my Reg Call Handler challenge on LinkedIn in March 2024.
The original problem was deliberately simple.
There was a spreadsheet that worked.
A call handler could use cascading drop-downs to select information and look up stock levels.
It worked perfectly well.
There was one call handler and one warehouse.
Then the business grew.
Now there were 50 call handlers and 20 warehouses.
The question I asked was:
How do we adapt what already works so that it works at this scale?
The immediate response from several people was effectively:
“You can’t do this with Excel.”
“You need a proper system.”
“Just because you can doesn’t mean you should.”
It sounded very much like the lawnmower argument.
The spreadsheet was being treated as the garden shears.
The business had grown.
Therefore, apparently, it needed the lawnmower.
But nobody had stopped to ask the more important question:
What exactly is causing the scaling problem?
That is the question that changes everything.
The problem wasn’t cascading drop-downs.
The problem was where the cascading drop-downs were getting their data from.
Virtually all the teaching material I could find about cascading drop-downs was based on the same architecture:
The data was in the workbook.
One workbook.
A file.
So if you mentally scale that architecture from one warehouse to 20 warehouses, and from one user to 50 users, of course it looks problematic.
But that isn’t the only architecture.
Move the source data to a central location.
Now every call-handler workbook can obtain its information from that central source.
Suddenly the problem looks completely different.
Twenty warehouses aren’t a problem.
Fifty call handlers aren’t a problem.
Five hundred call handlers aren’t fundamentally a different problem.
The architecture has changed.
The important insight was not a clever Excel formula.
It was correctly identifying the problem.
That is what I mean by solution methodology.
You don’t start by asking:
“Which system should we buy?”
You start by asking:
“What is actually preventing the existing solution from scaling?”
Those are very different questions.
“But surely you shouldn’t be doing payroll in Excel?”
Another example had come up in discussions around GenCFO.
The argument was that companies were still doing payroll in spreadsheets.
The immediate reaction is understandable.
Why would anybody do payroll in Excel when there are specialist payroll systems?
But again, let’s stop and examine what “doing payroll in Excel” actually means.
Suppose I have one employee.
I know their salary.
I know their tax code.
The statutory rules determine the deductions.
There is PAYE.
There is employee National Insurance.
There is employer National Insurance.
There may be other known deductions.
But it’s a simple calculation.
The calculation produces net pay.
Historically, payroll could be calculated using published tax tables, paper, a pencil and a calculator.
You still can. HMRC provides tax tables.
There is nothing inherently mysterious about the calculation.
So if someone creates a spreadsheet containing the employee’s details and formulas implementing the relevant calculations, what exactly has happened?
They have automated the calculation.
Now suppose there are ten employees.
Does the arithmetic suddenly become fundamentally different?
No.
There are ten rows instead of one.
What about 100?
100,000!
Again, the calculation is fundamentally the same.
The number of employees is a volume issue, not necessarily a methodology issue.
Of course, there are legitimate reasons why an organisation might choose specialist payroll software.
Compliance, filing, auditability, workflow, security, integrations, statutory updates and operational controls can all be relevant.
But those are reasons that emerge from understanding the requirements.
Simply saying:
“It works for one person, but what happens when you have 100?”
doesn’t establish that the spreadsheet methodology has failed.
It establishes only that the volume has increased.
And that distinction is important.
Consolidation
The same argument appeared in a GenCFO Academy panel discussion involving Justin Merritt of Planful.
The sponsors of the event.
The proposition was essentially:
Why struggle with consolidation and reconciliation in spreadsheets when there are better tools that will do it?
Again, that sounds persuasive.
Until you examine the actual process.
What exactly is wrong with what is claimed to be wrong?
Imagine a budgeting meeting.
Budget holders, regional managers and country managers are on a Zoom call.
They are agreeing next year’s budgets.
During the meeting, a budget holder says:
“We need another £5,000 in September because of this exhibition.”
The budget is changed.
Everyone sees the updated number in this live Zoom meeting.
Now the regional manager asks:
“What does that do to the consolidated position for India? Or the Asia region?”
This is where the methodology question becomes interesting.
Do we stop the meeting?
Do we export the data?
Do we send it to another system?
Do we wait for a consolidation process?
Do we come back three days later to resume?
Or do we simply retrieve the consolidated numbers from the central data and look at them immediately?
On the same spreadsheet model?
In the model I demonstrate, the answer is the latter.
Select India.
Click Get.
The consolidation appears.
The new number appears.
And if somebody wants to understand where that number came from, select it and the model retrieves the underlying breakdown.
The adjustment that was made seconds earlier is visible in the consolidated result.
That is not a theoretical claim.
It is a demonstration of a working methodology in a live meeting.
And this is why I object to the blanket statement that “you shouldn’t do consolidation in Excel because there are better systems.”
Better for what?
Better in what way?
That is the question.
If the requirement is an enormous enterprise consolidation process involving particular controls, workflows, regulatory requirements and thousands of complex processes, there may be compelling reasons to use a specialist application. If a batch process at some later time is ok.
But if the requirement is:
“During a live budgeting meeting, can we immediately see the effect of an adjustment on the regional consolidation?”
then we should examine the actual mechanics of that requirement before deciding that the spreadsheet is inadequate.
Here, we see that it is simply adding up the numbers for the operating units that comprise India, or Asia. Adding up numbers is what a spradsheet does.
Otherwise we are back to the motorist.
The car has stopped.
Buy another car.
Why?
We haven’t checked the fuel gauge.
We haven’t checked why the car has stopped.
The most interesting example happened in 1982
This brings me to a story from the beginning of my career.
Every time I look out of the window of my flat at Docklands, I think about it.
Today there are skyscrapers everywhere.
But when I first encountered Docklands, it was a building site.
The company I worked for was the first businesses to build a new office block and move there.
This was in the early 1980s.
There wer government subsidies.
I had joined a publishing company producing magazines for the music industry.
I was 29.
The owner, Richard Desmond, was only a year older than me at 30. (He is now a billionaire in the UK)
I joined as an accountant and, through circumstances I won’t go into here, found myself becoming head of finance on my second day!
There was a problem for months.
Richard wanted management accounts.
He wanted to know where the money was coming from, where it was going, and which products were profitable.
But he wasn’t getting them.
The explanation from my predescessors was that the company didn’t have the systems required to produce the reports.
The existing accounting system, he was told, wasn’t capable of producing the information.
The solution being discussed was a new system.
New software.
New expenditure.
New implementation.
New disruption.
The familiar answer.
The existing system isn’t good enough. We need a new one. They had said.
But I had access to something that apparently nobody else had been able to find.
The manual.
I looked at the existing system.
How the data was structured.
I worked out how the reports were configured.
And within about two months I produced the management information Richard had been asking for.
Not eventually.
Not after buying a new system.
Not after a major implementation.
From the system the company already owned.
I even produced it as a proper bound management report.
Richard was surprised.
He asked me how I had done it.
I explained that the information was already in the system.
The system wasn’t incapable of producing it.
It simply hadn’t been configured and used in the way required to produce the information he wanted.
And that saved the company a substantial amount of capital expenditure and, just as importantly, the disruption associated with replacing a system that wasn’t actually the problem.
It also gave Richard something else.
Information.
Once he could see the profitability of the different parts of the business, he could make decisions that had previously been guesswork.
One of those decisions contributed to the move towards Docklands.
So when I look at Docklands today, I don’t just see the skyscrapers.
I remember a management accounting system that apparently couldn’t produce management accounts.
Until somebody asked a different question.
So what is actually going on?
This is the thread connecting all these examples.
The lawn.
The car.
The Reg Call Handler.
Payroll.
Consolidation.
My first management accounting system.
They all involve the same potential mistake.
We see a problem.
We recognise a familiar pattern.
And we immediately reach for the familiar solution.
The grass is difficult to cut.
Get a lawnmower.
The car has stopped.
Buy another car.
The spreadsheet has to scale.
Buy a system.
Payroll has grown.
Buy a payroll system.
We need consolidation.
Buy a consolidation system.
The accounting system isn’t producing the reports.
Replace the accounting system.
But there is a missing step.
Diagnose.
Before deciding that something is inadequate, establish what is actually inadequate.
Before deciding that a spreadsheet cannot scale, identify what prevents it from scaling.
Before deciding that payroll cannot be done in a spreadsheet, identify which part of the payroll process supposedly fails at scale.
Before deciding that consolidation requires another system, identify the actual consolidation requirement.
Before replacing an accounting system, find out whether the system itself is incapable of doing the job.
This isn’t an argument for Excel.
And it isn’t an argument against specialist systems.
It is an argument for proper problem definition.
The vested-interest problem
There is another dimension that we shouldn’t ignore.
The person giving the advice may benefit from the solution they are recommending.
The car dealer benefits when you buy a car.
The software vendor benefits when you buy software.
A consultancy benefits when a project is commissioned.
That doesn’t mean their advice is wrong.
It doesn’t even mean they are acting improperly.
But it does mean that their proposed solution should not automatically be confused with an objective diagnosis of the problem.
If the person selling you the lawnmower tells you that garden shears are inadequate, they may be absolutely right.
But before handing over the money, you might still want somebody to look at the lawn.
This is why I created Mission Impossible
This is also the thinking behind my Mission Impossible series.
I deliberately start with something that people will look at and say:
“You can’t do that with Excel.”
That is the challenge.
Not because Excel is magically the answer to everything.
But because I want to expose the mental model that produces the immediate conclusion that it isn’t.
Then I demonstrate the solution.
And often the interesting part isn’t the technique.
It is the moment when you realise that the thing you thought was impossible was only impossible under the mental model you had.
Change the mental model.
The problem changes.
The same thing happened with the Reg Call Handler.
The perceived problem was:
“How can Excel handle 50 users and 20 warehouses?”
The actual problem was:
“Why are 50 users expected to obtain their information from the same workbook?”
Once you ask the second question, the answer becomes much more obvious.
That is the penny-drop moment.
The egg
There is a story attributed to Christopher Columbus.
I don’t know whether it is true, and I’m not particularly interested in whether it is.
The story says that Columbus challenged his critics to stand an egg upright.
They tried.
It wouldn’t stand.
Then Columbus demonstrated the answer.
He tapped the end of the egg against the table, flattening it slightly.
Now it stood upright.
The solution was obvious once somebody had demonstrated it.
But it wasn’t obvious before.
And that is the point.
Sometimes the difficulty isn’t in doing the thing.
It is in seeing the thing differently.
That is what I am trying to explore with Tim and Reg.
Not whether Excel is better than a specialist system.
Not whether a lawnmower is better than garden shears.
Not whether one technology is universally superior to another.
The real question is much more fundamental:
How did we decide what the problem was in the first place?
Because if you get that wrong, you can spend an enormous amount of money solving the wrong problem.
For example, because somebody told you (and you believed) that you can’t consolidate, bottom-up, with spreadsheets (Colin Wall, Anaplan salesman on LinkedIn July 2023)
And if you get it right, you may discover that the supposedly impossible solution was sitting there all along.
And it just may be that it is superior to the expensive solution being suggested, like the new car.
You just hadn’t looked at the problem in the right way.
Add comment