Problems without an owner.
The most expensive technical problems in an organization are often the ones no team owns. They are solved by being specified, not by being assigned.
Most organizations have a few problems that nobody owns, because they sit between one team's responsibility and another's. Everyone involved can describe the problem. Nobody's remit contains it.
These are rarely small. A problem that falls between two teams usually touches two systems, and the places where systems meet are where the difficulty tends to be. Nobody decided it did not matter. There is no natural place for it to land.
Ownership follows structure
Teams are given systems, functions, or products, and most problems sit inside one of those boundaries. That is how anything gets finished. But the boundaries are drawn around the parts, and some problems belong to the whole: a process that is correct at every step and wrong end to end, or a constraint one team can see and only another can act on. Nobody is at fault, and the problem has no obvious address.
Assigning it is not solving it
The usual response is to give it to someone. Sometimes that works. When it does not, the team now owns a problem it can only partly see, has to negotiate for access to the rest of it, and is measured on work that was already filling the week.
What was missing was a definition, not a name. Nobody has said what it would look like for the problem to be finished. Without that, effort goes to the visible parts and the rest stays where it was.
Specification creates ownership
The work that moves a problem like this happens before anything is built. Someone has to look at the whole of it, including the parts that are inconvenient to look at, and write down what is true. Then someone has to write down what a correct outcome would be, precisely enough that two people could agree on whether it had been reached.
That turns an ambient problem into a bounded one, and a bounded problem is something a team can own. The people doing the work can tell when they are done, and everyone else can disagree early, while disagreement is still cheap. It also outlasts the people involved: an understanding shared between two teams lasts until one of them reorganizes, and a decision written down in terms someone can check does not depend on either of them.
The cost of leaving it
Unowned problems are rarely urgent, which is why they last. They cost a little every week: a manual step someone absorbs, a check that happens because one person remembers to do it. Then something changes, a deadline or a departure, and the problem has to be solved on someone else's schedule. That is the most expensive moment to begin understanding a problem that was going to need understanding anyway.