The system is faster than you

The system decides first. The name on the shift is still yours.

Every job I have done had a system in it that was faster than me. The till in the shop. The scanner and the route planning in last mile. The hotel system at the front desk and in Night Audit. The dashboard that turns red. In more than thirty essays on this site those systems appear on most pages and are the subject of none. They are there the way the desk is there in a story: everyone works on it, nobody describes it.

In a shift, nobody asks whether we should use technology. It is there when you arrive and it will be there when you leave. The question that really comes up, in different words, is another one: the system says one thing, the floor says another, whom do I believe?

And behind it a harder one: when the system was wrong and I followed it, who is responsible?

This essay opens a series about that question. Not about which systems to buy, and not about what they will do in five years. About what is left for the person on shift when the system is faster than them.

What I have and what I do not

As in the rest of this site, I will not name systems or applications, and I will not describe how they work inside.

What I have: a change to the route and time planning system in last mile, in August 2025, which I write about below. The work with drivers, tours and the operational problems that arise between the plan and the ramp. From the hotel, documented complaints about water pressure and bathroom cleanliness, which showed me how far apart the status in a system and the history of a problem can be.

What I do not have: a documented case in which a system took a wrong decision, I discovered it and I corrected it. And no measurement of how often the system is right. I cannot say that it is often wrong, nor that it is rarely wrong.

So the scenes with drivers and tours in this essay are pictures, marked as such, not memories.

August 2025: the plan that wanted to learn from the floor

In August 2025, in last mile, a change was introduced to the system that planned the tours and the time. One of its aims was to reduce unrealistic plans, planning errors and operational exceptions. It was also intended that information from the field would be used to improve the planning.

I will not say what changed after that, because I have not measured it. But the aims themselves say something, and this is my reading. A system that has to reduce unrealistic plans has produced unrealistic plans. And a system that needs information from the field admits, in its own language, what the floor has known for a long time: some things can only be seen out there.

The question that remains is who brings it that information. The system does not take it by itself. It gets it only if someone on the floor sees it, writes it down and sends it somewhere someone can use it.

When the system is right, until the moment it is not

Imagine a tour planned by the system for a new driver. The order of the stops is perfect for the system: the shortest distance, the least time, no going back. The driver follows it. The third stop is a shop that opens at ten, and the system has put it at half past eight because it was nearer.

The system has not failed. It did what it was built for: it calculated distances. It did not know that the shop has opening hours, because nobody told it. A driver who knows the area would have seen it in a second. The new driver trusted the screen, because the screen was faster and surer than the driver's own judgement.

The work is not to fight the system. A shift in which every decision of the system is checked by hand is not safer, only slower. The work is to recognise the cases in which the system is wrong when they come. Those cases often have the same shape: the system did not know something the floor knew. The opening hours. That the second gate is broken. That the guest in that room is the one who complained yesterday. That the bag with that code was on the wrong trolley, even though the scan said yes.

The system is faster than you in everything it was told. It knows nothing of what it was not told. And most of what the floor knows has never been told to anyone.

Three ways to get it wrong

There are three ways a shift lead can get this wrong. They are not cases I have documented. They are patterns that anyone who has worked next to a planning system will recognise.

Full trust. The system said it, so it is so. When it goes badly, the answer is “the system assigned it”. It is the most comfortable answer and the most dangerous, because it hands responsibility to something that cannot carry it. The customer in front of the closed shop does not ask the system.

Full distrust. The experienced driver who changes the tour every day without saying a word. They may be right. But their knowledge stays in their head: the system does not learn, the new driver does not learn, and on the day they are absent, the tour goes back to the first mistake.

The silent correction. The shift lead who corrects the system by hand every morning, in the same places, for weeks. They have solved the problem for themselves and left it for everyone else. This is exactly the information from the field that a system like the one from August 2025 needed, and it never reaches it. A correction that repeats is not a correction. It is a fault in the system that nobody has reported.

At the front desk: the status and the history

In the hotel, the system knows the reservations, the room statuses, the arrivals, the departures and the transactions. The front desk also knows what the guest says at the counter and what comes from the other departments.

From Night Audit I have documented complaints about the water pressure in the shower and about a bathroom that had not been cleaned properly. Neither was solved at the front desk: the first belonged to Maintenance, the second to Housekeeping, as I wrote in Mistakes get lost between departments. And when they stayed open, the next shift had to know.

I do not have a case in which the system showed a wrong status. But the lesson I draw is this: the status in the system and the full history of a problem are not the same thing. A room can be “free” on the screen and have behind it a complaint that nobody has closed. That history is not kept by the system. It is kept by the handover, if someone writes it down.

Three questions for every decision

For every decision the system takes in my shift, today I would want to know three things. What the system knows when it takes it. What it does not know. And how I, from the floor, notice when it is wrong.

The first two questions are answered once and written down. The third is the work. In last mile the answer can be a call from the driver, a trolley that does not match its tour, a number in the stand-up that does not match the day. From a distance, as I wrote in Leading 80+ vehicles you cannot see, the answer is thinner: the problem reaches you only if someone sees it, understands it and reports it.

If I cannot answer the third question for a decision, I am not running that part of the operation. I am following it.

And after the questions comes the rule. A decision suggested by the system does not remove the human responsibility to check it, especially when there are signs that something is not right. But that only holds if it is clear who can correct the decision, who approves the change, and how the problem is recorded. Without those three, “check it” means “correct it in silence”.

The rule that remains

The system may have been wrong. The name on the shift is yours. That is not unfair. It is the job.

The aim is not to choose between the system and experience. The aim is a process in which the system helps you work faster, and people have a way to notice, report and correct what the system does not understand. The system gives you speed, memory and numbers you would never have on your own. In exchange you give it what it does not have: eyes on the floor, a question when something does not make sense, and a name that answers.

The essays still to come in this series are about that exchange: the tour the driver does not understand, the scanner that is a witness and not a judge, the dashboard that turns red before you, the report a machine wrote, and the night the system went down and we saw what the team really knew.

Who decides what

The card below has one row for each decision the system takes in your shift. For each one: what the system knows, what it does not know, how you notice when it is wrong, and who can correct it, who approves, where it is written down. The last row is for the correction you make by hand every day, the one that should have been reported long ago. KPI Diagnostic helps with the numbers the system shows you: what a red number tells you before you act on it.

The system decides first. What is left for you is the part it was never told, and the name that answers for all of it.