Pseudo-random thoughts (includes stereotypes that are 3dB over the top. Put on -3dB glasses to read the realistic version):
1. There is a tendency for managers on software or electronics-heavy projects to have Mechanical Engineering backgrounds, not Electrical or Software Engineering backgrounds. This seems to come from that there is always more electrical and software work to do, as it proceeds at O(n2), but the brackets and boxes tend to get done at O(nlog(n)). The respective engineers eventually tend towards estimating projects the same way, which is why software engineers get in trouble from management for always making estimates that are well beyond what a mechanical engineer-manager will come up with. Mechanical engineers, tending to be the ones who played sports in school, are naturally more assertive while the chess-playing software engineers slink back to their cubes to put in even more 10-hour days while the managers go golfing.
2. Compared to certain other professions, in engineering almost by definition the task is always in a state of failure, incomplete, and broken. Not everyone can work like that for days, weeks, months, years, and decades on end. Once the project in finished, it dissipates away, to come back either in another state of failure, or as the cracked foundation upon which to build the next task. Meanwhile the salesman says, "Ship It!", and takes credit for the successes of the product, while engineering gets the blame for the failures.
3. Unknown and not understood by many is the distinction between Product Development and Technology Development. Similar to the issues above, Product Development may proceed at O(nlog(n)), while Technology Development may proceed at O(n2), O(n3), O(n!), etc. Which category a particular task falls in can be very difficult to determine early on, if one is even lucky enough to have that awareness to see it. Usually such things are completely missed, so the problem instead appears in the form of slipping schedules, multiplying budgets, and cascading problems.