I'd suggest some general "business strategy" works that will help you understand the context of how/why the very highest level business decisions are made, as well as some works that deal with tying together strategy and tactical execution (which includes technical initiatives).
1. Understanding Michael Porter - John Magretta. http://www.amazon.com/Understanding-Michael-Porter-Essential...
Porter's framework is VERY influential in the business world, and having at least a passing familiarity with his work is important at the higher levels. Going straight to the primary sources (Porter's books) can be a bit daunting as they are big, dry, and academic and not exactly what you'd call "page turners". This book is a fairly solid overview of the key elements of Porter's approach, and a good read before diving into the meat of Porter's works.
2. Competitive Strategy - Michael Porter. http://www.amazon.com/Competitive-Strategy-Techniques-Indust...
3. Competitive Advantage - Michael Porter. http://www.amazon.com/Competitive-Advantage-Creating-Sustain...
4. On Competition - Michael Porter. http://www.amazon.com/On-Competition-Updated-Expanded-Editio...
5. Good Strategy, Bad Strategy - Richard Rumelt. http://www.amazon.com/Good-Strategy-Bad-Difference-Matters/d...
6. Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne. http://www.amazon.com/Blue-Ocean-Strategy-Uncontested-Compet... This book has its critics, but I think it's a worthwhile read. Some people argue against the whole idea of a "blu e ocean" market, but even if the authors aren't 100% right about everything, I think the lines of thinking this book fosters are valuable in a general sense.
7. The Discipline of Market Leaders. http://www.amazon.com/Discipline-Market-Leaders-Customers-Do... I think very highly of this book and the author's approach to strategy. It's not radically different from the Porterian approach in some ways, but I'd say it's narrower in focus and simpler. The big takeway is the idea (which should be obvious, but often isn't) that "you can't be everything to everyone". The authors push a model of choosing a market discipline to appeal to a certain type of customer, and making that discipline the core of your business.
8. The Machine That Changed The World. http://www.amazon.com/Machine-That-Changed-World-Revolutioni... Have you ever wondered what this "lean" stuff is all about? Or why Toyota is so revered by business leaders? Here's a good place to find the answer to those questions.
9. Working Knowledge- Davenport and Prusak. http://www.amazon.com/Working-Knowledge-Thomas-H-Davenport/d... Perhaps the seminal book on Knowledge Management, or at least one of them. If you want to understand the importance of knowledge in an organization, this is a very valuable read.
10. Outside Innovation - Patricia Seybold. http://www.amazon.com/Outside-Innovation-Customers-Co-Design...
11. The Future of Competition. http://www.amazon.com/Future-Competition-Co-Creating-Unique-...
12. The Balanced Scorecard. http://www.amazon.com/Balanced-Scorecard-Translating-Strateg...
13. Strategy Maps. http://www.amazon.com/Strategy-Maps-Converting-Intangible-Ta...
14. The Strategy Focused Organization. http://www.amazon.com/Strategy-Focused-Organization-Scorecar...
15. If Only We Knew What We Know. http://www.amazon.com/Only-Knew-What-Know-Knowledge/dp/14516... Another seminal title in the Knowledge Management world.
16. Common Knowledge - Nancy Dixon. http://www.amazon.com/Common-Knowledge-Companies-Thrive-Shar... Another seminal title in the Knowledge Management world.
17. Winning The Knowledge Transfer Race. http://www.amazon.com/Winning-Knowledge-Transfer-Michael-Eng...
Let me suggest that your sarcasm is misplaced. My guess is that you have never worked on a multidisciplinary product that, in the event of failure, can kill people or one that has to be manufactured in thousands to millions of units per year. Not to minimize your experience, but software engineering is vastly different from designing, assembling and testing complex electromechanical systems.
I am speaking from the vantage point of having extensive experience engineering all aspects of multidisciplinary products during my career. From raw sheet metal through machined parts and injection molding. From analog electronics design to complex multi-gigahertz FPGA's. And, of course, software in embedded, mobile, web, custom real-time OS and workstation. Let's just say I've made enough mistakes in each field to have a reasonable understanding of their respective domains.
Also worth noting: DFM is only ONE of the the long list of relevant disciplines at play. The fact that I focused on DFM on my prior post does not mean that DFM alone is the solution to this problem.
Software is different in a number of ways. For one thing, in the software world you don't hand pieces of the product to a non-programming workforce for final assembly. The analogy here would be that you write code that instantiates a thousand different independent objects and then hand those over to an assembly team to "wire" together and manufacture the final product. That, of course, isn't the way it is done. In software development the product is typically designed, engineered, assembled and tested by one or many software engineers. In some cases, such as games, a multidisciplinary team assembles and tests the product. However, at no time are people unskilled in software engineering touching the very code that makes the product work. With electromechanical products your assembly crew quite literally has their hands in the guts of the product. Very different scenarios.
It might be a good mental exercise to think of the hypothetical scenario I painted. Imagine your job was to write code that instantiated a complex object and this object was to be integrated into a finished product by a technician who is not a software engineer. Would you blame the technician if the object was wired into the product with method arguments flipped around and property assignments inverted? You should not. In such a ridiculous hypothetical case it would be your job to ensure that this mythical object cannot be integrated into the greater operating code but one way and that all other options are covered and detected during testing.
Of course this is an imperfect and ridiculous analogy, don't waste any time lost in the minutiae to dissect it. The point is to highlight that software development cannot be directly compared to the process of designing and manufacturing a complex multidisciplinary product.
In typical large scale electromechanical projects from a toaster to a TV set, a car or a rocket there are have dozens to thousands of people involved, each with their own domain. For example, one of my acquaintances was the chief engineer for the F-18 fighter project. He had 3,000 engineers working under him. At the other extreme, I know multiple one or two person teams.
In most cases manufacturing is a discipline in and of itself, one where process and tooling are also engineering projects. If you've watched any of the "How it's made" shows you have probably seen how much special-purpose (and sometimes unique and custom) equipment is required for even the seemingly simple products. Example: Aircraft, mechanical and electronic engineers design a wing. Manufacturing engineers design the fixtures and tooling necessary to make the wing. They often work together in a feedback loop in order to integrate manufacturing concerns into the wing design.
The job of the manufacturing engineering team is to ensure that a reasonably skilled workforce can put out a quality product with consistency. However, a good portion of what happens during manufacturing is determined and decided upon during the design phase. Design often has to take into account manufacturing by integrating such things as reference marks, tooling points, easily accessible test connections, failure indicators (such as LED's), etc.
Aside from some corner cases it is of great value to treat all product quality issues as failures to engineer the product for optimal quality. By doing so one can ensure that the issue has a formal process through which the problem can be studied, analyzed and eliminated from future production. Yes, sometimes failure is required in order to discover what needs to be addressed. This also extends to operational issues. If, for example, users keep hitting the wrong buttons on a device it could very well mean that they are too small and spaced too closely, thereby increasing the probability of a user pressing one button when she meant to press one of the adjoining buttons.
Worth reading:
http://www.amazon.com/Machine-That-Changed-World-Revolutioni...
http://www.amazon.com/Poka-Yoke-Improving-Product-Quality-Pr...
Going back to the subject of this thread, I'd ask you to understand that the idea of designing mechanical assemblies for proper mating, indexing and alignment is, perhaps, at the core of mechanical engineering. For example, there are formal approaches to designing something like two mating parts, both with an array of holes that must align. Manufacturing tolerances are taken into account in order to allow for maximal and minimal errors at all bolt positions and, therefore, produce and assembly that will be easy to put together. The holes on one assembly are made slightly larger than on the other in order to allow for tolerances. Bolts are never used for indexing. If indexing is important, pins are added in order to guarantee alignment. Ignoring these design maxims means that, during manufacturing, someone has to use a manual reaming tool to enlarge holes in order to allow for the parts to go together and, perhaps, a hammer to adjust alignment. This is a failure of design, not a failure of the assembly worker. Mechanical engineers are trained to understand these issues and, unless they are complete morons, should and do work these constraints into their designs.
When it comes to the idea of a mission critical sensor designed into an assembly to be integrated into a rocket by a technician, well, there really is no excuse. This is basic engineering. You consider manufacturing and operational failure modes and seek to eliminate or reduce the probability of running into them. I don't know what these Russian modules look like. I'll just say that in a lot of cases a simple $0.25 alignment pin or an almost trivial machined or sheet-metal feature can ensure that an assembly is never mounted upside-down. There's absolutely no excuse for an engineer to design a critical sensor assembly that can be mounted in any orientation other than that which is required for the proper and safe operation of the system.
The Machine that Changed the World
https://www.amazon.com/Machine-That-Changed-World-Revolution...
Toyota Production System Beyond Large Scale
https://www.amazon.com/Toyota-Production-System-Beyond-Large...
The Toyota Way
https://www.amazon.com/Toyota-Way-Management-Principles-Manu...
Out of the Crisis
https://www.amazon.com/Out-Crisis-W-Edwards-Deming/dp/091137...