The problem with this way of thinking is that it basically absolves everyone of blame. Bad stuff happens and nobody's at fault. You point to the managers, because the engineers were so busy, but the managers are going to claim they were busy too. Again, from the manager's perspective - the managers aren't even in a position to understand the problem or the reasons for it.

Having been on both sides of this (as a developer and later a senior manager with product/feature responsibility), I'd say it can be both. A really good manager/executive has enough knowledge and experience to ask the right questions and parse the answers even when they are technical. Sadly, many managers aren't that good (at least yet).

On the other side, a really good developer has the knowledge and experience to frame the problem in an understandable business context when communicating the issue and options to management. Some of the best work experiences I've ever had were in orgs with such experienced developers and managers. Working together we were often able to solve apparently intractable problems with creative options which would never have been conceived absent the clarity of thought and communication on both sides.

This thinking implies nothing is worth doing unless it has a clearly articulable direct business value whereas a lot of technical debt simply doesn't. When the only people affected by a problem are people who have already spent their money or people who have no autonomy it's unlikely the decision makers will decide to investigate and fix it. If you're lucky you can convince decision makers that there is an impact to hiring or efficiency but in my experience these arguments are extremely challenging to make in the face of other stuff that decision makers feel directly impact business, and for good reason. I'd say this is a big reason autonomy is crucial when it comes to cultivating a curious team because without autonomy you are limited to things that can achieve consensus in an environment where people inherently have different interests to attend to.

I feel like the "20% time" paradigm where one day out of the week is left up to the developer to schedule (within reason) is the right way to balance the conflicts of interest and still leave room for people to be curious.

"the managers aren't even in a position to understand the problem or the reasons for it." Which is again the fault of management. It is the responsibility of management to facilitate proper management.

As a shareholder, I’d be rather happy with the management of GTA - it’s phenomenally profitable. That sounds like proper management to me.

You're pretty quick to act like there is a lot of blame to be allocated, but GTA 5 is arguably the most successful game in history. With games that truly have technical problems so bad they ruin the game, people don't complain - they just don't play it.

Maybe a long load time just wasn't that important for the success of GTA.

It wasn’t my intention to blame engineers but I agree with the other reply to you, someone needs to be responsible for creating these environments. It’s not like we’re dealing with fundamental forces of nature here, this is all self afflicted.