The workflow you inherited

At a mid-sized online retailer in Sheffield, any refund above £150 requires sign-off from two people in the operations team before it can be processed. Nobody who works there today can tell you why. The closest anyone got, during an internal audit last year, was a vague memory that “there was some trouble with a supplier return a few years back.” The rule itself was precise: two signatures, £150 threshold, no exceptions. Its origin had dissolved entirely into the company. The people who wrote it were gone. The incident it was guarding against was forgotten. The process remained, running quietly, slowing down a small but steady stream of customer interactions, absorbing a few minutes of two people’s days, every single week.

That rule was not written by the company. It was written by a situation, in 2019, by somebody who has since left. What remained was the solution without the problem.

01 · InheritanceThe decisions nobody made

Processes do not usually get designed. They accrete. A decision gets made in response to a specific problem: a customer complaint, a near-miss with compliance, an awkward conversation at a board meeting. Someone adds a step. Someone else inherits the step without inheriting the context. The step becomes the default. The default becomes the policy. By the time anyone calls it a workflow, it has already been running for years.

This is not unique to small companies or badly run ones. The logistics firm in Bristol we spent time with had a distribution-approval process that required physical initials on a printed sheet before any order above a certain weight could leave the warehouse. The weight threshold dated back to a carrier contract from 2017, with a carrier they no longer used. The initials requirement dated back to an insurance condition from 2016, with an insurer they had switched away from in 2020. The form itself had been redesigned twice since then, but both of those original constraints had survived every redesign, absorbed into the process as unquestioned background. Two people initialled that form every working day, for reasons that had ceased to exist four years earlier.

The cost, in isolation, was modest. A few minutes, twice a day. Across a year, it was closer to forty hours. Across the decade the condition had been running, it was a week of work, per person, doing something that no longer served any purpose. And that was a single step in a single workflow, at a single company. Most operations teams have dozens of these.

The insidious thing is not the cost; it is the invisibility. From the outside, a process that is running looks like a process that is working. The two are not the same. A workflow that runs smoothly but serves no purpose is still a cost. A rule that nobody has questioned is still a constraint. The question “why do we do it this way?” is rarely asked of steps that have been running without incident. Incident-free is mistaken for correct.

There is also a social dimension that makes this harder to fix than it looks. Questioning an existing process implies, however faintly, that whoever last reviewed it missed something. Most people sense this and stay quiet. The step keeps running. Another quarter passes. The person who originally introduced it leaves, and the institutional knowledge of why leaves with them. By the time the question is finally asked, there is nothing to ask it of. The answer is simply: we have always done it this way.

“The most dangerous phrase in any operations team is not ‘this is broken.’ It is ‘this is fine.’ Fine means nobody is paying attention.”

— Field notes, Bristol logistics engagement, 2025

02 · CustodyWhat “ownership” actually looks like

Most process documentation, when it exists at all, includes an owner. A name, usually. Sometimes a role. In theory, this person is responsible for the process: they keep it current, they review it periodically, they raise issues when it stops working. In practice, process ownership is frequently a fiction, and quite often a polite one.

The documented owner tends to be the person who was most senior when the process was last written down, or the person who happened to volunteer in the meeting where ownership was discussed. Neither of these criteria has much to do with who understands the process, who depends on it, or who will notice first if something goes wrong. Operational knowledge and org-chart responsibility sit in different places, and the gap between them is where inherited processes go to survive indefinitely without scrutiny.

What real custody looks like is quieter and harder to see. At the Sheffield retailer, the person who genuinely owned the refund-approval process was a customer-experience coordinator who had been in her role for three years. She was not on the RACI. She had no formal authority over the process. But she was the one who knew the £150 threshold was arbitrary, she was the one who flagged it to her manager when it caused a problem, and she was the one who understood every edge case. When she left, the institutional memory of the process left with her. Her replacement inherited the rule without the reasoning.

This pattern replicates itself across most operations functions. The real custodian is the person who has absorbed enough context to know where the process creaks. They are usually mid-tenure: long enough in the seat to have encountered the edge cases, not so senior that the day-to-day has become invisible to them. They are rarely the person named on the process document. They are often the person everyone quietly rings when something does not work.

Identifying them is straightforward. Ask five people in a team who they would contact if a specific process broke in an unusual way. The name that comes up most often is the real custodian, regardless of what the documentation says. Once you know who they are, the second question matters just as much: what happens to the process if they leave next month?

· · ·

In the next article in this series, we look at the practical technique for mapping what is actually happening inside a workflow, as distinct from what the documentation says should happen. The gap between those two things is almost always larger than people expect, and it is the gap, not the documentation, that tells you where the real risk lives.