Software engineering is different from other kinds of engineering

When a company's primary product is not software, but rather contains software as a sub-component of something larger such as a piece of hardware, I have found that the management, processes, and culture of such companies generally do not support innovative, high quality software development.  Some online internet services are similar, even though they are entirely enabled by software - since they aren't selling software, but rather a service, the support for innovation can be weak weak.

What happens at first, in such cultures, is that the software developers are left alone to figure out how to make things work, and they pull it off.  So management assumes that its approach in terms of management, processes, and culture must be working.  However, what inevitably happens is that things gradually, eventually start to fall apart in terms of productivity and quality.  At this point management often thrashes about trying various solutions to the problem that may be partly effective or not, not realizing that *it* in fact is the problem and that management is what needs to change.  Management's hubris in such a company can often get in their way of seeing themselves as the root cause.  This can create a morale problem for the software developers working in such an environment.

Management might try to bring in "process" in some form - importing processes from other organizations in the form of specification processes, project management tools, version control and configuration management systems, testing tools and procedures, and so on.  This can be helpful in some ways but isn't a silver bullet.

Management might try to bring in "culture" in some form - "Everyone show up at 8:00 am from now on and no more telecommuting even when you're working overtime," for example.  Yeah, that's going to go over well with software developers.  Not.

Management might try to bring in new management - a manager that supports upper management's values.  However, if management fundamentally does not understand or value software development, then it will bring in a manager with that philosophy and the result is that the manager will be a proxy for the culture and processes that management wants to inflict on its software engineers - "We just need someone to make them follow the process."  Yeah, developers will like that.  Not.

Managing a high quality team of productive software engineers is so fundamentally different from managing other kinds of engineers, it can lead to upper management's mistaken assumption that they can apply other engineering management practices and experience that, in the end, is not effective.