I can totally agree there are segments of the software industry where these issues exist more meaningfully, like in your experience. Internally to tech compani

I can totally agree there are segments of the software industry where these issues exist more meaningfully, like in your experience. Internally to tech companies though, I think this sort of thing is trumpeted around too much to try to shift the balance of decision making power away from engineers. Sometimes of course engineers are not the ones in the position to know all the relevant factors for decision making. But often they really are, and if they tell you we can’t over-promise to the customer on XYZ because our legacy code is reaching a critical failure state, it needs to be urgently believed and trusted, but most of the time is not. There’s often a fundamental incentive struggle between parties who get bonuses or commissions because of a binary outcome (closed the sale, shipped the feature, lost the customer, revenue less than the target), and people for whom the binary event translates into long-term service requirements (support the feature and backwards compatibility, deprioritize a critical version upgrade, grow support capacity without being granted more headcount, etc.). Ideally it should be based on situational evidence and technical details (both business tech and engineering tech), and hopefully not just generic principles (often invoked via confirmation bias or argument from authority) like in this article.