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?)
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.
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 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/ )
There are just people out there that shouldn't be managers. Actually, let me rephrase. There are managers out that that us as engineers shouldn't take crap from and bother working for. I've learned enough that life's too short to be involved in bad work.
Scenario #1 - you're employed and have been looking elsewhere. The manager interested in having an interview should never call the person out of the blue if that person has an email address in the resume. If the manager is asking for basic things that are already in the resume, he has not taken the time to review it. This is a job you should not waste time persuing because that would be an idiot you'll need to deal with - unless you're out of work and need the money
Scenario #2 - Manager should be looking out for his/her team members. If you're in a meeting with other teams where the other team is reporting a problem with the project, don't start immediately putting blame at your own guys in front of other people without fully understanding the situation.
Scenario #3 - There are managers that solely care about numbers and bookings. They're pure sales weasels, not there to manage. Well, I guess 'manage' would be the appropriate term, since they're not there to 'lead'. In any case, they are ones that are so disconnected with technology, people that work for them, completely disregards effots that their team puts in, show no remorse when people from his team leaves. They're so high up in the food chain that they're most interested is how much commission they get from bookings.
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?
We've all come up with ideas when we're not staring at our work, but how much of our time is spent on "busy" work, the kind that has to be done but is monotonous, requiring no thought? We often need to longer hours just to do that.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.