The Process Can Be Taught. The Judgement Takes Years.

The judgement behind the process.

People often talk about operational experience as though it were instinct. They will say someone has a good eye for stock ordering, or that they simply know when something does not look right. Spend enough time around experienced managers and you will hear phrases such as you will understand after a while or it is just a gut feeling. Those explanations are not wrong, but they stop short of explaining the underlying reason that judgement cannot simply be transferred from one person to another. They describe what experienced people appear to do, but not why they are able to do it.

That question became particularly interesting to me when I was training my successor to take over stock ordering. On the surface, it seemed like a straightforward responsibility to hand over. The mechanics were easy enough to explain: where to find the reports, how to review historical sales, how to account for deliveries already on the way and how to submit an order. Like most operational processes, those mechanics can be taught with enough repetition. If someone is engaged, capable and willing to learn, they will usually become comfortable with that part of the role surprisingly quickly.

What proved much harder to teach was not the process itself. It was the thinking behind it. I was not trying to show someone how to complete an order form. I wanted to teach them how to think about an order: how to look beyond the figures in front of them, question whether those figures genuinely represented what the business would need over the coming week and challenge the obvious answer when the surrounding circumstances suggested something different.

As I tried to explain my reasoning, I realised how little of it actually came from the ordering system itself. Of course, the figures mattered. Historical sales, current stock levels and outstanding deliveries formed the foundation of every decision. Ignoring them would have been irresponsible. But over time, they had become only the starting point. Around those numbers sat a much broader set of considerations that rarely appeared anywhere on the screen. The weather might change demand dramatically over a weekend. A local event could bring thousands of additional customers into the area. A supplier who had become unreliable over the previous month might influence how aggressively I ordered certain products. Sometimes there were subtle changes in customer behaviour that I had noticed on the floor long before they became obvious in a weekly report.

None of those things were hidden. They simply existed outside the system.

The more experience I gained, the less I relied on the reports themselves. Eventually, I stopped using them almost entirely—not because the figures were necessarily wrong, but because I had become more closely attuned to my own operation than the reports could ever be. Historical data could describe what had already happened. My job was to decide what was likely to happen next.

By that point, I had developed what operators often call a gut feeling, although I think that phrase oversimplifies what is really happening. Before placing an order, I would review the bookings for the coming week, note any pre-orders, consider the weather forecast, think about local events and reflect on how recent services had actually felt. Over time, I had also developed my own internal par levels: an instinctive understanding of how much of each product we really needed to hold, which lines could comfortably run lower and which shortages would immediately create operational problems.

That internal model was constantly evolving. A particularly busy weekend might permanently change how I viewed the required stock level for a product. A series of inconsistent supplier deliveries might lead me to increase the buffer I kept. A gradual shift in customer preferences would often become obvious during service before it ever became obvious in the data. By combining what I could see inside the operation with information about what was coming next, I could often make a better decision than I could by simply extrapolating from historical sales.

The reports were not inaccurate. They were retrospective. The decision I was making was predictive.

A report could tell me exactly what we had sold last Friday. It could not tell me whether last Friday was actually the right comparison to make. It could not know that the coming weekend would be the first genuinely warm spell of the year, that a local festival was expected to bring thousands of additional people into the area, or that one of our suppliers had become increasingly unreliable over recent weeks. It could not account for the countless observations I had accumulated simply by being immersed in the operation every day. The report was not wrong. It was simply incomplete.

Looking back, I realised I had stopped reading reports at face value a long time ago. Without consciously thinking about it, every report was being filtered through years of accumulated experience. I found myself asking questions that never appeared anywhere on the screen. Was this week actually comparable to last week? Had something changed since those figures were recorded? Was anything happening that the numbers could not possibly know about? Eventually, those questions stopped feeling like questions at all. They became part of how I naturally thought.

From the outside, that probably looked like instinct. Looking back, I do not think it was instinct at all. It was experience compressed into rapid pattern recognition. Every busy bank holiday, every supplier issue, every unexpectedly quiet Tuesday, every stock shortage, every over-order and every mistake had quietly changed how I interpreted the next set of figures. Individually, none of those experiences seemed particularly significant. Collectively, they formed a mental model of the operation that no report could fully capture.

That was the point at which I realised I was not really trying to teach somebody how to order stock. I was trying to transfer years of accumulated judgement. The process itself could be explained in an afternoon. The reasoning behind the process had been built over hundreds of services, countless supplier conversations and years of watching situations unfold in ways that no spreadsheet could have predicted. I could explain why I had reached a particular decision on a particular day, but I could not simply hand over every observation that had shaped the way I thought.

The process can be taught. The judgement takes years.

For a long time, I assumed that was simply the nature of operational experience. Some things could be documented and standardised. Other things had to be earned through repetition. Every experienced operator had travelled the same path, gradually refining their judgement until it became difficult to separate conscious reasoning from what appeared to be instinct.

Then I started building software. Almost without realising it, I found myself asking a completely different question: not how the process could be automated, but how much of that judgement software could help preserve. Not because software can replace experienced operators—I do not believe it can—but because there is an enormous difference between asking someone to make a decision armed with nothing more than a spreadsheet of numbers and asking them to make that same decision with the context an experienced operator would naturally consider.

The goal is not to remove people from the decision-making process. It is to ensure they do not begin the decision empty-handed.

Why operational software stops too soon.

One thing became increasingly obvious to me after that experience. The problem was not that we lacked data. It was that we lacked context. Modern businesses collect extraordinary amounts of information. Every sale is recorded. Every order is stored. Every customer interaction leaves a trail. Dashboards are filled with graphs, percentages and reports that update in real time. Compared with even twenty years ago, we know more about our businesses than ever before.

Yet despite access to all that information, organisations continue to depend heavily on experienced people to interpret it. That is not a coincidence. Data and judgement solve different problems. Data tells us what happened. Judgement decides what to do next. Those ideas are often treated as though they are interchangeable, but they are not.

Imagine opening a sales report and seeing that a particular product sold one hundred units last week. That is useful information. But is one hundred good? Should you order another hundred? Should you order one hundred and fifty? Should you reduce your stock holding because demand is slowing? The report cannot answer those questions, not because it is poorly designed, but because those questions are not about history. They are about the future. The report has already completed its job. The decision still belongs to the operator.

This is where many operational systems quietly reach the limits of what they were designed to do. Most software is exceptional at recording events. It knows what was sold, when it was sold, who purchased it and how much they paid. It can retrieve invoices from three years ago in seconds. It can calculate totals, produce reports and surface trends across millions of records with remarkable accuracy. But once those facts have been recorded, the software often stops. The remaining work—the interpretation, the reasoning and ultimately the decision—is handed back to the person sitting behind the screen.

That is where experienced operators become invaluable. When an experienced manager opens a dashboard, they do not just see numbers. They see stories. They remember the supplier who missed three deliveries last month, the unusually warm bank holiday when sales doubled, the product that always appears to underperform until payday arrives and the local event that completely changed trading patterns the previous year. None of that information exists in isolation. It is connected.

Years of experience gradually teach operators how to build those connections without consciously realising they are doing it. They stop processing individual facts and begin recognising patterns instead. Ironically, that is exactly the point at which their expertise becomes the hardest thing to transfer. You can export a spreadsheet. You cannot export twenty years of pattern recognition.

When an experienced employee leaves a business, they do not just take knowledge with them. They take context. The procedures remain. The reports remain. The software remains. But the invisible reasoning that sat between those things disappears overnight.

Businesses often describe this as losing good people, but I do not think that is the whole story. What they have actually lost is an internal model of how their operation behaves: someone who instinctively knows which reports matter, which figures deserve scepticism, which suppliers require contingency plans and which trends are genuine rather than temporary. That knowledge rarely exists anywhere except inside somebody's head.

The consequence is familiar. A highly capable employee leaves. Their replacement follows exactly the same documented process. They generate the same reports and complete the same forms, yet the quality of the decisions declines. Not because the replacement lacks intelligence, and not because the process is wrong, but because the process was never where the expertise lived. The expertise lived in the judgement.

That realisation fundamentally changed how I started thinking about software. Instead of asking how software could automate another process, I began asking what would happen if it could preserve some of that operational context before it disappeared. Not by pretending to replace experienced people, and not by making every decision automatically, but by making years of accumulated operational knowledge visible to the next person before they needed to make the same decision.

Perhaps the greatest value software can provide is not recording what happened yesterday. It is helping someone make a better decision tomorrow.

Reality is messier than the database.

When I first started writing software, I thought the difficult part would be translating business processes into code. If somebody could explain how an order was placed, how stock was managed or how payments were processed, then surely the rest was engineering: listen carefully enough, build the appropriate data model, write the business rules and eventually arrive at software that mirrors the operation. It sounds logical. In reality, I do not think that is what businesses actually are.

Businesses are not collections of processes. They are collections of exceptions. The documented process is usually the easy part because it describes the world as everyone wishes it behaved. A customer places an order, payment is authorised, stock is allocated, the parcel is dispatched and eventually it arrives on the customer's doorstep. Everything flows neatly from one stage to the next, each transition represented by another status in the database.

If you were designing an entity relationship diagram, that is probably exactly how you would model it. The problem is that real businesses rarely experience that version of reality for very long.

Customers cancel orders after they have been packed. Payment providers decline transactions that should have succeeded. Couriers lose parcels. Suppliers miss delivery dates. Inventory counts do not match what is physically sitting on the shelf. A product that sold consistently for six months suddenly stops moving for reasons nobody can immediately explain. Sometimes a member of staff catches the problem before it reaches a customer. Sometimes the customer notices first.

None of those situations are particularly unusual. They happen so regularly that calling them exceptions almost feels misleading. They are simply operations.

That distinction took me much longer to appreciate than I expected. When I was managing hospitality operations, I rarely felt as though I spent my day following documented procedures. The procedures existed, and they were important because they gave everyone a consistent starting point. But very little of my time was spent executing them exactly as they appeared on paper. Most of my day was spent adapting them.

One supplier was late, so another order had to be rearranged. A delivery arrived incomplete, forcing substitutions elsewhere. A booking that should have been straightforward suddenly doubled in size. The weather changed, and with it the entire trading pattern for the weekend. Every decision affected the next. The operation was not breaking down. It was simply responding to reality.

Looking back, I think that is one of the biggest misconceptions about operational software. We often behave as though complexity exists because businesses have not yet become organised enough. I think the opposite is true. Complexity exists because businesses interact with the real world, and the real world refuses to remain predictable for very long. Customers are unpredictable. Suppliers are unpredictable. Markets are unpredictable. Even your own staff will occasionally surprise you. No amount of elegant software architecture changes that.

What software can change is how well an organisation responds when those unpredictable things happen.

Once I started thinking about operations in those terms, I found myself paying much less attention to the perfect transaction and much more attention to everything that surrounded it. A refund was not simply a refund anymore. It became a question. Why did it happen? Was the product damaged before dispatch or during delivery? Was the customer dissatisfied because the description was misleading, because expectations had not been managed properly or because the wrong item had been picked? Was this an isolated mistake, or the latest example of something the business should already have recognised?

The same was true of inventory adjustments. Reducing stock by five units is a transaction. Knowing that those five units were written off because packaging repeatedly failed during transit is operational knowledge.

The quantity tells you what happened. The explanation tells you what should happen next.

Traditional software records outcomes remarkably well. Databases are exceptionally good at preserving facts. They remember precisely what changed, when it changed and, if designed well, who changed it. Those capabilities are enormously valuable. But facts, on their own, rarely improve a business. Understanding does.

Two businesses can possess identical sales figures, identical stock histories and identical customer records, yet make completely different decisions because one understands the context surrounding those numbers while the other does not. The database has not failed. It has simply preserved information without preserving interpretation.

That was the real connection I began to make with the experience of training my successor. The difficult knowledge was not disappearing because people were forgetting the process. It was disappearing because nobody had ever captured the reasoning that surrounded the process.

When experienced operators leave an organisation, they do not walk away with the order history. They walk away with the explanations. They know why one supplier is trusted despite occasionally being more expensive. They remember why stock levels for one product were permanently increased after a particularly busy summer. They understand why two apparently identical customer complaints should be handled completely differently. None of that knowledge sits comfortably inside a traditional relational database, yet it is arguably the most valuable information the business possesses.

That realisation changed the way I approached software. I stopped asking whether a system accurately reflected the process. Instead, I started asking whether it accurately reflected reality. Those are not the same question, because reality is rarely as neat as the database we would like to build for it.

The no man's land between engineering and operations.

The more time I spent building software, the more I realised I had been looking at problems from an unusual position. Most software engineers spend their careers becoming exceptionally good at solving technical problems. They think in abstractions, systems, algorithms and architecture. They learn how to design resilient software, optimise performance and write code that remains maintainable as complexity grows. Those are difficult skills to acquire, and they are the reason modern software can scale to millions of users.

Operations asks a different set of questions. How much stock should we hold next week? Why are refunds increasing? Can we trust this supplier? Why does one shift consistently outperform another? Why did revenue fall despite customer numbers remaining stable? None of those questions have purely technical answers.

They emerge from the day-to-day reality of running a business, where every decision is shaped by incomplete information, competing priorities and countless variables that never find their way into a database. They are not answered by reading documentation or designing a better data structure. They are answered by spending time inside the operation itself and gradually learning how the business behaves.

For most of my career, I did not think much about that distinction because I was not building software. I was running operations. Like many managers, my day revolved around solving whatever problem happened to appear next. Some days that meant reorganising staffing because somebody had called in sick. Other days it meant dealing with suppliers, investigating stock discrepancies, resolving customer complaints or making decisions that would affect the following week's trading. The work rarely followed a predictable pattern because the business itself rarely did.

Looking back, I realise that period taught me something far more valuable than I understood at the time. It taught me how operational decisions are actually made. Not how they are described in training manuals. Not how they are documented in procedures. How they are made when reality intervenes.

Only later, when I began writing software, did I realise how different those two worlds really were. Engineering encourages you to simplify problems until they become manageable. Operations teaches you that simplification is often where the important information disappears. Neither perspective is wrong. Both are necessary.

Without engineering discipline, software becomes fragile, inconsistent and impossible to maintain. Without operational understanding, software risks becoming technically elegant while solving only a fraction of the problem it was built for.

I began to notice this divide in conversations with both engineers and operators. Engineers would often ask whether a particular feature was really necessary. Could the user simply export the data? Could they make a note somewhere else? Could another report solve the problem? From a purely technical perspective, those questions were reasonable. What they often underestimated was the cost of asking people to leave the system.

Every notebook, spreadsheet, whiteboard and sticky note represented something the software had failed to capture. Every time an employee had to explain the same situation twice because the reasoning behind the original decision had not been recorded, knowledge was being recreated instead of preserved.

Operators tended to approach the same problems from the opposite direction. They knew exactly where the friction existed because they experienced it every day. They knew which reports they no longer trusted, which workarounds everyone quietly followed and which processes looked sensible until the operation became busy. They understood the pain, but they rarely had the opportunity to redesign the systems causing it.

The result is a gap. On one side are people who know how to build software. On the other are people who know how businesses actually function. Most organisations spend their lives translating between the two.

Looking back, I think I was fortunate to have spent meaningful time in both worlds. Hospitality taught me that businesses are living systems, constantly adapting to changing circumstances and imperfect information. Software engineering taught me that complexity can be organised without pretending it does not exist. Neither discipline, on its own, would have led me to the philosophy described throughout this essay. It was the combination that mattered.

Once you have experienced both sides, you begin to notice that many operational problems are not really technical problems at all. They are communication problems. Knowledge exists, but it exists in the wrong place. It is stored inside people's heads instead of inside the systems that support them. It is passed between colleagues through conversations rather than being captured where future decisions will benefit from it. It disappears whenever experienced people leave, forcing the next generation to repeat lessons that the business has already paid to learn.

That, more than anything else, changed how I started thinking about software. I stopped seeing software as a collection of features. I started seeing it as infrastructure for organisational memory. Not memory in the sense of storing data—that part has been solved for decades—but memory in the sense that matters to businesses: preserving enough context that experience does not have to begin again every time somebody new joins the team.

Once I started looking at software through that lens, the question behind every feature changed. It was no longer, “What information does the user need to enter?” It became, “What understanding should the business still possess five years from now?”

For me, that has become the real purpose of operational software. Not simply to help businesses run, but to help them remember.

More than software.

Looking back, I do not think this essay was ever really about stock ordering. Stock ordering simply happened to be the moment that exposed a much larger idea. At the time, I believed I was trying to teach someone how to perform a task. Only later did I realise that the task itself had never been the difficult part. The real challenge was attempting to transfer years of accumulated understanding—understanding built gradually through mistakes, successes, changing circumstances and thousands of small observations that no report had ever recorded.

That experience changed the way I think about expertise. It also changed the way I think about software.

For decades, we have become exceptionally good at storing information. Modern systems remember almost everything. Every transaction is timestamped. Every payment is logged. Every order has a history. We can retrieve events from years ago in seconds, analyse trends across millions of records and produce reports that would once have taken entire departments to assemble. Yet despite all that progress, businesses still depend on experienced people to explain what those records actually mean.

The information survives. The understanding often does not.

Perhaps that is because we have spent so much time asking software to remember what happened that we have rarely stopped to ask whether it helps people understand why it happened. Those are fundamentally different problems. History is easy to preserve. Understanding is much harder.

I do not believe software will ever replace experience, nor do I think it should. Some judgement can only be developed by making decisions, living with their consequences and gradually learning how a business behaves under changing conditions. That process cannot simply be downloaded into another person's mind.

But I do believe software can do far more than act as a passive record of events. It can preserve context. It can connect information that would otherwise remain isolated. It can expose patterns that would normally disappear with staff turnover. It can explain why previous decisions were made instead of merely recording that they were made. Perhaps most importantly, it can ensure that every lesson a business pays to learn has a better chance of being available to the person who faces that same decision in the future.

To me, that is a far more ambitious objective than automation. Automation is about removing work. Understanding is about improving decisions. Those goals sometimes overlap, but they are not the same thing.

The more software I have built, the less interested I have become in replacing people. Instead, I have become fascinated by helping people make better decisions: helping someone notice the context they might otherwise miss, helping someone understand why something happened rather than simply what happened, and helping organisations retain the knowledge they spend years acquiring instead of rebuilding it every time an experienced employee moves on.

Perhaps that is an idealistic way to think about software. Maybe it is. But I also think it is a practical one. Every organisation accumulates knowledge over time. Every difficult decision teaches something. Every operational mistake carries a lesson. Every experienced employee gradually develops an understanding of the business that extends well beyond the processes written in a manual.

The question is whether that understanding disappears with them, or whether the systems they have worked with have quietly been preserving enough of it for somebody else to continue where they left off.

For me, that is what operational software should aspire to become. Not simply a database. Not simply a collection of features. Not simply another tool that records transactions more efficiently. It should become part of the organisation's memory: a place where knowledge is not only stored, but connected; where context survives alongside data; and where the next person does not begin with an empty screen, but with the accumulated understanding of everyone who came before them.

If we can build systems that do even a small part of that well, then we are doing something more meaningful than digitising paperwork. We are helping organisations keep the one asset that has traditionally been the easiest to lose.

Experience.