When Your Team Is Compensating for Your Systems

There is a specific stage a company reaches where the systems no longer fit the business, but nothing breaks. Orders still ship. Invoices still go out. Clients are still happy. From the outside it looks like the operation is working.

It is working because people are absorbing the difference. Someone maintains a spreadsheet the official system cannot produce. Someone remembers that this particular client is invoiced differently. Someone spends Friday afternoon reconciling two sources that should agree and don't. None of this appears on an org chart or in a budget line, which is exactly why it persists.

Competent teams are very good at this, and that is the trap. The better your people are, the longer a broken system can survive, and the more expensive it eventually is to unwind.

What compensation looks like

• The parallel spreadsheet. A file that exists because the real system cannot answer a question someone needs answered weekly.
• The knowledge that lives in one head. Which supplier tolerates a late order, which client always disputes the first invoice, which step can be skipped in a rush.
• The manual bridge. Someone exports from one system and imports into another, on a schedule, by hand.
• The reconciliation ritual. A recurring block of time spent making two numbers agree.
• The pre-emptive apology. Staff warning each other that a report is "probably not current."
• The unofficial channel. Decisions being made in a chat thread because the sanctioned tool is too slow to bother with.

Each of these is a person doing work a system should be doing. Individually they look like diligence. Collectively they are your operating cost.

Why it is invisible

Broken systems announce themselves. Ill-fitting systems do not, because the compensation is silent and the people doing it rarely frame it as a problem. Asked directly, they will describe it as "just how we do it" — because from their perspective it is not a workaround, it is the job.

The other reason it stays hidden: the compensating work is usually done by your most capable people, and capable people do not complain about work they can handle. You find out when one of them leaves.

Putting a cost on it

Pick one week and ask everyone a single question: what did you do this week that a properly configured system should have done for you?

Do not ask what is broken. That produces complaints about software preferences. Ask what they did that a system should have done, and you get a specific list of hours.

Then multiply. Six people averaging four hours a week of compensation is 24 hours weekly — around 1,100 hours a year, or roughly two-thirds of a full-time role you are already paying for, spread invisibly across your best staff. At a €35 fully loaded hourly cost, that is about €38,500 a year of capacity going into holding the operation together instead of moving it forward.

The direct cost is the smaller half. The larger half is what those hours would otherwise have produced.

The second cost: your systems stop reflecting reality

Once compensation is established, the official system contains a version of the business that is no longer true. That has consequences beyond wasted hours:

• Reports get checked against the spreadsheet before anyone trusts them, so decisions slow down
• A new hire learns the official process, then learns the real one, which is why onboarding takes months
• You cannot automate anything, because the actual process is undocumented and partly improvised
• Due diligence, if you ever go through it, surfaces all of this at the worst possible moment

What to do about it

The mistake is buying more software. New tools inherit the same undocumented exceptions and produce a new round of workarounds within a quarter.

The sequence that works is duller:

1. Write down what actually happens, exceptions included, from the people doing it — not the official process
2. Separate genuine complexity from accumulated habit. Some exceptions exist for real commercial reasons; others exist because someone once made a mistake and the workaround stayed
3. Decide which exceptions the system will support and which the business will stop making
4. Build or configure around the process you decided on, then retire the spreadsheet with an actual date

Step three is where the value is, and it is the step almost everyone skips. Automating a process you have not first simplified means paying to make your current inefficiency faster.

The signal that matters

The question worth asking at your next management meeting is not whether the systems work. It is: if the person who holds this together were unavailable for a month, what would stop?

If you can name the person, you have found the compensation. The system is not working — someone is working instead of it.

Related reading: Why Internal Tools Separate Good Companies From Great Ones and SaaS Subscriptions vs Custom Software: The Five-Year Math.