By Hiran de Silva
There is something about Reg that I don’t think I fully appreciated when I first started developing the Tim and Reg story.
Reg is a disruptor.
Not because he is trying to be disruptive.
He isn’t campaigning against anybody. He isn’t trying to destroy an industry. He isn’t attacking Excel educators, software vendors, IT departments or consultants.
He simply re-engineered a process.
And that is precisely the problem.
Because once people see what Reg has done, some very uncomfortable questions begin to emerge.
First, meet Tim
Tim is not incompetent.
Quite the opposite.
Tim represents millions of enthusiastic Excel users around the world. He enjoys Excel. He wants to become better at it. He follows developments in the product. He watches videos. He attends conferences. He learns Power Query, dynamic arrays, LAMBDA and the latest features.
And what a wonderful time it is to be an Excel user.
The capabilities available to someone sitting at an ordinary Windows computer today are extraordinary.
There is an enormous educational ecosystem serving people like Tim: YouTube channels, conferences, courses, books, MVPs, trainers and influencers.
People such as Leila Gharani, Mynda Treacy, Mark Proctor, Danielle Stein Fairhurst and Wyn Hopkins contribute enormously to that world.
Tim is exactly the sort of person that world is designed to help.
Then Reg walks into the room.
And turns the table over.
Not because Reg knows some amazing new Excel function.
Quite the reverse.
One of the most disruptive things about Reg’s solution is how simple it is.
Reg changes the architecture
Tim has been given a spreadsheet problem.
So naturally, Tim looks for a spreadsheet solution.
Perhaps he has hundreds of workbooks containing information that eventually needs to be combined.
There is a huge amount of educational material showing him increasingly sophisticated ways of combining that information.
And much of it is excellent teaching.
But Reg asks a completely different question:
Why are we distributing the data across hundreds of spreadsheets in the first place?
That one question changes everything.
Reg separates the working documents from the data.
Instead of hundreds of spreadsheets becoming little islands of information, he gives them a common Digital Librarian — a relational database sitting in the middle.
The spreadsheets PUT information into it.
The spreadsheets GET information from it.
Suddenly the architecture becomes hub and spoke.
And now something interesting happens.
Many of the problems that Tim was learning increasingly clever techniques to solve simply disappear.
That is disruptive.
It disrupts Excel education
Consider the enormous popularity of tutorials showing people how to combine information from multiple worksheets, workbooks and files.
Millions of people have watched them.
There is nothing wrong with those techniques. There are perfectly legitimate circumstances in which they are useful.
But Reg introduces another question:
When should we be teaching people to combine distributed data, and when should we be teaching them not to distribute the data in the first place?
That is a very different educational question.
And it is especially interesting because the alternative architecture is not new.
The idea that Excel can consume data held externally predates Power Query and Power Pivot by many years. Excel developers were working with relational databases, DAO and later ADO decades ago. My own Excel work was doing precisely this in the 1990s.
I vividly remember attending an ICAEW presentation by Simon Hurst many years ago in which a PivotTable was being supplied from data in Access. My recollection is that the source wasn’t even simply an Access table; the data had already been assembled through an Access query.
In modern terminology, we would recognise the principle immediately.
The data model existed outside the spreadsheet.
So Reg raises a historical as well as an educational question.
How did something that was already possible become almost invisible to a large part of mainstream Excel education?
It disrupts the Excel replacement industry
Now consider the industry selling alternatives to Excel.
One familiar argument goes something like this:
The problem isn’t necessarily Excel itself. The problem is the people using Excel.
Ordinary spreadsheet users cannot reasonably be expected to engineer robust enterprise systems. A specialist software company employs professional engineers to do precisely that.
At first sight, that sounds entirely reasonable.
I don’t build my own motor car.
Mercedes employs people with vastly more expertise, equipment and experience in motor-car manufacture than I possess.
Why shouldn’t the same logic apply to enterprise software?
Then along comes Reg.
Reg possesses something extremely important.
Domain knowledge and technical capability in the same person.
He understands the business problem because he lives inside it.
But he also understands the technology well enough to re-engineer it.
He doesn’t need to recreate Anaplan, Workday or any other enterprise platform.
He needs to solve this particular business problem.
That distinction is enormous.
And Reg has another advantage.
He has access to remarkably powerful technology already sitting on his desk.
Excel.
ADO.
Access or SQL Server.
The Windows environment.
The organisation’s existing infrastructure.
Suddenly the comparison is no longer:
Spreadsheet versus sophisticated enterprise software.
It becomes:
A locally engineered business solution using existing enterprise technology versus buying another platform.
That is a very different proposition.
It disrupts the definition of Excel
This leads to another argument I have encountered.
Someone will look at Reg’s solution and say:
That’s not Excel.
Really?
Where exactly does Excel end?
If Excel connects to a relational database using technology supplied for precisely that purpose, has Excel somehow stopped being Excel?
This matters because Excel has had client-server capabilities for decades.
The Excel developer literature of the 1990s was already discussing database connectivity. DAO preceded ADO. Excel 97 and subsequent versions opened increasingly powerful routes between spreadsheets and external data.
The spreadsheet could be the client.
The database could be the librarian.
This isn’t something Reg has bolted awkwardly onto Excel.
It is an architecture that Excel has been capable of participating in for decades.
It disrupts the idea of the Citizen Developer
There is another objection.
Perhaps Reg can do this.
But Tim can’t.
This is where I think the argument becomes particularly interesting.
Suppose Tim genuinely cannot build what Reg has built.
What happens when Tim’s manager sees it?
Or Tim’s manager’s manager?
That is what I repeatedly experienced during my own consulting career.
The decisive moment wasn’t necessarily somebody asking:
Can all our spreadsheet users build this?
The question became:
Can we have this?
Once management sees a proof of concept that solves a problem they thought was difficult, the conversation changes.
At Informa, for example, the importance of the proof of concept was precisely that. Instead of debating theoretically what Excel and a relational database might achieve, management could see it working.
That changes the balance of power.
The boardroom doesn’t particularly care whether every Tim in the organisation can build Reg’s solution.
It cares that somebody can.
It disrupts IT
And now things become even more interesting.
Because Reg can sometimes move remarkably quickly.
I experienced this myself at Edexcel.
At one stage my own laptop and software environment was ahead of the corporate desktop environment. I had invested in my own technology and my own knowledge. That gave me the ability to experiment and produce proofs of concept extremely rapidly.
That occasionally created tension.
But consider the situation from management’s point of view.
Someone says:
It can’t be done.
Then Reg does it.
Someone says:
That will require a major project.
Reg produces a proof of concept tomorrow.
Someone says:
We need to procure a system.
Reg demonstrates that much of the required infrastructure already exists.
That doesn’t mean governance suddenly becomes unnecessary.
Quite the opposite.
Once Reg’s prototype becomes important, questions of security, resilience, ownership, documentation, support and governance become essential.
But Reg has changed the starting point of the conversation.
The question is no longer:
Is this possible?
It is:
Reg has demonstrated that it is possible. How do we industrialise it?
That is a much healthier conversation.
It disrupts the software procurement conversation
Paul Barnhurst once responded to one of my scenarios by saying that it wasn’t a job for spreadsheets and would need a proper system.
That raises a fascinating question.
What exactly is a proper system?
Suppose I have:
a relational database,
controlled user access,
centralised data,
audit trails,
business rules,
stored procedures,
security,
a client interface,
and hundreds of users retrieving and updating information through that controlled architecture.
If the client interface happens to be Excel, at what point does this cease to be a proper system?
That is not a rhetorical trick.
It is an architectural question.
And Reg forces us to answer it.
It even disrupts the recruitment model
There is another problem that I experienced personally.
Once management discovers that somebody like Reg exists, where do they find another one?
That isn’t as straightforward as it sounds.
The person may not fit neatly into IT.
He may not be a conventional accountant.
He may not be a conventional Excel developer.
He may not be a database administrator.
He may not be a management consultant.
He sits somewhere between all of them.
Today we might use terms such as Citizen Developer or business technologist.
I prefer another term.
Skunkworks.
Someone close enough to the business to understand the problem, technically curious enough to explore possibilities, and sufficiently empowered to build a working solution before the organisation has finished discussing whether the solution is possible.
That person can be extraordinarily disruptive.
And finally, Reg disrupts Tim
This may be the most important disruption of all.
Tim has spent years becoming better at answering the questions he has been given.
Reg teaches him to question the question.
Tim asks:
How do I consolidate these 400 spreadsheets?
Reg asks:
Why do we have 400 separate stores of data?
Tim asks:
How can I make this Power Query process more efficient?
Reg asks:
Why does this process exist?
Tim asks:
Which Excel feature should I learn next?
Reg asks:
What architecture does the business problem require?
That doesn’t make Tim’s knowledge useless.
Far from it.
Give Tim’s enthusiasm, Excel knowledge and willingness to learn the architectural perspective that Reg possesses and something rather powerful happens.
Tim starts becoming Reg.
The Panama Canal
Perhaps the best analogy came to me while I was dictating these thoughts.
Imagine generations of people being taught increasingly sophisticated ways of sailing around South America.
Better navigation.
Better ships.
Better weather forecasting.
Better route optimisation.
All valuable knowledge.
Then somebody says:
Why don’t we use the Panama Canal?
The surprising part of the story isn’t that the Panama Canal has just been invented.
It has been there all along.
That is the uncomfortable question Reg introduces into the Excel world.
The relational database has been there.
Excel’s ability to communicate with it has been there.
The client-server architecture has been there.
The Digital Librarian has been possible for decades.
Yet a huge educational ecosystem has developed around solving problems created by data remaining inside disconnected working documents. Your South America analogy captures that tension particularly well: the issue is not that the longer route never has a purpose, but that people may never be shown the alternative route at all.
So perhaps Reg’s most disruptive question is also his simplest:
If the Panama Canal was already there, why were we still teaching everybody to sail around South America?
And that is why Reg is dangerous.
Not to Excel.
Not to IT.
Not to software vendors.
Not to Excel educators.
Reg is dangerous to assumptions.
And those assumptions have been sitting comfortably, largely unchallenged, for a very long time.
Add comment