Every company has a technology problem it hasn't found yet
The most expensive problems are the ones nobody has named — so they are paid in payroll, not on a budget line. How to look for them before they find you.
The expensive problems are rarely the ones on the roadmap. A roadmap is made of things someone managed to describe — and describing is exactly what has not yet happened to the problems that cost the most.
It is not that nobody saw them. It is that nobody named them.
What a name does
A named problem enters a system that knows what to do with it. It gets an estimate, it competes for priority against everything else, it gets an owner and a date. And it can be refused — someone looks at it and says "not this quarter". That is a legitimate outcome, and what matters is that it is recorded: there is a decision, with a date, that can be revisited when the cost changes.
An unnamed problem is never refused. It gets absorbed.
Absorbing looks free because it appears nowhere in the budget. It appears in payroll — in the hours of people the company already pays, doing something every month that nobody has called a problem. Same money, on a line where nobody looks.
Where they hide
In the spreadsheet that one person maintains. In the manual step everyone has stopped noticing. In the integration that works because someone restarts it.
What those three have in common is not that they are broken. The opposite: all three are working. Which is precisely why nobody reports them. A problem that gets solved every month does not look like a problem. It looks like the job.
Why standing still makes them worse
The bad part is not today's cost. It is that the cost gets organised.
The spreadsheet gains a second tab. The manual step gains a checklist. The restart gains a calendar reminder. Each of those adaptations makes the problem harder to see, because now it has a process — and harder to remove, because now people depend on that process.
The workaround becomes structure. Once that happens, removing the problem stops being an improvement and becomes an organisational change, which is a far more expensive conversation.
How to find them
Four questions that work better than asking for a list of problems — because nobody lists what they have stopped calling a problem:
- What do you do that you would be embarrassed to demo? Embarrassment is the most reliable signal there is. It means the person knows it is wrong and has stopped expecting it to change.
- Follow the workarounds. Each one is a receipt for a decision nobody consciously made. Someone, at some point, chose to absorb instead of fix — and the workaround is the record of it.
- Look at the last business day of the month. Whatever only happens under a deadline is where the manual steps hide the rest of the time.
- Ask who you would call if that person were on holiday. A single name in the answer is a problem wearing someone's name instead of its own.
Naming is most of the work
Naming does not fix the problem. What it does is bigger: it turns invisible cost into a budget line.
From there the problem can be estimated, prioritised, and refused. Refused especially — it is good for a lot of things to be refused, because refusing with the cost in view is management. What you cannot do is decide about something that has no name.
One practical test, before buying any system to fix something: check that the thing has a name and an owner. If it does not, you are not buying a solution. You are buying an answer to a problem the company has not admitted having — and it will keep paying for both.
