---
title: "Every company has a technology problem it hasn't found yet"
author: "Jeferson Guardezi"
date: "2026-11-01T01:33:03.054Z"
updated: "2026-11-01T01:33:03.333Z"
lang: "en"
pillar: "Business"
canonical: "https://guardezi.com/en/writing/every-company-has-a-technology-problem-it-hasnt-found-yet"
translations:
  en: "https://guardezi.com/en/writing/every-company-has-a-technology-problem-it-hasnt-found-yet"
  pt-BR: "https://guardezi.com/pt/writing/toda-empresa-tem-um-problema-de-tecnologia-que-ainda-nao-encontrou"
---

# 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.

![Diagram comparing two paths. On the left, "named": someone describes it, it gets an estimate, competes for priority, gets an owner and a date — ending in "shipped or refused", both recorded decisions. On the right, "unnamed": someone works around it, the workaround becomes routine, the routine becomes structure, and it becomes "how we work" — ending in "paid every month, forever", in payroll rather than on a budget line.](https://guardezi.com/api/media/posts/technology-problem-not-found-yet/problema-com-nome-en/1600.webp)
*The same problem, named and unnamed. The difference is not effort — it is whether a decision exists.*

## 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.