These are all strawmen in most cases. Most businesses operate software systems that are perpetually at critical breaking points, riddled with tech debt, long-unfixed bugs that severely degrade quality and actively make customers unhappy but are not prioritized.<p>The business and product side always say things like not choosing projects based on technical challenge, but that’s so extremely far away from the case of reality that it’s just FUD to better politically control things.<p>Most engineers I have worked with are really clever generally and can quickly grok sales or business considerations at a higher level than the sales or business people can. They want to build things that customers care about and don’t need anyone from sales or product hierarchies to “make” them follow that priority. They only want to test new tech stack choices in careful, isolated ways, not betting the farm on a new toy.<p>These are basically made up, misunderstood myths that business people tell because they’re insecure that smart engineers are good enough to make both engineering and business decisions.<p>And the flip side failure mode, where engineers are raising alarms about serious tech debt issues or inflexibility / incapability to innovate, and business people dismiss the seriousness of the issues in a genuine business sense, is rampant.<p>As an engineer one of my most frustrating experiences is when, _after taking business concerns into account very carefully_, my expert opinion that the business outcome is at high risk of failure due to lack of engineering investment and basic quality focus is just dismissed because “I’m not a product person” or some similar bullshit self-preservation from soft-skilled people writing Powerpoints all day while dismissing the idea that engineers can learn the business (usually very quickly).