When Your Business Can No Longer Explain Itself

Some of the most expensive operational problems begin long before anyone realizes they have a technology problem.

A few years ago, I met the owner of a group of quarries through a mutual friend. It wasn't a sales meeting and we weren't discussing technology. We were simply talking about business when he mentioned something that immediately caught my attention. He owned several quarries, they already had custom software, and yet he still didn't trust what his operation was telling him.

At first, I assumed I knew what the problem was. The software had probably been built poorly, key functionality was missing, and management lacked the visibility it needed to run the business confidently. Those are familiar situations in our industry, and they often lead companies to look for a new technology partner.

In this case, that explanation wasn't wrong.

It just wasn't complete.

The company already had a custom-built application, but the developer who had created it disappeared before finishing the project. Some workflows had never been completed, and one of the calculation routines responsible for determining invoice amounts produced inconsistent results. On paper, it looked like exactly the kind of project a software company is hired to rescue.

The more time we spent inside the operation, however, the less interested I became in the software itself. What began to fascinate me was not the application we were replacing, but the way the business actually functioned from one decision to the next.

One morning I spent several hours inside the dispatch cabin where every truck stopped before entering the quarry. Drivers arrived with delivery slips, some paid in cash, and the operator recorded those payments in an Excel spreadsheet before moving on to the next customer. The process looked efficient. There was no visible chaos, no obvious bottleneck, and no reason to think the operation wasn't under control.

Then I asked what I thought was a simple question.

"How does the billing team know whether the customer you've just written down is a new customer or someone who already exists in the system under a different name?"

The answer wasn't in the spreadsheet.

It depended on the people.

Someone recognized the name. Someone remembered the customer's history. Someone knew that two slightly different names referred to the same company. The spreadsheet wasn't incorrect; it simply assumed that the people using it would always provide the context it couldn't capture.

Later that same day I noticed something else that seemed equally ordinary. When trucks reached the loading area, the machine operator frequently asked the driver which material should be loaded because the delivery slip didn't always identify it. The driver answered, the operator trusted the answer, and the truck was loaded.

Nobody questioned the process because, for years, it had worked.

The operators knew their customers. The drivers understood what they had purchased. The commercial team remembered pricing agreements and special situations. Experience compensated for what the process itself never made explicit.

That observation stayed with me long after the project ended because it forced me to reconsider something I had believed for years.

I had always assumed that companies looked for new software because their existing software had reached its limits. What I began to see instead was that software often becomes the topic of the conversation only after something much more fundamental has already happened. Somewhere along the way, the organization has stopped keeping its most important operational knowledge inside the business itself. That knowledge gradually migrates into conversations, habits, spreadsheets, paper forms, and, above all, into the memories of the people who have been there the longest.

Once I started looking at projects through that lens, I realized the quarry wasn't an exception.

I found the same pattern in healthcare organizations where experienced physicians instinctively knew how certain clinical situations should be documented even though the process itself had never been clearly defined. I found it in startups where only the founders could explain why two customers paid different prices for what appeared to be the same service. I found it in companies running sophisticated ERP platforms where finance and operations still spent hours trying to understand why two reports produced different numbers for the same customer.

The industry changed. The software changed. The pattern remained remarkably consistent.

What those organizations had in common wasn't outdated technology. It was that critical business knowledge existed primarily inside experienced people rather than inside the business itself. As long as those people remained in the organization, everything appeared to work. They remembered exceptions, corrected mistakes before anyone else noticed them, and filled in the gaps that systems and processes left behind. Ironically, the stronger and more experienced the team became, the longer the underlying weakness remained invisible.

That realization also changed the way I think about spreadsheets.

For years, spreadsheets have been treated as the enemy of digital transformation. I no longer see them that way. In my experience, spreadsheets rarely create operational complexity. They appear because operational complexity already exists and the organization needs somewhere to compensate for it. The same is true of paper forms, WhatsApp messages, handwritten notes, and countless other workarounds that companies often try to eliminate. Those things are rarely the disease. More often, they are evidence that the operating model has evolved faster than the organization's ability to describe it.

As a result, the questions I ask at the beginning of a project today are very different from the ones I asked ten years ago. I still care about architecture, integrations, and artificial intelligence, but I no longer begin there. Instead, I want to understand how the business decides what is true when two reports disagree, how responsibility moves from one department to another, which operational exceptions are intentional, and which continue to exist simply because nobody has challenged them in years.

Those conversations consistently reveal more than any technical assessment.

Over time, I've reached a conclusion that I didn't expect when I first started building software.

Technology is exceptionally good at preserving understanding, but it is remarkably poor at creating it. If an organization has never developed a shared understanding of how pricing works, how responsibilities change hands, or how exceptions should be handled, software cannot solve those disagreements. It can automate them. It can standardize them. It can even make them less visible for a while. But it cannot create understanding where none exists.

Today, when an executive tells me that their company needs a new system, I rarely think about technology first.

Instead, I find myself wondering whether the business has quietly reached the point where it can no longer explain itself.

Because, in my experience, organizations rarely lose control when their software becomes outdated.

They lose control when the knowledge required to operate the business no longer belongs to the business itself.