The Permanent Workaround: Why Processes Built Around One Person's Judgment Never Survive That Person's Absence

Most organizations can point to at least one person who is, in the words of colleagues, irreplaceable. That description usually carries admiration, but it also signals something worth examining carefully. When a process works because a specific individual knows when to apply an exception, whom to call when the system produces a wrong answer, or how to read a situation that the written procedure does not quite fit, the organization has not mastered that process. It has delegated mastery to a single person and left the process itself incomplete.

This is the permanent workaround. It is not dramatic. It does not appear on any risk register. It rarely surfaces in audits because everything continues to function while the person remains in the role. The problem becomes visible only when that person is promoted, departs, takes extended leave, or simply becomes unavailable at a critical moment. At that point, organizations discover that what they believed was institutional capability was actually individual expertise, and the two are not interchangeable.

How Workarounds Become Infrastructure

Workarounds typically form at the edges of formal process design. A new system is implemented, but it does not handle a particular class of exception gracefully. Rather than revisiting the design, the team asks the most experienced person in the group to handle those cases manually. The exception volume is low enough that this feels like a reasonable solution.

Over time, the exception volume may stay low, but the judgment involved in handling those cases quietly grows more sophisticated. The individual accumulates context about customers, vendors, regulators, or internal stakeholders that makes their intervention fast and effective. Colleagues learn to route edge cases to them without thinking about it. The workaround becomes, in practice, a standard operating procedure that simply never got documented.

When this happens across multiple processes in an organization, the result is a hidden dependency graph. Senior leaders may have an accurate map of the formal org chart and the official process flows, but the actual operational network includes invisible load-bearing nodes: people whose judgment is woven into daily function in ways that no diagram captures.

Why the Risk Stays Hidden

The most capable people rarely raise this as a concern themselves. The work feels manageable to them. They may not fully appreciate how much contextual knowledge they have accumulated, because that knowledge feels like ordinary competence from the inside. They are also often busy enough that documenting their own judgment is not a natural priority.

Organizations, for their part, tend to measure process health by output quality rather than by process robustness. As long as the workaround produces acceptable results, there is no visible signal that something structural needs attention. The problem is that this metric is entirely dependent on one variable remaining constant, which is the continued availability of one person.

In addition, raising the issue can feel organizationally uncomfortable. Acknowledging that a critical process depends on a single individual implies that the organization has underinvested in process design, that leadership allowed a dependency to grow unchecked, and that the person in question holds more operational leverage than the structure formally intended. None of these observations are welcome ones, which makes the conversation easy to defer.

A Structural Approach to Identifying Hidden Dependencies

Organizations that want to locate these vulnerabilities before a departure forces the issue can conduct a structured dependency review. The review is not primarily about documentation, though documentation will result from it. It is about asking a specific operational question for each critical workflow: if the person currently responsible were unavailable for four weeks with no notice, what would break, what would slow materially, and what would continue without interruption?

The answers to those three categories reveal which processes have genuine institutional robustness and which have a single point of failure. Processes that would break or slow significantly despite documented procedures are good candidates for closer examination. The goal is to determine what knowledge, judgment, or relationship is actually doing the work that the formal procedure does not capture.

This review is more useful when conducted with peers rather than through self-report alone. A person's own assessment of their replaceability tends to be either overstated or understated depending on temperament. Colleagues who have had to cover responsibilities or who have watched handoffs fail are often better sources of information about where the real dependencies live.

Converting Judgment Into Transferable Process

Once a dependency is identified, the goal is not to eliminate judgment but to make it transferable. This usually requires a different kind of documentation than most organizations produce. Standard procedures describe what to do in the expected case. What is missing in most workarounds is documentation of how to recognize which case you are in, what conditions trigger the deviation, and what decision logic applies when the formal path does not fit.

A suggested approach is to have the knowledge holder walk through several real examples of the cases they handle, articulating out loud what they notice, what they weigh, and how they decide. A colleague who is not yet expert in the domain facilitates the conversation, because a novice is more likely to notice when the expert skips a step that feels obvious to them but is not obvious to someone learning the judgment for the first time.

The output of that conversation is not a rigid rule set but a richer decision framework that captures the conditions under which standard procedure applies, the signals that indicate an exception is warranted, and the reasoning logic that governs the exception itself. This kind of documentation is more cognitively demanding to produce than a standard procedure, but it is also more useful because it reflects how the work actually gets done.

Building Redundancy Without Creating Bureaucracy

Organizations sometimes resist this work because they assume that distributing judgment requires adding process overhead. That concern is worth taking seriously, but it conflates two different things. The goal is not to add approvals or checkpoints. The goal is to ensure that at least one other person can exercise the same judgment with comparable quality when the primary person is unavailable.

This is primarily a development investment, not a process investment. A second person learns alongside the primary, handles a share of the edge cases with review, and builds the contextual knowledge that makes their judgment reliable. The formal process need not change at all. The change is that the capability now exists in more than one place.

For senior leaders, the practical action is to treat single-person dependencies in critical processes with the same seriousness they give to single-vendor dependencies or single-system risks. The operational exposure is analogous. When one person's presence is what stands between an organization and a disrupted workflow, that is a structural condition worth resolving while there is still time to resolve it thoughtfully.