I do disagree. The primary responsibility of the manager is to manage and to manage they need to understand the process. The problem is that managers very often do not understand the software engineering field particularly well at all. I've seen it a thousand times that both large and small issues are simply ignored by managers, because they either do not understand them or even if they manage to grasp something, they fail to understand that they need to actively do something about it or just plain out ignore the issue, either with wishful thinking or just a power move where they think the issue isn't theirs to solve and in fact that the issue lies on the engineer to resolve. Most engineers are highly logical and would not bring something up without good reasons. It will have a negative impact if not handled.

I do not manage like this myself and I do not blame my engineers for anything that sits on my head, but I learned these lessons painstakingly through 15+ years of professional coding myself, seeing all kinds of roles at all kinds of companies creating chaos, project managers, product managers, bad managers, bad manager's managers, etc, but also the good ones luckily, the ones that were respected, knew what they were talking about, won the hearts of engineers, etc. This is what I modelled my own path after.

> They almost never reflect on the time they’ve wasted or how they don’t really understand the goals or users for the software they are responsible for.

I think the quoted statement tends to be a systematic issue on struggling projects that describes the decision makers, regardless of role.

I'm not sure how anybody can expect other outcomes than a few lucky successes and a lot of failures when understanding why you are building something seems to be undervalued by management, technical or other.