The Human Stays in the Room

There is a slightly embarrassing gap in the story so far. I have spent chapter after chapter telling you to go to the person doing the work, watch what gets in their way, listen to the workaround and let them puncture your assumptions. Then, if I am not careful, the story can sound as though I thank them very much for the insight, disappear with my laptop and return later carrying the answer.

That is not how I want this work to happen, and it is not how the best of it has happened. The person in the middle is not merely the source of the requirement. I cannot simply stop involving them once the prototype works. If their judgement mattered enough to understand the problem, I need to be very sure why it suddenly stops mattering when I design the solution.

I learned that most clearly in a piece of work that, on paper, looked like exactly the sort of thing designed to remove humans from the middle. Finance needed data from an old restaurant system to arrive in a new finance platform in a very particular form. The existing route involved too much handling, too much checking and too much opportunity for a tiny inconsistency to become somebody's afternoon. I built middleware, software that moves and translates information between systems, to take the pipe-delimited files, transform what needed transforming and pass them on in the format the receiving system expected.

It is difficult to make middleware sound exciting without either lying or inviting a very particular sort of person to dinner, but I loved that project. More than five thousand files eventually travelled through it. Most of the time nothing interesting happened at all, which is exactly what you want from middleware. Data arrived, the transformation happened, Finance got what it needed and nobody had to become a human integration layer between two systems that ought to have been capable of speaking for themselves.

Then one day it stopped.

The culprit was not a collapsed database, an expired certificate or anything else dramatic enough to justify the expression on my face. It was a trailing space. One category had arrived as 'Cocktails ' rather than 'Cocktails'. A single invisible character was enough to upset the process. Somewhere, a computer was effectively saying that Cocktails and Cocktails-with-a-tiny-bit-of-nothing-on-the-end were entirely different things, and technically it was right, which was of very little comfort to anybody trying to get the finance data through.

That tiny incident reinforced something I had already been circling for years. The aim was never to remove Finance from Finance. It was to remove the mechanical work that prevented Finance doing Finance. I did not need a skilled finance person spending part of their day moving information between systems because the systems could not manage it. I did need their understanding of what the numbers meant, what looked wrong, which exceptions mattered and what the business would need to do next.

There is a huge difference between those two things, and I think technology projects blur it far too easily.

When I say I want the human in the middle, I do not mean I want a person ceremonially clicking Approve on every automated process so I can claim it has human oversight. That is not meaningful involvement. It is a workflow wearing a safety badge. Nor do I think every human step deserves to survive simply because somebody currently performs it. If a person is copying a number from one screen to another because two systems cannot talk, that is not valuable human judgement. That is an integration problem wearing a name badge.

The question I have learned to ask is much more useful. What is the person contributing here?

Sometimes the answer is judgement. They know that the number can be technically valid and still look wrong. Sometimes it is context. They know there is a local event tomorrow, a road is closed, a supplier is late or a school holiday has moved the shape of the week. Sometimes it is empathy. Sometimes it is accountability. Sometimes it is the ability to deal with the exception that nobody imagined when the process was drawn neatly on a screen. Sometimes, frankly, the answer is that they are contributing a pair of hands because the software is rubbish. Those cases should not all be treated the same.

That is why I am uncomfortable with the phrase human in the loop when it is used as though the presence of a human automatically makes an automated system responsible. A person can be in a loop and have no real say in what happens. If the system presents a decision at speed, with no useful explanation, and the person is expected to approve it ninety-nine times out of a hundred, I have not preserved judgement. I have probably created a very bored liability sponge.

I want something stronger than that. I want to know where human judgement genuinely improves the outcome, and I want the technology designed around that fact rather than around an ambition to automate everything that moves.

Forecasting taught me the same lesson, as I will come to shortly. The users challenged what I had built, and their expertise turned out to be part of the intelligence the product needed to respect.

A restaurant manager who has lived through fifteen years of Friday nights has a model too. It is not written in Python and it will not produce a lovely accuracy metric, but it contains weather, football, payday, local habits, staffing reality and thousands of tiny observations that have been accumulated without anybody calling them training data. I would be foolish to throw that away simply because my version has a chart.

The better relationship is not human versus machine. It is to decide which part of the work each is unusually good at. Let the machine remember every transaction. Let it compare patterns across years. Let it do the repetitive transformation at two in the morning without becoming bored, distracted or resentful. Then let the experienced person challenge the strange result, understand the exception, make the consequential judgement and explain it to another human being when that matters.

That balance changes from problem to problem. In one process the person may remain the decision maker while the technology supplies evidence. In another they may become the exception handler. Somewhere else the system may act automatically ninety-nine percent of the time and bring the one unusual case to somebody who has the authority and context to do something sensible with it. Occasionally the evidence will show that the human step adds nothing at all and can safely disappear. I am fine with that too. What I am not fine with is making that decision accidentally.

This matters during the build as much as after it. The people who help shape a pilot should not become passive recipients the moment it scales. I want a route back from real work into the thing I built. If people start creating workarounds around my workaround remover, that is not user resistance. It is evidence. If they stop trusting a recommendation, I want to know why. If the world changes underneath the assumptions, the system needs a way to learn that before somebody writes a six-page business case explaining why everybody should please use it properly.

There is a temptation in technology to treat completion as the moment the project team leaves. I increasingly think completion is closer to the moment the relationship changes. During discovery I need the person doing the work to show me reality. During the pilot I need them to contradict me. Once the thing is live I still need them, but now I need them to tell me when reality has moved.

That is a much healthier definition of human involvement than keeping somebody trapped in a pointless manual step for fear that automation sounds unfriendly.

Automate the task if the task deserves automating. Remove the copy-and-paste. Remove the re-keying. Remove the weekly hunt for a number that a machine can surface in a second. I have absolutely no nostalgia for work that exists only because systems are badly joined together. But do not accidentally automate away the judgement that made the work valuable in the first place.

There is another reason this matters, and it becomes more important as AI improves. The easier it becomes to create an answer, the easier it becomes to stop asking the person with the problem. I can now sit at a laptop, describe what I think is happening and produce something polished enough to fool myself before lunch. That is not a superpower I entirely trust. The speed is useful only if I keep returning to reality quickly enough to be corrected by it.

So the human stays in the room. Not because humans are automatically better, and not because machines are automatically suspect. The human stays because meaningful work contains context, consequence and judgement, and I want to know exactly which of those I am changing before I congratulate myself on an efficiency.

The simplest test I have found is one I wish I had been asking much earlier in my career. If this works exactly as designed, what does the person stop doing, what do they still decide, and what becomes possible for them that was not possible before?

Those three answers tell me far more about whether I have helped than a diagram showing that the process now has fewer boxes.