In one line: Some problems are simple, some are random enough for statistics, and the hardest are in between: many interacting parts whose behavior emerges from their relationships. Those need different tools than the first two.
Core idea
In a 1948 essay, Warren Weaver [1] divided scientific problems into three kinds:
| Kind | Example | Tools that work |
|---|---|---|
| Problems of simplicity | a few variables: a planet’s orbit, a two-body collision | classical analysis, equations |
| Disorganized complexity | millions of variables acting randomly: gas molecules, insurance tables | statistics and probability |
| Organized complexity | a moderate number of variables interrelated into an organic whole: an economy, a living cell, a large engineered system | neither alone; it needs new methods, computing, and mixed interdisciplinary teams |
Weaver predicted that organized complexity would be the great challenge for science in the coming half century. Engineering has made it central. A more recent primer from the INCOSE working group on complex systems [2] translates the idea for systems engineers. It distinguishes complicated systems (many parts, but predictable from their design) from complex systems (behavior that emerges from interactions and adaptation, and can’t be fully predicted by analyzing the parts).
How it works
Signs that you are facing complexity, not just complication:
- Emergence: the whole does things no part does.
- Nonlinearity: small changes have outsized effects, or large ones have none.
- Feedback and adaptation: parts respond to each other and to the system’s own outputs.
- Sensitivity to history and context: the same action works once and fails the next time.
- Many stakeholders with different views of what the system is for.
Implications for engineering:
- Rely more on experiments, prototypes and iteration, and less on one-shot prediction.
- Design for resilience and adaptability, not just for optimal performance at one point.
- Use diverse teams and models to see the system from several sides.
- Keep monitoring and adjusting after deployment.
In practice
Engineers trained to decompose problems sometimes treat a complex problem as merely complicated: decompose, optimize each piece, reassemble. When the parts interact strongly, that fails in surprising ways. Examples include a system that passes every subsystem test but misbehaves when integrated, or an organization that optimizes each department and slows down overall. Recognizing which kind of problem you have is the first skill. Sense-making frameworks such as Cynefin, introduced in the design module (see Design Thinking), are built around exactly that question.
Questions to ask yourself
- Is my current problem simple, statistical, or organized complexity?
- Where might the interactions between parts matter more than the parts themselves?
- What experiment would teach us more than another round of analysis?
Connections
- Extreme case: Wicked Problems. Tools: Thinking in Systems, Systems Engineering, Design Thinking.
- Consequence for products: Reliability.
- Capabilities exercised: Inquiry, Connecting Across Disciplines, Decision Making.
Sources
- Weaver (1948) Science and Complexity [1]
- INCOSE (2016) A Complexity Primer for Systems Engineers [2]