Every growing company has one. The person who can tell you, from memory, which reports were finalized before the quarter closed and which were amended after. The person who checks two systems before answering a customer question because the two systems disagree about a third of the time. The person who has a spreadsheet that nobody asked them to build, that nobody else fully understands, and that the finance team quietly depends on every month.
Leadership usually describes this person the same way: invaluable. They know how everything works. They are the one who keeps things moving when a process breaks down, which, in most growing organizations, is often.
That description is accurate, and it should be more alarming than it is. An employee becoming indispensable because they can hold together a business process that the organization's own systems cannot is not a story about talent. It is a story about an operating model that has quietly stopped functioning on its own.
The Work Nobody Designed
Most of this work was never assigned. Nobody wrote a job description that said reconcile the CRM against the billing system every Friday, or confirm with three departments that an order actually shipped before telling the customer it did. These responsibilities accumulate the way sediment does: one exception handled manually because there was no time to fix the underlying process, then another, then a habit, then a system that exists only in the practiced judgment of the person doing it.
Call it what it is. These employees are functioning as middleware. In a well-designed technology environment, middleware is the layer that lets separate systems exchange information automatically, without a person in between. In a growing company where that layer was never built, or was outgrown years ago, people fill the gap instead. They move information between platforms that were never connected. They interpret inconsistent data to figure out which version is correct. They remember exceptions that were never documented because nobody had time to document them. They tell the next team a step is complete because no system does it for them.
This is Human Middleware, and it is one of the most reliable signs of Operational Friction in an organization. It rarely shows up on an org chart, and it almost never appears in a budget line. It shows up in the quiet, correct assumption that if this one person went on vacation for two weeks, three processes would slow down and at least one would break.
Why the Obvious Response Doesn't Work
The instinctive response to this pattern is to protect the person carrying it. Give them a raise. Give them a title. Hire someone to help them. Write down what they know so the risk feels smaller.
Each of those responses treats the symptom as the problem. None of them touches the actual issue, which is that a piece of the business is running on a person instead of a system. Hiring a second person to help does not eliminate the manual coordination. It doubles it, and now two people need to agree on the same undocumented judgment calls the first one was making alone. Writing down what they know produces a document that is stale within a quarter, because the underlying systems keep drifting further apart and the exceptions keep multiplying.
The deeper problem with all of these responses is that they accept the premise that this work has to be done by a person at all. In most cases, it doesn't. It exists because two systems were never integrated, because a workflow was never automated, or because ownership of a cross-functional process was never assigned to anyone accountable for the whole thing rather than just their piece of it. The work is not evidence that the company needs more people like this one. It is evidence that the company needs less of this kind of work.
The Real Cost Isn't Visible on the P&L
Human Middleware is expensive in ways that don't show up cleanly in a financial statement. The most capable people in an organization are the ones most likely to become the connective tissue holding a broken process together, precisely because they're the ones trusted to get it right. That means the organization's best judgment is being spent reconciling spreadsheets and chasing down status updates instead of solving the problems that judgment was actually hired to solve.
There is also a continuity risk that most leadership teams underestimate until it's too late. Every hour a critical process depends on one person's memory is an hour the organization is not designing that process to survive its own growth. When that person leaves, is promoted, or simply takes a real vacation, leadership discovers how much operational knowledge existed nowhere except in someone's head. What looked like resilience turns out to have been fragility with a friendly face.
None of this is a criticism of the employees carrying this load. In nearly every case, they are doing exactly what a good employee should do: noticing a gap and closing it so the business keeps running. The failure belongs to the operating model that required them to, not to the person who stepped up.
A Different Question to Ask
The organizations that eventually solve this problem stop asking how to support the person holding a broken process together and start asking why the process requires a person to hold it together in the first place. That is a different question, and it leads somewhere different. It leads to redesigning the workflow so the two systems talk to each other automatically. It leads to assigning clear ownership of the process end to end, rather than leaving it split across departments that each manage their own piece. It leads to using the automation and integration tools now available, cheaply enough that this kind of redesign is no longer a multi-year IT initiative, to remove the manual step entirely.
The goal is not to make the indispensable employee replaceable. It's to make them unnecessary in the specific role of human middleware, so their judgment, relationships, and experience can go toward the work only a person can do. That is a better use of talent than reconciliation, and it is a more durable way to run a business than hoping the one person who understands how everything fits together never leaves.
If there is someone in your organization who fits this description, the right response isn't gratitude alone. It's a serious look at why the business still needs them to play that role, and what it would take to make sure it doesn't.