Missing that point that it's not a simple worker-bee relationship and doing it
is the job of the manager, not a fact about engineers.
What the manager should be doing is aligning the direction of higher-ups and developers. This takes being able to clearly understand and communicate interests and needs two-ways.
As an IC I've always been vocal about the technical needs of product or platform development as it grows and expands capabilities. There's no chance higher-ups would know these things without being exposed to situations as they develop. At the same time I have to learn about the longer-term product direction and how to sequence development, and in particular research that can uncover the unknown unknowns heading in that direction. I'm lucky to have access to information and background that lets me make good guesses. This is the kind of process that the manager should be creating and refining.
The problem is that too many 'technical' managers behave as middle managers, merely allocating developers to teams by skillset (or worse title Sr/Jr Frontend/Backend) to projects picked by product managers and let project managers try to make it work. Instead of remembering all those times as an engineer that a timely refactor would have saved the company so much money and pain and getting key ones 'in the books', they take the easy route agreeing with the hand that feeds and only aim to satisfy one side's requirements without trying to fully understand the other's.
