There is a specific kind of operational drag that is almost invisible. It is not the process that breaks spectacularly on a Thursday afternoon and brings three people in early on Friday to fix it. It is the process that works. That has always worked. That will, as far as anyone can tell, keep working indefinitely.
The problem is not that it works. The problem is what it costs to work — and how much of that cost would disappear if someone took ten hours to look at how it was designed and when.
Most established businesses have at least one process I would call a legacy load. You know the kind. It was built when the business was a different size, in a different period, by someone who has probably left since. Nobody is quite sure why certain steps happen in the order they do. The person who does it now was trained by the person who did it before them. There is a spreadsheet involved. There is almost certainly a spreadsheet involved.
The illustrative situation I use when I explain this is a client reporting pack. It is not a specific engagement — it is an archetype I have seen enough times in enough variations to describe with some confidence.
Imagine a professional services firm — somewhere between 30 and 50 staff. They produce a monthly reporting pack for management: revenue by client, billable hours versus target, utilisation rates by team, a few operational metrics. It takes two and a half days every month to produce. One person does most of it, another cross-checks the numbers, a third contributes the project management section.
When the business was founded, this was entirely reasonable. There were twelve people. The data lived in three places. Two and a half days for a senior person to pull it together was expensive, but it was proportionate to what the report was worth.
The business is now 40 people. The data lives in six places. The report is longer, more complex, and expected by more stakeholders. The time to produce it has crept from two and a half days to three and a half. The cost of the three and a half days — in salaries, opportunity cost, and the management attention consumed reviewing it — is now roughly four times what it was when the business was 12 people.
The process has been working since 2018. It has never been revisited. And that working has become expensive.
Here is what I find when I ask about processes like this one: nobody disputes that there is a problem. The person who produces the report can tell you exactly where the time goes. The management team know the report takes “a while.” But there are always three reasons it has not been addressed.
The first is that it is not broken. It works. Every month, the pack goes out. There is no crisis. There is no moment of failure that forces the issue. The cost is invisible because it is regular and expected — it has been absorbed into what people think of as normal.
The second is that the person who does it is good at it. They know where the data is. They know what the exceptions look like. They know what to do when the project management system exports in a different format. That knowledge took time to accumulate. There is a quiet assumption that changing the process means losing the person’s expertise. It does not — but the assumption is real.
The third is that “redesigning the process” sounds like a project. A proper project, with scope and a plan and someone’s time. And the business is always a little too busy for a proper project right now.
The concept I use for this is operational debt. It is borrowed from software development, where technical debt describes the accumulated cost of decisions made quickly that accumulate over time and require progressively more effort to work around. Operational debt is the business equivalent: the cost that accrues when processes designed for one version of the business continue to run a larger, more complex version without revision.
The important thing about debt is that it compounds. A process designed for 12 people that runs a 40-person business is a larger mismatch every year the business grows. The cost does not stay at its 2018 level — it increases. And unlike financial debt, it does not appear on the balance sheet. It shows up instead in the utilisation rates of people doing things that did not need to be done that way, in the week before month-end when everyone is slightly less available than usual, in the new hire who spends their first two months learning the workarounds.
Industry benchmarks for professional services firms of 20 to 60 people typically suggest that between 15 and 25 per cent of operational capacity is absorbed by what I would classify as process-legacy overhead — work that exists because the process was designed for an earlier, simpler version of the business. The actual figure varies significantly. But when you sit with the people who do the work and ask them how much of their week they would describe as genuinely useful, the answers are consistent enough to suggest the benchmark is not implausible.
The fix is almost never a large project. The reporting pack example above is something I would expect to compress from three and a half days to half a day once the data connections are properly configured and the compilation steps are handled by the systems that already hold the data. The work involved in making that change is perhaps 20 hours — mostly configuration, some testing, a brief handover. The annualised saving, for that single process at a 40-person firm, is in the range of £35,000 to £50,000 depending on the seniority of the people involved. That is a calculation from the hours and the cost rate of the people doing them, not a projection.
It is also not the point of the exercise. The point is that a process running since 2018 is probably being run by a business that looks nothing like the 2018 version. And the gap between the process and the business it serves is not neutral. It has a number.
The question worth asking is not “how do we fix this?” It is “how long has this been costing us, and how much of that cost was recoverable?”