Solve fewer problems

In business there are always more problems than you can solve — so the real skill isn't solving everything. It's choosing. On testing problems against your future, studying them before you touch them, and working them in strands.

It's one of the consistent uncomfortable truths of being in business: you are always solving problems. Every single day brings a fresh batch for you to tackle – some enormous, some trivial, some genuinely life-changing, some so small they take a simple conversation to solve. And there are always, always more of them than you could realistically hope to solve.

Which sounds rather bleak doesn't it? But it isn't, because it points straight at the real skill when it comes to problem solving. The job is not to solve more problems. It's to solve fewer, better ones – and to leave the rest well alone.

The whole art, and I call it an art because problem solving often defies precise mechanisms, is deciding which problems deserve your time, energy and attention, and which ones simply don't. Two tools do most of that heavy lifting for you: your strategy, and the painted picture of where you're headed – because once you can see the bright future clearly, the only problems worth your finite resources are the ones standing between where you are now and this bright future.

And of the problems that do make the cut, it's nearly always worthwhile getting to the root and pulling, cutting or digging the whole thing out, rather than trimming a few of its symptoms and declaring victory.

Get this right and you stop pouring your scarce time, energy and attention into solving symptoms and the wrong problems – the busywork that infests a great many organisations. Solve the right ones instead – usually the systemic ones that have been gathering friction for months or years – and you get something that busywork never delivers: genuine momentum.

Three tests before you spend a thing

I think it's only fair to suggest three specific tests before committing your money, time, energy and attention to any problem. They overlap a little with what's above, but they're worth the second look.

Only solve problems on the path to your bright future.
When the direction of a business, a function or a team is unclear, every problem takes on the smug air of urgency, and the whole thing starts to feel overwhelming – because anything might be the problem you need to address, and you can't quite tell which.

That's the fastest way there is to burn through your resources, and your team's, at a remarkable rate – and those should be protected fiercely. This is where the painted picture earns its effort: it gives you an orientation, and anything not on the road between where you stand now and that better place can be set aside with gusto.

If a problem keeps coming back, you haven't solved it.
However productive, fun and successful it felt at the time, if the thing – or one of its many symptoms – keeps returning to haunt you, it isn't solved, whatever you told yourself and the leadership team.

Recurring problems are almost always symptoms of something deeper: weak delegation, a broken process, a structural constraint, a cultural habit nobody's challenged, poor behaviour. Fixing the shiny symptoms feels brisk and satisfying and rather productive, but satisfaction isn't the point; a problem that doesn't come back is.

Solving things by halves is a wonderful way to stay busy and move almost nowhere.

If a problem is easy to solve, it's probably not the real one.
The interesting problems standing on your path are rarely the easy ones. They tend to be systemic – they cross functional boundaries, touch everyone, and have been loitering like someone up to not good for years – and they're hard for exactly that reason: cracking them takes cooperation, collaboration and coordination across functions, which is far more a political problem than a technical one.

That's also why they give so generously when you do crack them: the breakthrough and the momentum are proportional to the gnarliness. The circles of contribution help here, if you've built the skill to move through them.

Sometimes people like the problem

Here's the one that's less comfortable, and truer than anyone tends to let on. A problem, properly defined, is something with a cost that affects someone.

And that cost isn't only money – it's confusion, waste, depleted energy, the slow burden of something that doesn't work, a work-around, dullness, rework, lack of meaning. The operative words are "affects someone." A problem might cost you a great deal and barely register a beat to the person next to you – worth solving, still, just probably not systemic.

And sometimes – more often than I'd like to write here – people rather enjoy having a problem around. It keeps the attention of leaders fixed on the problem rather than on them. They've built a small kingdom around managing the problem. Or it happens to land on other people and not on them, so why hurry, or worry, or scurry to get it fixed?

It's insidious and a bit tragic and extremely real, and no amount of eloquently explaining the benefits of solving it will make the problem matter more to someone it doesn't touch or someone who needs it to remain a problem. So it persists. Which is one good reason leaders should be answerable for the design and health of the whole system of work, and not merely its results.

Study the problem before you touch it

To solve a problem you have, at the very least, to understand it. Problems deserve study before action – which sounds almost too obvious to write down, and is somehow desperately needed anyway. There are teams everywhere solving problems they've never actually understood, often by importing a framework someone used elsewhere, without knowing the problem's shape, or how they'd even tell whether it was solved.

So staple yourself to the problem. Watch it in the wild – in flow, in motion, in the act of generating its costs and affecting people. Gather the evidence for where and when and how it shows up. And the simplest, most effective move of all: talk to the people in the business and listen – they'll frequently tell you exactly what the problem is, why it's a problem, how they know, and how they'd fix it.

A remarkable share of my time helping companies get smoother at turning ideas into value is spent finding the people who are already trying to solve the problems on the path. They understand the shape of it far better than leadership ever will, even when they can't see the whole system – and the trick is simply to give them the air cover, the resources and the climate to get on with it.

You'll also, along the way, run into a great many strong opinions – firmly held, often with little evidence underneath them. Take those at face value and you'll generate impressively confident mistakes. It takes judgement, skill and a bit of taste to sift the real from the imagined. And yes, a few feathers will get ruffled; nobody promised this was tidy, easy or simple.

Gather the evidence. Question the assumptions. Resist the itch to act before you've learned. And try to understand someone's view deeply enough that you can challenge the assumption and opinion without challenging the person. Not easy – but that's rather the job when we think about it.

When you've gathered enough – not everything, because you never will – the next move is to name it.

Name it, and make it something you can point at

Vague, unnamed problems stay unsolved. Named ones become workable, at least in principle. Giving a problem a specific, honest description – a genuine name even – is one of the most underrated moves in all of business, because the naming strips away the cloudy cover that let it survive unexamined.

In workshops I like to take this a step further and turn problems into things you can physically hold. The method I use is the Vending Machine: every problem is built as a product in the machine – a name, a description, a glossy attractive visual, a slot of its own alongside all the others. People can reach in, pull one out, hold it, point at it, argue about it.

When you can touch a problem, it becomes discussable. The medium matters far less than the principle: posters, diagrams, named cards, a simple shared document – anything that lifts the problem out of people's heads and into a space where a group can see it, touch it, turn it over and discuss it honestly. And a useful tell falls out of it – if you can't describe the problem easily, I'd suggest you don't yet know it well enough.

One more thing, obvious and routinely skipped: keep the measures that told you it was a problem in the first place. If numbers, data or evidence flagged it, those very same numbers are what will tell you whether you're actually solving it. It's astonishing how rarely this happens, and it may be exactly why problems keep reappearing: after a burst of hard work we believe, we hope, we assume the thing has gone, with nothing to confirm it either way.

Break it into strands

Many problems feel immovable simply because they're vast and shapeless. The way in is to break them into strands and solve one part at a time.

Low engagement is never one problem – it's management clarity, or objective-setting, or feedback loops, or some tangle of many other things. Don't try to solve "low engagement"; solve what the evidence actually points to (if you must run the survey at all).

Delivery delays are rarely "the delivery system" – they're a single bottleneck, an approval that doesn't work, a chain of small problems adding up to a big one; solve each in turn, almost like a series of little experiments, and you not only keep each fix manageable, you learn what works and what doesn't.

Customer churn isn't one thing either – it's onboarding, or service quality, or mismatched expectations, or something upstream in the sales process, or simply nobody telling the customer they matter. Each of those is a strand.

Solve one strand and you build a little confidence and a little momentum. Solve the next and you build more. Over time the whole problem shifts – not because you charged at it once with everything you have, but because you worked through it in sequence. Methodical, not frantic.

Which, when you stand back, is what business agility actually looks like. Not reacting faster. Choosing better problems, and working them more effectively.