Problem Solving

The most expensive mistake in problem-solving is fixing the wrong thing. A manager sees productivity dropping and orders longer hours, but the real cause was a noisy new open-plan office nobody can concentrate in. Longer hours in a louder room just make it worse.

What went wrong is confusing the symptom (low output) with the problem (broken working conditions). Treating symptoms feels productive and quietly wastes everything you pour into it.

The cure is a stubborn habit: before you solve anything, ask what's actually wrong underneath.

A simple tool digs from symptom to root: keep asking "why?" a handful of times, each answer feeding the next question.

1. Productivity's down. Why? People are distracted.
2. Why? The office is too noisy to focus.
3. Why? We doubled the desk density.
4. Why? To cut costs.

Four whys in, the real problem surfaces: a cost-cutting move wrecked the conditions people need to work. Now the useful solutions appear: quiet zones, headphones, remote days, rethinking the savings. None of which "work harder" would ever have reached.

It's also worth defining what "solved" looks like in concrete terms: not "improve morale" but "lift the satisfaction score from 6.2 to 7.0," so you'll actually know when you're done.

A huge problem is paralyzing precisely because it's one big lump. The move is to break it into sub-problems small enough to grab. "How do we reduce defects?" splits into: catch them earlier, train workers better, upgrade the equipment, standardize the process.

Laying these out as branches off the main problem does two things: it shows which pieces are independent (solvable on their own) and which are tangled together. Independent pieces can be handed off and solved in parallel, which is far faster than wrestling the whole knot at once.

It also surfaces your constraints, such as budget, time, tech, and rules, and constraints are useful, because a problem that looks impossible often becomes easy the moment you see which limit to relax.

With the problem clear, generate options widely, using brainstorming and the lateral moves from earlier, then judge them against your success criteria. Which actually hit the root cause? Which are feasible? Which carry side effects you can live with?

A quick grid helps you sort: rate each option on impact (how much it solves the problem) against effort (what it costs). The high-impact, low-effort ideas are the quick wins. They go first, they build momentum, and they often teach you something. Big-impact, big-effort ideas may be worth it but need real planning, and low-impact ones drop down the list. For anything major, run a pre-mortem first: imagine it failed, and ask why, before you commit the resources.

A plan on paper isn't a solution. Implementation is. And the smartest way to implement something uncertain is to start small: pilot it with one team, one region, or one week, before you roll it out everywhere.

A pilot surfaces the practical snags that no amount of planning predicts. The workflow that breaks, the step people skip, the assumption that was quietly wrong. Far better to hit those on a small scale, where they're cheap to fix, than to discover them after a full, expensive rollout. Learn from the pilot, adjust, then scale.

Once a solution's running, keep measuring it against the concrete success criteria you set. Getting closer to the goal? If not, diagnose honestly: wrong assumption, weak execution, or a fix that never touched the root cause?

And when it's done, do the part everyone skips. Look back. What worked better than expected? What underperformed? What would you change next time? That review is what turns one solved problem into sharper instincts for the next one; skip it and you'll just repeat the same fumbles on a fresh problem.