Don't bring me solutions, bring me problems (2021-08)

This article was first published on LinkedIn in August 2021.

Truth is subjective, it changes with perspective. When I was a new graduate, building my credibility as a subject-matter-expert, I used to hate managers who said "don't bring me problems, bring me solutions". It seemed so arrogant, and dismissive, and like a dereliction of duty, after all, my job was to escalate, their job was to be escalated to.

When I was a new manager, building a team, growing in confidence, I came to see the wisdom in "don't bring me problems, bring me solutions". Of course it was good to understand the problems, but seriously, I didn't have all the answers. Occasionally it was exhausting, one or two people seemed to do little else save bring little problems they had found, like dutiful cats presenting me with dead birds and mice. "Well done", I used to joke, "here are five more problems, we have plenty of problems, it's like shooting fish in a barrel!".

And yet, I was reflecting last week that actually "don't bring me problems, bring me solutions" is potentially very toxic. The worst thing you can do in an organisation is to make people perceive that they are only bring you answers, and that they have to keep other problems to themselves.

I may not have answers to all our problems, there may not even be answers, but I still want to know what is broken, I still want to know where we can improve.

"Problems" are not really one kind of animal. There are lots of different creatures in the problem-zoo:

• Missed Opportunities: Nothing is 'broken', but something is not happening that means we miss out. Jane sells tea towels door-to-door, sometimes customers ask for dish cloths instead. If Jane had dish cloths, perhaps she could sell more stuff.

• Risks: Nothing is broken, but something is happening that could result in something really bad happening. Most of Jane's customers pay with cash, so she is carrying a lot of cash when she's walking the streets.

• Morale Drains: Nothing is broken, but something is happening that makes people uncomfortable or unwilling to do the job. Sometimes people are so offended at being disturbed by Jane knocking at their door, that they yell at her.

• Process failure: Something is actually broken, and we can't do the thing we said we were going to do. Jane should be able to take credit cards, but the device she's been given to do it doesn't work.

When people talk about 'problems', we mostly think about the last sort, but actually my experience has been that most 'problems' are actually one of the first three sorts.

I've come to think that what really matters with "problems" is what you can do with them, or equally, what is the consequence of not doing something with them.

There are lots of things you can do with problems, solving them is just one possibility.

Of course, everyone wants to solve problems, heck, that's what we do, we are problem solvers... But actually, often that's not what's needed. For instance you can:

• Park it: Talk it through, does this really impact the organisation? What would be the cost of fixing it vs the benefit? Maybe we just need to come to peace with it?

• Escalate it: We can't solve all the problems, sometimes we have to ask for external help.

• Share it: A problem shared is a problem halved. Sharing problems with other people or groups can offer solutions, but it can also just build rapport, help others to see they are not alone, or form the basis for a broader collaboration. As Ian says in the comments, it's also a great 'coachable moment' for team members :- "Great point, that is a problem, if you were me, what things would you suggest?"

Within the agile set of frameworks, a backlog is a great tool for capturing and acknowledging these problems that we are either unable or unwilling to solve, or that we will solve, just not yet. As Ian pointed out in the comments, Agile also advocates the use of root cause analysis, using frameworks like the "5 whys". Without such techniques, we often solve the wrong problem - if poor Jane in our example above got mugged, we can use root cause analysis to determine that we need to fix her credit card reader, not give her karate lessons.

I hope you found this interesting and/or useful! Let me know. Just remember, problems are great, so don't be stingy, don't keep all those great problems to yourself!