Too often managers of software teams fail to understand what the people under them do.
Managers of software people often do not understand what the people under them do. A company pilot who became president of the company I once worked for once said, "Software how hard can it be? You just type it in the computer!"
His concept of computers was based on the flight management computer. If he wanted to fly the plane to L.A. he just typed in KLAX into the flight management computer, which took care of the rest all the performance calculations, departure, en route, and arrival course corrections. It even checked in with ATC via a DATALINK (this was for a high-end business jet).
He had no clue that some engineer had to manually check each flight plan, do performance calculations and course correction methods on paper and in a simulator, as well as study reams of data from the ever-so-boring-and-uneventful test flights that the pilots flew.
Most managers who are not technical seem to have some misguided idea that working on the computer is like having a spelling checker in MS-Word helping you at every step, when in fact tools are rarely available to help add the extra margins to the design that make it robust. There is no automatic tool that will tell you your interrupt loading is sporadically too high.
Seldom will you find tools to tell you you've overwritten stack. If you're doing a project completely from scratch, few tools will help you get good estimates for RAM size on embedded projects (they usually require calibration on a few projects).
There are many other chronic problem areas in embedded development that are just plain areas of skill, experience, and taking the time to do the calculations, estimates, management education and prototypes.