Becoming a Better Problem-Solver

This subject gave you tools — decomposition, root cause analysis, systems thinking, creative generation, design thinking, working under constraints. The skill this capstone adds is knowing which to reach for, and when. A tool applied to the wrong kind of problem does not just fail; it burns the time you needed for the approach that would have worked.

Most real problems do not announce their type. Part of the work is deciding, early and provisionally, whether you face something tame (well-defined, one known method), complex (many interacting parts, no single fix), or wicked (contested even in how it is defined). Get that reading roughly right and everything downstream becomes easier.

Match the approach to the problem type

A tame problem has a clear goal and a known method — follow the procedure. A complex problem has many parts that interact; here systems thinking and small, reversible experiments beat any single grand solution. A wicked problem is contested at the level of its own definition, with stakeholders disagreeing on what the problem even is; for those, design thinking and repeated reframing matter more than optimisation. The classification is provisional — revise it as you learn more.

Zoom in, zoom out

Root cause analysis zooms in: it asks why a specific failure happened and refuses to stop at the first plausible answer. Systems thinking zooms out: it asks what structure keeps producing failures like this one. Skilled solvers switch deliberately. Zoom in when a discrete thing broke and you need the mechanism; zoom out when the same problem keeps returning under different names. Staying stuck at one altitude is the common error.

Frame before you solve

A well-supported finding across problem-solving research is that experts spend proportionally more time understanding and framing a problem before generating solutions — and the time is not saved by rushing, it is lost. A well-framed problem narrows the search; a poorly framed one sends good methods after the wrong target.

A support team is drowning in tickets. Rushed, you hire more agents — treating it as tame. Reframed, you notice the same twenty questions recur: this is a complex problem in an interacting system of product confusion, missing documentation, and a screen that invites the error. Zoom in on the top recurring ticket for its root cause; zoom out to see the pattern; run one small experiment — rewrite the confusing screen — and measure whether that ticket category falls. Creativity supplies the options; rigour tells you which one actually moved the number.

Not every problem deserves this machinery. A payroll run failed because a date was typed wrong — that is tame. Convening a systems workshop and running a design sprint on it would be absurd. Matching approach to problem type cuts both ways: over-thinking a simple problem wastes exactly the judgement a hard one needs. The habit is diagnosis, not always escalation.

After an oxygen tank ruptured on 13 April 1970, the three-man Apollo 13 crew shut down the damaged Command Module and used the Lunar Module as a lifeboat. But the Lunar Module was built to remove carbon dioxide for two people for about two days, not three for four, and CO2 began climbing toward dangerous levels. The Command Module carried spare lithium-hydroxide scrubber canisters, but they were square, while the Lunar Module's system took round ones — they did not fit. On the ground, a team led by engineer Ed Smylie worked out how to adapt the square canisters using only what the crew already had aboard: plastic bags, cardboard from a flight manual, a spacesuit hose, and tape. They tested the fix, radioed up the procedure, the crew built the improvised device, and CO2 fell. The crew returned safely on 17 April 1970.

What makes it a capstone example is that it combined every theme at once: a precisely framed problem (CO2 must fall, using only what is aboard), a hard constraint (no new parts), root-cause clarity (a wrong-shaped canister), a systems view (survival depended jointly on power, water, CO2, and trajectory), and disciplined creativity (a tested procedure, not a guess). The episode is documented in NASA's mission records and the official Apollo 13 review board report.

• "There is one best problem-solving method." No — the best method depends on the problem's type.
• "Framing is procrastination." Time spent understanding a problem is the cheapest time in the whole process.
• "Creativity and rigour are opposites." They are a sequence: generate freely, then test hard.
• "Zooming out is always deeper." Sometimes the answer is one root cause, and system-level talk is avoidance.

Take three problems you currently face. For each, label it tame, complex, or wicked; decide whether it needs zooming in or zooming out; and write the single framing sentence you would test first. Notice how often your first label turns out to be wrong.

Think Like a Maester: Before reaching for a method, spend the first and most valuable minutes deciding what kind of problem you are actually holding.

1. What distinguishes a wicked problem from a merely complex one?
2. When should you zoom in to a root cause rather than out to the system?
3. What does the research on expert problem-solvers say about time spent framing?
4. Why can matching approach to problem type mean doing less, not more?
5. In Apollo 13's scrubber fix, which constraint shaped the whole solution?

Becoming a better problem-solver is not learning one more technique; it is learning to read the problem first — tame, complex, or wicked — and then choosing deliberately: zoom in for a mechanism, zoom out for a pattern, generate creatively, and test rigorously. Frame before you solve, stay flexible about your first diagnosis, and practise until the diagnosis itself becomes the habit.

• Continuous Improvement
• Problem Solving & Decision Making