True, but if your company's product is, for example, software - and that software company is being run by someone with a legal, financial, hardware, operations, or non-software engineering background, the problem is much more difficult. And that's what I'm seeing. First the engineers need to be able to think in terms of business objectives (one of the best courses I ever had was a grad course in "engineering economics"). But second, the management community (starting with the business schools) need to figure out how to train CxOs that actually -understand the business they're in-.
For the last 30+ years, I've been in the large scale systems business. Most, but not all of that has been on projects for the US DoD. I've been appalled by the number of senior executives, military/government, large industry, small industry, who fundamentally don't understand software-intensive systems. As my earlier post said, their software experience is encapsulated in some small-scale programming task, rather than in large scale software engineering. On the one hand, they expect software to perform miracles because "it's software, you can change it," while on the other hand they refuse to invest in software. For the former, the best quote is from a former co-worker, "The software engineer is the system engineer of last resort."
I'm reminded of a system I once reviewed where they had a 'software problem'. But it turned out they had a -networking problem-. They were trying to move large volumes of images over a 10BaseT ethernet connection, and wondered why they weren't getting system throughput. Their ethernet was usually well over 50% loaded and couldn't handle the data. But they expected the software to 'fix' this.