A very traditionalist view. Close to the mark, but also impractical. I manage a small but very cross-disciplinary R&D team (also hardware/electronics/software)

A very traditionalist view. Close to the mark, but also impractical. I manage a small but very cross-disciplinary R&D team (also hardware/electronics/software) and do not expect people to execute on all of those capabilities. It would surely be a great help if they could, but it's just unrealistic to find people who are that well rounded. I find that engineers are often domain-specific and their thinking may be clouded by a core or familiar domain. For example in cross-domain problems you'll often see software engineers who want to solve everything with a stack they're familiar with, mechanical engineers who reach directly for industrial automation components, and electronics engineers so stuck in high-cost-of-iteration or large production mentalities they are unable to operate in high-iteration modes with alternative tradeoffs. In general, I would say that: (1) engineering process management is a different discipline to most domains of engineering; (2) competency at generalist or cross-domain engineering is a relative rarity in those identifying as engineers; (3) R&D engineering is a different skillset (both engineering and management process wise) to production engineering (and the magnitude of these differences is often related to the fabrication/iteration processes and associated costs and timelines in the domain in question); (4) Engineers who excel at cross-disciplinary thinking and novel problems tend to be those without overly formal engineering backgrounds; (5) In some ways, all management is human process engineering, and it's simply unrealistic to expect all engineers to be effectively multi-domain.