When Processes Outgrow the People Running Them

Why It Happens

That assumption does not hold up under examination. The migration did complete successfully. What happened instead is that the reconciliation process, in the course of running, began catching a small number of genuine exceptions each month — real discrepancies that would otherwise have gone unnoticed. Its original purpose ended, but a new purpose was found for it along the way, and nobody made an explicit decision to keep it running for that new reason. It simply continued, because stopping it required a decision that nothing forced anyone to make.

This is a distinct pattern from most process problems, and it is worth naming precisely because it does not fit the usual story of decay or neglect. Nothing about this process failed. Temporary work acquired a permanent justification without any decision being taken to make it permanent — the process outgrew the reason it was built for, quietly, by finding a new one to serve instead.

The reason this happens so consistently is structural rather than individual. Stopping a running process — even one whose stated purpose has ended — requires someone to notice it, understand what it is currently doing (as opposed to what it was originally built to do), and take a deliberate decision to end it. Continuing a running process requires nobody to do anything at all. Given that asymmetry, processes accumulate a permanent legacy far more easily than they get retired, regardless of whether their original purpose still holds. Nelson Repenning and John Sterman of the MIT Sloan School of Management, writing in California Management Review in 2001, describe the same default: under pressure, organisations tend to work harder at what is already running rather than deliberately review it.

This has a compounding effect across an organisation’s history that is easy to underestimate. Every project, migration, or temporary fix leaves behind some probability of generating exactly this kind of residue — a process that outlives its original reason by finding a new one. Individually, each instance looks minor: a small manual step here, a workaround there, none large enough to justify a dedicated review. Collected across years of organisational history, though, the aggregate becomes a meaningful and largely invisible portion of ongoing operational effort, sustained not because anyone decided it should be, but because nobody has ever been specifically tasked with asking whether it still should be.

A related misconception is worth naming directly: because the process in this example is now doing something genuinely useful — catching real exceptions — it is easy to conclude it must therefore be the right way to keep doing it. That does not follow. That the process is currently useful only establishes that the underlying need it now serves is real; it says nothing about whether a manual reconciliation, inherited from an unrelated migration years ago, is actually the best way to meet that need going forward. Those are two separate questions, and the process having quietly answered the second one by default, without anyone actually examining it, is precisely the pattern this article is describing.

This pattern also varies in a fairly consistent way by how visible the original justification was. Where the original, time-limited reason for a process was widely known and clearly communicated at the time — as in a migration announced to the whole organisation — the eventual gap between “why this started” and “why it continues” is usually easier to notice, once someone happens to ask, because enough people remember the original context to recognise that it no longer applies. Where the original reason was narrower or less visible — a fix introduced quietly by one team to solve its own immediate problem — the same gap can persist far longer, simply because fewer people ever knew the original justification well enough to notice it has expired.