# What a Hotel Doorman Taught Me About Building Software - Published: 2026-11-10 - Author: [Daniel Haiem](https://informaticsmagazine.com/author/daniel-haiem.md) - Topics: [Insights](https://informaticsmagazine.com/insight.md) - Source: https://informaticsmagazine.com/insight/what-a-hotel-doorman-taught-me-about-building-software/ - Publication: Informatics Magazine - Publisher: Connectively (Terkel, Inc.) - Editorial policy: https://informaticsmagazine.com/editorial-policy/ I recently came across a concept called the *doorman fallacy*. Someone posted about it somewhere (I can't remember where exactly), but it was so interesting that I made time to look it up. So, advertising executive Rory Sutherland coined the term "doorman fallacy" in his 2019 book *Alchemy*, and he illustrates it with a hypothetical hotel. Picture a hotel manager reviewing costs and realizing that the doorman draws a full salary for just opening a door. He figures that if he gets an automatic door, it will save him money. Obviously, the math looks reasonable. The thing is, the doorman was never just opening a door. He greeted customers, hailed taxis for those who needed one, recognized regulars, and kept an eye on who walked in. Yes, the hotel might have been able to save on payroll, but it could risk losing some regulars along the way because they no longer feel welcome, or because nobody is hailing taxis anymore or watching who walks in. That's the concept of doorman fallacy. You define a role by its most visible task, then you automate it and eventually lose everything else the role was quietly doing. What's funny is that I've seen companies make the same mistake with software for years — even myself — and I didn't know there was a term for it. Now, with AI booming, that mistake is becoming even easier to make. Ever since automation became a thing, I've heard countless versions of, "Can we just automate this?" Don't get me wrong, some things genuinely need to be automated to make our lives easier. But there are also times when the workflow they want to replace is rarely as simple as the process document says. There are small steps between the obvious ones that most of us overlook, and the worst part is we won't notice them until later, after the gap has already left dents in the whole process. Just like what happened at Klarna. In early 2024, the company said its AI assistant was doing the equivalent work of 700 full-time customer service agents, but by 2025, its CEO acknowledged that the cost-focused approach had hurt service quality, and Klarna began expanding human support again. They didn't abandon AI completely, though. They basically kept the assistant and added people back where quality had slipped. Simply put, AI could handle the visible task, but the quality of the service was the doorman. I have been trying to avoid the same mistake for the past few years. Whenever automation is in question — because we love to automate — my team and I do a simple exercise where we list every outcome the role touches, not every task it performs. The questions include: Who does this person talk to? What do they notice that nobody asked them to notice? Which complaints never reach leadership because this person handles them first? If that list runs longer than the job description, you've found your doorman. And if you do, for the love of God, do not replace them. Now when it comes to setting an automation for our clients or if the project involves automation, the first thing I do is evaluate it by pricing everything the role or step touches, not just what it costs overall. This leads me to questions like, "What happens to retention, error rates, escalations, and customer trust?" If nobody on the team can answer that, the savings on the spreadsheet aren't real yet, they are merely an attempt to guess. Now, let me be clear, none of this is an argument against automation. Most of the software we build exists to remove manual work, and much of it should. I am simply reminding founders, developers, and whoever this may concern about the sequence. You have to understand the full job first, then decide which parts the machine should take. This article was first published on [Featured News](https://news.featured.com/what-a-hotel-doorman-taught-me-about-building-software). ## Related - [AI assistants cited our pages thousands of times, but few visits were traceable](https://informaticsmagazine.com/insight/ai-assistants-cited-our-pages-thousands-of-times-but-few-visits-were-traceable.md) - [Assessing AI skills is now my life, and here’s what it taught me](https://informaticsmagazine.com/insight/assessing-ai-skills-is-now-my-life-and-heres-what-it-taught-me.md) - [Where New Patients Disappear: Funnel Analytics for Private Practices](https://informaticsmagazine.com/insight/where-new-patients-disappear-funnel-analytics-for-private-practices.md) - [Naming a Dish Is the Easy Half: Structuring a Food Database That Actually Reflects a Country's Cuisine](https://informaticsmagazine.com/insight/naming-a-dish-is-the-easy-half-structuring-a-food-database-that-actually-reflects-a-countrys-cuisine.md)