There is a well intentioned, but flawed management principle that pops up fairly regularly in articles, podcasts and social updates. It’s a piece of advice for what a manager should say to their team member when problems arise:
“Bring me solutions, not problems.”
On the face of it, it makes sense. You’re saying to your team members that they should think about how to solve a problem before bringing it to you – nothing wrong with that, right?
Except, there is.
Don’t get me wrong, I’m very much in favour of people being encouraged to think for themselves and to not be spoon-fed answers to every problem that arises.
With a soundbite or stance of “bring me solutions, not problems” though, it’s very easy for team members, particularly junior ones, to take this literally. This happens far more often than you’d hope because to many people who haven’t developed experience yet, the world is very black and white. If you tell them something, they take it and run with it.
Great managers realise that words matter.
Words can be heard in ways that you don’t intend and lead to a culture developing in ways that you didn’t intend too.
When you say “bring me solutions, not problems”, I’d hazard a strong guess that you’re not saying “never bring me problems without a solution”.
But this is what people can and do hear.
The issue – people won’t bring problems to you
“Don’t bring me a problem without a solution”
When the tyre hits the tarmac, this is essentially what a lot of people can hear instead of what you actually said. It’s not hard to see why and to understand why a very slight shift in perspective here can lead to a very different mindset.
You’ve basically told people to do this and it’s what they do. When a problem arises, they will have a look at it and try to formulate a solution
The deeper issues – missing context
People don’t know what they don’t know.
When someone, particularly junior or less experienced members of your team, brings a problem and a proposed solution to you, you’re only getting a small snippet of the situation.
The chances are that a wealth of context will be missed out. This is fine to some extent and in some cases, the context may not matter. But when it matters, it really matters.
So you may end up signing off their proposed solution because of the facts and context that they’ve put in front of you. But sometimes, the missing context may make all the difference.
I know this may be getting quite abstract, so let’s talk about an example.
Let’s say that you work at a digital agency and your team handles a bunch of clients. Your team comes to you and says that the client is a little unhappy because of some deliverables that haven’t been quite as good as they should have been. The client has voiced their unhappiness on the regular monthly call and then followed up over email to confirm what their issues are.
So the team explain this to you and aren’t overly worried because the client has generally been pretty happy and this is a large project, yet they’ve only raised concerns over a small portion of the deliverables – everything else seems fine.
Their solution is to redo the sections of the deliverables that the client is unhappy with over the next two weeks and resend. You ask if this is fast enough and they agree that maybe they should do it sooner, and agree to get the work re-done over the next week instead.
On the face of it – this is fine. The client has a problem and that problem is about to be fixed as quickly as possible.
Now, because the conversation with your team is framed as “bring me solutions, not problems” – they’ve done exactly that, described the problem and the solution.
But they’ve missed out a key piece of context – in the follow up email from the client where they confirmed their concerns, they also asked to see a copy of their contract terms and statement of work.
For anyone who has worked in an agency and has a decent level of experience, this would instantly throw up a red flag. Clients don’t ask to see contract terms for no reason and certainly don’t ask to see them because of one or two small deliverable problems.
The thing is, the team are very skilled and good at what they do, but they’ve never faced this question before and didn’t realise what it could mean. So they just sent the contract as requested and carried on working on the problems that they client have raised.
An experienced team member would know here that the problem isn’t what the client is saying, it’s what the client isn’t saying that’s the problem. Asking to see a contract isn’t a problem in itself – sometimes clients lose them and need to record them. But asking for one at the same time as raising concerns about deliverables – they’re saying that they are questioning wider deliverables and the work you’re delivering without saying it.
The underperformance on a small part of the project has triggered them to think about the project as a whole.
Now, I’m not blaming this entire situation on “bring me solutions, not problems”, but I am saying that by taking this stance and having this as part of your team culture, you’re enabling situations where context can be missed out of key conversations.
This may never be a problem if you always have experienced people working across all elements of all projects, but that won’t always be the case.
The dangerous consequence – this is hard to spot
Now, this is where things get real and the real problems can happen.
The real, deep, dangerous consequence of the whole “bring me solutions, not problems” mantra, is that when things are going wrong because people aren’t bringing problems to you – you have no idea that it’s happening.
There could be a bunch of problems in your team, but because the team doesn’t have the solution or more dangerously, doesn’t know the solution, then they may not ever reach you.
What happens instead?
The problems are ignored or papered over with half-way solutions that never reach you.
In summary
Be wary of using this kind of language with your team because, as we’ve seen, it can have unintended consequences that may not even becomes clear to you until it’s too late.
Instead, focus on building a team around the idea that you do trust them to take ownership of problems and to solve them on their own.
BUT…
Balance it very clearly against the idea that you know that they can’t solve every problem on their own and will often need help from you or other senior, experienced members of the team. Encourage them to have conversations about problems, rather than always having to shortcut straight to the answer and not discuss the problem first.
