Future of Work

We Never Learn From the Doorman Fallacy

A five-star hotel hires a consulting firm to find savings. The consultant walks the building, watches the operation, and

By Conor Healy

July 1, 2026

A five-star hotel hires a consulting firm to find savings. The consultant walks the building, watches the operation, and settles on the doorman. He costs roughly $40,000 a year, and as far as anyone can see, all he does is open a door. Install an automatic mechanism, the consultant advises, and the salary becomes profit. The hotel agrees and the doorman is let go.

According to Rory Sutherland, who tells this story in his book Alchemy, the place is a mess within two years. The doorman had never simply opened doors. He hailed taxis in the rain, remembered returning guests by name, and turned away the people who should not have been let in. He carried bags, settled disputes with cab drivers, watched the street, and signalled, just by standing there in a good coat, that this was the kind of establishment where someone stood at the door. None of it appeared in the consultant’s report, because none of it was the part of the job you could point at.

Sutherland calls this the doorman fallacy: the error of defining a role by its most visible task, removing that task, and treating the saved cost as pure gain, while everything the role quietly held together comes apart somewhere off the balance sheet.

The reason the doorman fallacy is worth a name is that we keep falling for it. The story is not really about one hotel. It is about a way of seeing that recurs every time a new technology makes an old job look redundant.

Why the Visible Task Wins

Value comes in two layers, and only one of them is easy to see.

The surface value of a doorman is door-opening. It is legible, countable, and simple to put a price on. The real value is everything beneath it: security, status, hospitality, the judgment to know who belongs. That layer resists measurement, which is exactly why it gets discounted to zero. Anyone paid to find efficiencies will tally what is visible and quietly ignore what is not, because the visible number is the one that survives a slide deck.

This is a relative of Chesterton’s fence, the old principle that you should not tear down a fence until you understand why someone built it. The doorman is a fence in the shape of a person. Pull him out before you understand what he was holding back, and you learn his real functions the hard way, as a series of new problems nobody can quite trace back to the decision that caused them.

That tracing problem is the heart of why the fallacy survives. The cost of the doorman is immediate, certain, and attached to a name. The value he provided is diffuse, delayed, and attached to nobody in particular. When the takings dip two years later, no line item reads “absence of doorman.” The executive who cut him has already booked the saving, claimed the win, and very possibly moved on. The losses land on someone else’s desk, in a form too vague to litigate. The incentives reward the cut and hide the consequence, which is a reliable recipe for doing the same thing again.

The Cashier Was Also a Guard

The clearest recent example is the supermarket self-checkout.

Define a cashier narrowly, as a person who scans items and takes payment, and the machine is an obvious upgrade. Customers scan their own goods, the retailer sheds wages, and the queue theoretically shortens. For most of the past decade that was the consensus, and self-checkout spread to the point where it sits in roughly 96% of grocery stores.

Then the figures on theft arrived. Shrinkage at self-checkout lanes runs around 3.5 to 4%, against roughly 0.21% at a staffed register, a gap of more than fifteen times. In one LendingTree survey, 27% of self-checkout users admitted to deliberately walking out with something they had not scanned, up from 15% two years earlier. United States retailers now lose an estimated $4.9 billion a year to self-checkout theft alone.

The cashier, it turned out, had a second job nobody had written down. A human at the register is also a deterrent, a witness, and a quiet check on the basic honesty of the transaction, so removing the person costs the store far more than the scanning it set out to automate.

So the retailers are walking it back. Walmart has pulled machines from some stores and restored staffed lanes. Dollar General stripped self-checkout from 12,000 locations. Costco now puts a worker in the line to pre-scan carts. The proof sits in the police logs: at one Walmart in Shrewsbury, calls to the store fell from 509 in the first five months of one year to 183 in the same stretch of the next after the machines came out, and arrests dropped from 108 to 49. The cashier was never only a cashier, and the industry is paying tuition to relearn it.

Now It Is the Programmers

The doorman fallacy has found its largest target yet. This time the role is software engineer, and the automatic door is AI.

The logic is identical. A manager looks at a programmer and sees a person who writes code. AI writes code now, and writes a lot of it: on recent benchmarks the strongest models resolve the majority of standard tickets, and at many firms close to half of new code is already machine-generated. If the job is writing code, and the machine writes code, then the headcount looks like a cost waiting to be cut. The same reasoning that retired the doorman is now applied to the engineering team, and it is wrong for the same reason.

Writing code is the surface value of software engineering, the visible and benchmarkable part, which is precisely why it draws the eye. The real value rarely shows up in a commit. It lives in deciding what to build, in hearing the requirement a client states without meaning, in knowing that one ageing service runs a fragile job at 2am that must never be touched on a Friday, in choosing an architecture that survives three years of changes rather than buckling under the fourth, and in being the named human who answers for it when the thing falls over at midnight.

One way to hold this in view is as a decide-execute-deliver sequence. AI is genuinely strong in the middle, the execution, the production of working code. It is far weaker at the ends: deciding what ought to be built, and owning the result once it ships. When the middle compresses, the two ends do not shrink to match but instead become most of what the job consists of.

The 70% Problem

Addy Osmani, who builds developer tools at Google, describes what he calls the 70% problem. AI carries you about seventy per cent of the way to a working solution, and it does so quickly. The final thirty is the hard part: the edge cases, the security holes, the behaviour under real load, the fit with systems that already exist.

That last stretch is where engineering judgment lives, and reaching it means understanding what the first seventy per cent actually did. People without that understanding hit a wall, unable to debug a thing they did not build. The ratio may improve to eighty per cent on a clean project, but the character of the remaining work holds steady. It is the part that fails at 3am and needs someone who knows why.

None of this is hypothetical. A controlled trial by METR found that experienced developers using AI tools were 19% slower on real tasks in their own codebases, partly because checking and fixing the output is itself expensive work. For senior engineers on complicated systems, the tidy productivity gain that justifies the layoff is often not there to begin with.

The Theory Lives in People

The deeper limit is that a model knows everything about code in general and nothing about your code in particular.

The agent has read most of the public programming knowledge ever written. It has read none of the undocumented, institution-specific lore that makes a real system run. It does not know that your European users are legally owed a double opt-in, that a particular microservice was written by someone who left in 2021 and cannot safely be redeployed, or which corners were cut deliberately and which by accident.

Peter Naur made this argument back in 1985, decades before any of it was a product. In an essay called “Programming as Theory Building,” he argued that a program is not the text of its code but a theory held in the minds of the people who built it, a shared grasp of why the system has the shape it does. He demonstrated that even with full documentation, a second team struggled to extend a program the first had written, because the theory never travelled with the files. Fire the people and keep the code, and you are left holding the documentation without the understanding, which is the software version of keeping the door and losing the doorman.

Cutting Juniors Eats the Seed Corn

There is a second-order version of the mistake that is quietly the most expensive of all.

Because AI is best at exactly the work junior developers used to cut their teeth on, the boilerplate and the simple tickets and the supervised practice, firms have reacted by hiring far fewer juniors. Entry-level developer hiring has dropped steeply, by some accounts between 60 and 73% in a single year, even as overall demand for engineers carried on growing.

The trouble is that senior engineers are not minted. They are grown, slowly, out of junior engineers who spend years accumulating the tacit knowledge AI cannot hand over. Cut the bottom of the pipeline now and the shortage arrives in a decade, when the people who would have become the architects never got the apprenticeship that produces judgment. The role that looks most disposable today is the one that manufactures the people who turn out to be irreplaceable tomorrow.

The Lesson

Sutherland’s argument was never that automation fails. Automatic doors work perfectly well. The argument is that you have to understand the whole of a role before you delete it, because the obvious function is so seldom the valuable one, and the valuable one so seldom shows up where you are looking.

The firms handling AI well are not the ones cutting hardest. They treat it as something that compresses the execution while leaving the harder layers in human hands, which frees their engineers to spend more time on the deciding and the owning rather than less. The firms handling it badly are looking at their engineers the way the consultant looked at the doorman and the way the retailers looked at the cashier: seeing the one task that can be automated, missing the several that cannot, and reaching for the saving before anyone has counted the cost.

We have run this experiment with doormen, with cashiers, and with a dozen roles in between. The result has been the same every time. Before handing a job to a machine that can do its most obvious part, it is worth asking what the job was actually doing. The doorman opened the door. That was the least of it.