The Ghosts in the Machine

In software engineering, we talk about “design patterns”—elegant, reusable solutions to common problems. But for every good pattern, there’s an “anti-pattern”(or a Bad-Smell as we lovingly call it), a common practice that seems like a good idea but ultimately leads to trouble. One of the most intriguing of these is the “Poltergeist.”

What is a Poltergeist in Software?

Picture this: in your codebase, you have lightweight classes that appear as if from nowhere. Their entire existence is to perform a tiny, fleeting task—often just forwarding a call or shuffling data from one significant class to another. They don’t hold any substantial logic or long-term responsibility.

They’re ghosts in the machine. They float in, do a minimal job that could have been handled by someone else, and then vanish.

The trouble with these poltergeist classes is the unnecessary complexity they introduce. Instead of a clean architecture with well-defined components, you get extra, phantom layers that obscure the logic. They make the code harder to read, tougher to maintain, and slower to develop. Every time you need to trace a process or implement a change, you have to navigate through these ghostly intermediaries that add friction without adding value.

Does This Sound Familiar? The Organizational Parallel

Now, let’s step away from the code editor and into the office. Does this pattern sound familiar?

Large organizations, in particular, can inadvertently create their own poltergeists. These are the roles, or sometimes entire teams, that exist primarily as intermediaries. They don’t create unique value but instead spend their time relaying information, scheduling meetings for other teams, or acting as a go-between for departments that should be communicating directly.

Just like in software, these organizational poltergeists create friction. They can slow down decision-making, add unnecessary steps to simple processes, and create frustrating bottlenecks. If you’ve ever felt your progress halted because you’re waiting for a person whose only job is to forward your request to the person who will actually do the work, you’ve encountered an organizational poltergeist. You’re dealing with bloat that gets in the way of meaningful progress.

Exorcising the Ghosts: A Call for Clarity

The good news is that once you can name the pattern, you can start to address it.

In software, the solution is called refactoring. A developer identifies the poltergeist class and merges its fleeting responsibility into a larger, more permanent class that it interacts with. The goal is to eliminate the unnecessary middleman and simplify the system.

The solution in an organization is strikingly similar. It involves streamlining processes and clarifying responsibilities. It means asking tough questions:

• Does this role add unique value, or does it just pass information along?
• Can we empower teams to communicate directly instead of through a coordinator?
• Can this responsibility be absorbed by an existing team to make the process more efficient?

Whether we’re talking about code or companies, the lesson is the same: clarity is kindness. A system—be it software or human—runs best when every component has a clear and meaningful purpose. By identifying and eliminating the ghosts, we reduce complexity, decrease frustration, and empower every part of the system to focus on what truly matters.

So take a look at your codebase, and then take a look at your org chart. Don’t let the poltergeists haunt your productivity.