Skip to content

Doorman Fallacy

The organizational error of automating a role's most visible task as if it were the whole role, while omitting latent service, coordination, security, signaling, and exception-handling value.

Core Idea

The doorman fallacy begins with a faulty unit of analysis. A role is described by the task easiest to see or count—opening a door, answering a call, processing a form—and an automated device is compared with that task. The device may win the comparison while failing to replace the actual role.

The missing value is often distributed and tacit: noticing anomalies, recognizing people, coordinating nearby work, reassuring customers, handling exceptions, or signaling quality. The fallacy does not claim humans must always remain; it requires replacement decisions to model and reassign the whole function bundle.

How would you explain it like I'm…

More Than Opening Doors

A doorman opens doors, so someone thinks an automatic door can do his job. But the doorman also says hello, notices strangers, helps lost people, and makes the place feel nice. The automatic door can't do those things. Thinking a machine can replace him because it does the easy-to-see part is the doorman fallacy.

The Hidden-Jobs Mistake

The Doorman Fallacy is the mistake of judging a job only by the task that is easiest to see. A hotel might think a doorman's job is opening doors, so an automatic door seems like a perfect replacement. But the doorman also recognized regular guests, spotted problems, reassured visitors and made the hotel feel fancy. The machine wins at door-opening but loses all that hidden value. The lesson is not that people can never be replaced; it is that before replacing a role, you need to list everything it really does and decide who or what will do each part.

Visible-Task Replacement Error

The doorman fallacy is an error in judging whether automation can replace a role. It starts with the wrong unit of analysis: the role is described by its most visible or countable task, such as opening a door, answering calls or processing forms, and a machine is compared only against that task. The machine may win that comparison and still fail to replace the role. What gets lost is often spread out and unspoken: noticing anomalies, recognizing people, coordinating nearby work, reassuring customers, handling exceptions or signaling quality. The fallacy doesn't mean humans must always stay; it means a replacement decision must model the whole bundle of functions and decide who or what will take over each one.

 

The doorman fallacy is a reasoning error about automation that begins with a faulty unit of analysis. A role is defined by its most visible or countable task, such as opening a door, answering a call or processing a form, and an automated device is evaluated against that task alone. The device may outperform on that narrow comparison while still failing to replace the actual role. The value that goes missing is often distributed across many small activities and is tacit rather than documented: noticing anomalies, recognizing people, coordinating adjacent work, reassuring customers, handling exceptions, or signaling quality. The fallacy is not the claim that humans should never be replaced. Instead, it requires that replacement decisions model the entire bundle of functions a role performs and explicitly reassign each one.

Scope of Application

  • Service design. Discovers invisible work behind customer-facing roles.
  • Automation investment. Broadens business cases beyond direct task cost.
  • Organizational redesign. Assigns exception, coordination, and signaling functions after role changes.
  • AI deployment. Separates text or transaction output from relationship and accountability work.

Clarity

Analysts should compare role systems, not job titles or isolated tasks. List beneficiaries, routine actions, interruption handling, information flows, trust effects, and safeguards before choosing metrics. Inclusion test: Show that a role was reduced to one visible task, replacement was evaluated on that proxy, and material omitted functions were neither preserved nor valued. Exclusion test: Exclude ordinary automation failure, opposition to all automation, job preservation as an end in itself, and replacement after a complete function-and-outcome analysis. Nearest boundary: Automation bias is overreliance on automated outputs; the doorman fallacy occurs earlier, when the role being replaced is modeled too narrowly. Exit condition: The error disappears when the full role bundle is inventoried and its important functions are deliberately retained, transferred, or judged unnecessary.

Manages Complexity

The fallacy compresses a common modeling failure into a memorable diagnostic. It restores distributed value to the decision without treating every tacit benefit as priceless or immune to evidence.

Abstract Reasoning

  1. Observe the role across routine and exceptional situations.
  2. Separate the salient task from the full function bundle.
  3. Map each function to stakeholders and outcomes.
  4. Compare replacement and hybrid designs on the expanded model.
  5. Monitor indirect losses and revise responsibility assignments.

Knowledge Transfer

The diagnostic transfers wherever a role combines visible output with tacit coordination or signaling. It should not be invoked as a rhetorical shield against any measured productivity change.

Relationships to Other Abstractions

Local relationship map for Doorman FallacyParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Doorman FallacyDOMAINPrime abstraction: Latent Service Bundle — presupposesLatentService BundlePRIME

Current abstraction Doorman Fallacy Domain-specific

Parents (1) — more general patterns this builds on

  • Doorman Fallacy presupposes Latent Service Bundle Prime

    The Doorman Fallacy presupposes a Latent Service Bundle because the error occurs when one visible task substitutes for an unpriced bundle of coordination, security, signaling, and exception-handling value.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Doorman Fallacy sits in a crowded region of the domain-specific corpus (32nd percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Organizational Patterns & Management Concepts (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08