There Is Always a Spreadsheet
In four decades of building and buying systems that move money, I have never once found a fully automated process. Not one. Somewhere in every system that is described as automated, there is a person with a spreadsheet, and the spreadsheet is what actually keeps it running.
Sometimes it is a reconciliation that the code gets right ninety-eight times out of a hundred, and an operations manager who clears the other two every morning before anyone notices. Sometimes it is a list of customer accounts that need special handling, kept in a file nobody else knows exists, because the rules engine cannot express the exception and the person who understands the exception got tired of explaining it. Sometimes it is the payout schedule for a partner whose contract was negotiated by someone who has since left, living entirely in a tab named "DO NOT DELETE."
The spreadsheet is never in the architecture diagram. That is precisely why it matters.
Why it is always there
The spreadsheet exists because the system was designed for the cases the designers could imagine, and the world produced the rest. A bank changed a file format. A regulator added a field. A large customer needed something no one else needed, and the fastest honest answer was for a human to handle it by hand while the engineers worked on things with more users. Each of those is a good decision. Together, they accumulate into a shadow process that carries the real logic of the business, maintained by one or two people who understand it, and invisible to the people who fund and plan.
Early in my career I thought of this as a failure. Now I think of it as the most accurate documentation a company has. The code says what the system was built to do. The spreadsheet says what the business actually does, including every exception that reality forced on it. If you want to know how a company works, do not read the design docs. Find the spreadsheet.
Where it goes wrong
The spreadsheet is fine at one scale and catastrophic at another, and the transition is abrupt.
At a hundred customers, a human clearing two exceptions a morning is a rounding error. At ten thousand customers, the same two percent is two hundred exceptions a morning, and the person clearing them is now the bottleneck on the whole business, and nobody planned for that because nobody knew the person was there. Growth does not break the automated part. It breaks the human part that was quietly doing the automated part's job, and it breaks it suddenly, usually the week after the board deck that celebrated the growth. The dashboard will not warn you, because the dashboard measures the automated part, and the automated part is fine.
The other failure is departure. The person who owns the spreadsheet leaves, or goes on vacation at the wrong time, and the company discovers that a piece of its core process was a single human being's habits. I have watched a payments operation stall for days because one person's laptop died and the recovery took a weekend. Nobody had done anything wrong. The process had simply never been written down anywhere that could be read by someone else.
What to do about it
The instinct of every engineer, mine included, is to find the spreadsheet and eliminate it. Automate the exception. Fold the logic into the system. That is often the right long-term answer, and it is almost always the wrong first move, because you do not yet understand what the spreadsheet is doing, and the person who does is the one you are about to make redundant.
The first move is to treat the spreadsheet as the spec. Sit with the person who maintains it and have them walk you through every row, every color code, every column that means something only to them. Write down not just what they do but why, and what happens if they do not. You will learn more about your business in that hour than in a quarter of dashboards, and you will usually find that half the exceptions are a single rule nobody had stated, and the other half are genuine judgment calls that no rule will ever capture.
Automate the first half. Keep the second half human, on purpose, and staff it so that it is no longer one person. And whatever you do, keep the person. The one who kept the spreadsheet is the one who noticed what the system missed, and that ability to notice is the scarcest thing in your company. It does not scale by being replaced. It scales by being taught.
One practical marker: if a process has a name that only two people use, or a color code nobody can explain in a meeting, you have found one. Write it on the whiteboard next to the architecture diagram, in the same size type, and leave it there until the diagram tells the truth.
The founder's version
If you are running the company, the uncomfortable truth is that the spreadsheets are a map of every decision you deferred. Each one marks a place where the real requirement was more complicated than the plan, and somebody absorbed the difference so that the plan could proceed. That is not a criticism. It is how anything gets built. But the debt is real, and it compounds, and it comes due at the moment of growth when you can least afford to pay it.
So before the next raise, before the next big customer, before the next quarter's plan, go find them. Ask every team lead a single question: what do you keep in a spreadsheet that the system should know? Then listen for the pause before they answer. That pause is where your company actually lives.