The Drawer is a Mess

A good deal of what we call “work” in tech swings between the concrete and the abstract. The engineer who routes a PCB or codes a software driver is doing a rather concrete task. The results of their work are quite visual, and problems are in general well-defined (although not necessarily easy to solve).
In contrast, a manager who discusses plans and strategies, well, does not enjoy such concreteness. In such roles, the fuzziness of the topics makes it rather hard to jump into action as concretely as an engineer writing a line of code. The path to implementation is not as tangible.

In both cases—in the concrete life of the engineer and the abstract life of the manager—they deal with problems. A problem is not always necessarily a bad thing: it is simply something that must be sorted out.

For solving problems, the engineer may apply a simple FIFO (first-in-first-out) approach: the first problem needs to be solved before the next problem can be tackled. Rarely a design engineer will let too many problems pile up before feeling their life has just gone out of control. They might even define a schedule to determine when and how a problem will be addressed. For instance, a software engineer will input bugs in a system and chase them until they’re solved.
Managers behave rather differently. Because of the fuzzy nature of the things they deal with, it is common for them to continue collecting problems as they go. What is more, managers collect networks of problems that are often related one way or another.

Russell Ackoff stated ages ago that managers are never confronted with problems that are independent of each other, but with situations that consist of complex systems of evolving problems that interact with each other. Ackoff calls those situations messes. Problems are just abstractions extracted from messes; problems are to messes what atoms are to tables. Managers do not solve problems, they manage messes.
I think the definition is on point. Managers go around with their virtual baskets collecting problems, and they don't go the FIFO way but more a last-in-first-out (LIFO) way. They pile them up and treat them the same way we pick socks from a drawer. Only the last, freshest ones might get attention for as long as there isn’t a new problem coming in to push the current problem(s) down the pile. I tend to rotate the same 3 or 4 pairs of socks because I rarely feel like diving into the drawer every morning to give democratic rotation to all my socks. The same way managers behave. They can’t keep too many problems in their minds, so they only pay attention to the 3 or 4 more pressing ones. The rest? Down the drawer.
When pointing out problems to managers, you don’t get any “tracking” system like software bugs do; no ticket number, no schedule for completion, or status. All you get is a promise of a solution that will largely depend on their capacity to remember it as the next thing comes their way.