I don't know if it's the same with hardware, but my experience with software development has been that a great deal of time is wasted and delay caused by incorrect division of work.
Any time responsibility is split between people or groups in a way that causes one group to wait on another's output, or separates decisions about interacting parts, it has two effects. Projects take longer than they should, because what one group finishes languishes in a queue until the next group can pick it up, (e.g. prototype production to testing). Meetings held in an attempt to communicate what is needed, tie up people who could actually be doing work, if they knew what had to be done. Everybody spends a lot of time not achieving anything, rushing to overcome delays, reworking what was done badly because it was rushed, or just not what was really needed.
Some of this is what "Agile" methods attempt to address. Small groups, properly balanced teams, and short feedback cycles help. Reporting methods that don't create more work than they measure are important. too. (The Duke of Wellington made a relevant remark on the topic: see http://kevinstilley.com/bureaucracy-select-quotes/ )
I once worked for such a "marketing" company doing tech support and then management wanted to devlop its own products. We hired several engineering consultants and I was the project manager/test engineer. As we kept adding more projects, allof them fell behind and we switched gears whenever a customer screamed "where's my product?" Marketing then accused engineering (me) of deliberately delaying the projects in an effort to keep my job. That's the last thing I wanted to do, for I knew that completing a successful project was a better way to keep my job.
Management also didn't understand the need for things like test equipment and bought on price alone.
And of course, I still had to do the tech support for the other product line, products where were imported and sold under the company name.
I've worked in many environments during my career, roughly two-thirds of which were with companies that understood engineering and were willing to allow the engineers to make decisions.
It is the employers that describe themselves as "marketing companies" that seem, in my opinion, to have the most difficult time with engineers. The marketing companies that I have worked for have been very unbending regarding requirements, decisions, and schedules. The engineers were treated like robots that were expected to produce error-free results according to the schedule created by management. While at one of these marketing companies, when a product didn't meet sales expectations the engineering team was informed that we "had failed" and were expected to make it right so that sales would increase. The product met every requirement, including the ones that engineering had argued against or in need of improvement.
1) it repeats the mistakes of the past. For a ling time at large Japanese corporations there was an expectation that workers would not work 9 to 5, or even take their annual leave. This reached ridiculous levels where on top of a multi-hour commute workers were not meant to leave their desks, and when the bell rang at 5 pm no one moved, waiting until the 7pm "doors being locked" bell before stopping. This bred a culture of stretching the day's work to fit the hours ie not more productovoty but just longer hours.
2) how many really tough problems do you solve when you are not staring at them but instead you are doing something completely separate, like walking, reading a book, even sleeping? By working long hours you don't necessarily get to the solution any quicker and you do weaken yourself physically and mentally, and damage home life (which is after all what the work is meant to be paying for, isn't it?)
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...