The Doorman Fallacy (But for IT)

From a pure economics viewpoint if you only measure the act of door-opening, replacing the doorman with an automatic door looks like an operational no-brainer. Same output. Lower cost. Frictionless process.

Until you realize the doorman was never just opening the door.

They were greeting regulars, spotting security threats, managing luggage, hailing taxis, and quietly shaping the entire experience of arrival. The visible task was not the whole value.

IT has its own version of this mistake.

We commit it when we define developers as people who write code, support teams as people who close tickets or architects as people who draw diagrams. None of these descriptions are technically wrong, they are just dangerously incomplete.

In technology, the highest-value work is often invisible: it is the work that stops something bad from happening.

When IT works beautifully, its value is quiet, and quiet value is incredibly easy to underestimate on a spreadsheet.

The Surface Task vs. The Hidden Function

Every IT role operates on two levels: the visible output (the metric) and the hidden function (the actual value).

• The Developer: Visible Output: Writing lines of code. Hidden Function: Carrying product memory, spotting fragile logic and knowing when a "quick change" will break a downstream system.
• The Support Analyst: Visible Output: Resolving Jira tickets within SLA. Hidden Function: Absorbing user frustration, translating chaos into actionable feedback and identifying systemic failures before they become crises.
• The Infrastructure Engineer: Visible Output: Keeping servers online. Hidden Function: Managing technical debt, resilience, patches and recovery paths that nobody wants to fund until a disaster hits.
• The Enterprise Architect: Visible Output: Drawing component diagrams. Hidden Function: Preventing today's localized, short-sighted decision from becoming tomorrow's multi-million-dollar technical prison.

The mistake happens when we only manage the visible task. That is when the wrong question gets asked: "Can we get the same output cheaper?"

The better question is: "What invisible value are we relying on this role to provide?"

Developers Are Not "Code-Generating Units"

From the outside, software development can look like an assembly line: Requirements go in, code comes out, features get shipped. Naturally, leaders focus on velocity, throughput, and cost-per-story-point.

But great software engineering relies heavily on institutional judgment:

• Knowing which legacy table shouldn't be touched without checking three downstream finance reports.
• Understanding the undocumented workaround put in place for a major client five years ago.
• Knowing the difference between "simple in theory" and "simple in reality."

When an organization outsources or cuts an engineering team purely based on coding capacity, the capacity might stay, but the context leaves.

The danger is that context loss doesn't trigger an immediate alert. Code still appears. Tickets still close. The true cost arrives months later disguised as regression defects, longer incident response times, nervous change advisory boards and mounting tech debt.

The Reality: If you treat engineers as code-generating units, you lose the judgment that stops code from becoming a liability.

Support Is the Organization's Listening Layer

IT Support is too often dismissed as a pure cost center. A ticket comes in, a ticket gets closed, and a dashboard reports compliance.

But a seasoned support team sees the operational truth that dashboards obscure:

• They see the system that technically works but fundamentally confuses users.
• They see the shadow IT workarounds teams have built because the official tool is too slow.
• They see where corporate training is missing and where poor software design is being compensated for by human frustration.

When support is severely weakened or outsourced carelessly to a vendor focused solely on ticket volume, you don't just lose resolution capacity you lose your early warning system.

The Paradox of Quiet Infrastructure

Infrastructure management has a unique curse: When it works perfectly, people ask why it costs so much. When it fails, people ask why it wasn't better funded.

Stable infrastructure is often mistaken for simple infrastructure. In reality, quiet operations are the result of intense, disciplined, and proactive effort: capacity planning, certificate renewals, patch management, and testing the disaster recovery scenarios everyone assumes will just work.

This leads to a dangerous paradox: the better infrastructure is managed, the less dramatic it looks.

The Trap: It is incredibly easy to delay the invisible work. We can patch next month; we can review resilience later. Until the platform fails. Then, the invisible work becomes painfully visible.

AI and Automation Amplify the Fallacy

This issue is more critical than ever as AI agents and automation transform the workplace.

Automating repetitive tasks and leveraging generative AI tools is smart operational strategy. However, AI easily tempts leaders into a modern variation of the Doorman Fallacy, because AI can perform the visible task (e.g., generating a script or answering a basic service desk query), it is easy to assume the role has been entirely replaced.

• AI can write code, but it doesn't understand your unique regulatory constraints, historic compromises or customer promises.
• Automation can close common tickets, but it cannot recognize when a sudden spike in queries points to a deeper, systemic design flaw.

The organisations that win with AI will not be those that blindly use it to eliminate people from processes they don't fully understand. They will be the ones that understand their operations deeply enough to know what to automate, what to redesign and where human judgment is non-negotiable.

The IT "Doorman Test"

Before you cut, outsource, automate or restructure an IT function, challenge your leadership team with these questions:

1. What is the visible task, and what is the hidden function?
2. What does this role or team quietly prevent?
3. What undocumented context do they hold, and who else knows what they know?
4. What breaks three months after they leave that is working today?
5. Can the visible task be automated without sacrificing the invisible judgment?

IT must evolve. Operating models must change and automation should ruthlessly eliminate waste. Teams should never be shielded from optimization simply because they are busy.

But transformation requires true understanding. When leaders optimize purely for the visible task while ignoring the hidden function, they don't modernize IT.

They hollow it out.

Before you remove the doorman, make sure you know exactly who is going to hold the door.