The Sum of the Parts
Key Points:
- Break complex problems into manageable pieces—but design the framework that brings them back together.
- Specialization creates depth; integration turns individual expertise into system-level performance.
- The same principle applies at the product, engineering, and organizational levels: boundaries are useful, walls are not.
Early in my career at a large corporate R&D organization, I led a public-private technology development program built around a simple idea: take a specific complex real-world system composed of many interacting components. First, model each component in the virtual world. Second, assemble those models into a virtual system. Third, exercise the real and virtual systems under the same conditions.
Does the model agree with the real system? More fundamentally, can we build and deploy an accurate virtual system based on real component performance? And can we use it to design, optimize, and de-risk the real system?
Our project was successful within its domain. The team demonstrated the approach in a technically challenging environment, and the methodology and lessons learned have enabled faster progress in many subsequent programs. It also serves as a valuable metaphor for technology development at higher levels: components versus systems; specialization versus integration.
The same dichotomy exists within engineering organizations. There are specialists: mechanical, electrical, chemical; hardware, controls, system design; and many others depending on the problem. Specialization is essential. It allows people to go deep and make progress. But, just as with the engineered system, the components must be integrated into the whole system. People naturally tend to concentrate on the problems they know best, find most interesting, or believe they own. Interactions with other domains are often not sufficiently explicit. Crucial problems fall between the cracks. Assumptions diverge. The problem begins when decomposition becomes isolation.
The answer is not less specialization. It is stronger, smarter integration. A good framework lets specialists go off and do their thing—but continuously brings their work back together to see whether the collection of those efforts will function as one system.
The same dichotomy exists again at the organizational level. Engineering is only one component. Around it are program management, business development, marketing, executives, customers, partners, and others. The technical system exists inside a commercial system, which exists inside a business. Technology development has to begin with what the customer actually needs. Technical excellence does not create value if it solves the wrong problem. Commercial strategy cannot succeed if it ignores technical constraints. Management cannot make good decisions when information is fragmented by organizational boundaries or important gaps remain. Stakeholders need to assess the whole, not just what they want to see. Boundaries are useful. Walls are not.
I have worked with many exceptional professionals on many exciting pieces of technology. Very often, the individual components were workable. The harder task was making sure all of the necessary pieces came together: closing gaps, resolving conflicting requirements, directing resources toward the real constraints, and turning excellent individual work into a system that delivers value.
That is true at the product level. It is true at the engineering level. It is true at the organizational level. In the end, the pieces are not judged separately. The system is.
— Cassandra
Adolph Menzel: Das Eisenwalzwerk - The Iron-Rolling Mill (1872-1875)
