
The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions” (2017) - zameermfm
https://hbr.org/2017/09/the-problem-with-saying-dont-bring-me-problems-bring-me-solutions
======
idoby
There's another issue to be considered: a manager whose employees constantly
discover and solve problems by themselves or as a group without involving the
manager, will generally assume no problems were to be had. This is very bad as
these invisible problems will not show up when your skip-level or committee
reviews candidates for promotions or bonuses, or just generally can make you
appear to be low-performing just because you're a quiet, competent problem
solver. I've seen this happen on too many teams to count.

Always make sure to do your work and to communicate effectively that you're
doing your work, facing hard problems and working hard. Communicating this
effectively is far more important than actually doing it, so I'd recommend
spending 90% of your working time on this communication, and no more than 10%
of your working time on actual problem solving. You are a salaried employee.
The only thing you really need to care about is how your manager and their
manager feels about you.

~~~
taneq
I think you're right that just quietly solving all the problems is not a great
strategy for an employee, however I think this bit:

> Communicating this effectively is far more important than actually doing it,
> so I'd recommend spending 90% of your working time on this communication,
> and no more than 10% of your working time on actual problem solving.

...seems out of whack. We've probably all worked with someone like this, who
did very little actual work and spent all their time on self-promotion and
political maneuvering. They make awful teammates and bring everybody else
down.

It's definitely worth advertising when you do solve problems, of course. If
you hit a tricky one just send an email (either to team or just to boss as
appropriate) with a quick description of the problem and how you solved it. No
point doing good work if nobody's going to notice.

~~~
idoby
They do it because it works. Yes, they're bad teammates but they will move up,
and they don't care about you or how it feels to be their teammate.

~~~
taneq
That kind of thing only works for a short while before word gets around. Maybe
you can keep ducking the fallout indefinitely in a big enough city but where I
live, it's a small world and you'll burn your reputation in short order.

~~~
idoby
Only if you do it badly. It's very likely that the people at the top of this
"small world" in your town have done exactly this to get there.

~~~
taneq
If you spend 90% of your working time self-promoting instead of working, I
guarantee you your co-workers _will_ notice and they _will_ hate you for it
even if your current management are too incompetent to pick up on it. The only
exception is if your entire department is a nest of weasels.

------
marcus_holmes
The example manager in the article is an example of a bad manager, nothing to
do with "don't bring me problems". Shouting at people who bring bad news is a
dick move regardless.

And the point of "don't bring me problems" is not that no employee should
bring you a problem, but that no employee should bring you a problem _that
they haven 't tried to find a solution for_.

There are often problems that are outside the scope of a single employee to
solve, and that's OK. But the employee needs to have at least tried to find
that out. If they're genuinely unable to find a solution, that's fine.

It's not fine when the first tiny problem causes them to give up on a task and
say they can't do it. That's an indication of a deeper issue, and needs
investigation. Or a sign that they've been trained by previous managers to
bring up any problems - this is when "don't bring me problems" works well.

~~~
nicbou
Why should they have to find a solution? If I find a bug, I open a ticket and
let the next available person take care of it. Likewise I bring up process
issues before looking for a solution, because I don't have a full view of the
problem. I discuss it with the team first.

Defining the problem and the solution are two distinct steps. Otherwise you
might get invested in a solution that doesn't fully match the problem.

~~~
cosmodisk
If the problem you found only half relates to your job,then yes,sure,pass it
on,but that shouldn't be the case if it's purely related to your role. As a
manager I do expect people report all sorts issues but it's so much better
when it's like this: x,y,and z isn't working.I think we could do a,b, and c
with it. It shows that the person does care about it and they can think on
their feet.

------
aklemm
This is funny to me as it reminds of my early days on help desk where we would
get fed up with people coming in telling is what solution they needed for
their tech problems instead of telling us the problem and letting us find a
solution that made some sense.

So we’d say the opposite, “Don’t bring me solutions, bring me problems.”

~~~
taurath
In software roles, we're often asked by customers to "Build me this.", which
is a solution. The first thing we need to actually solve their problem is
"what problem are you trying to solve?". Sometimes its easy to get an answer
to that question immediately, and sometimes you never ever will. If you work
in a place where the latter is frequent, find a new job whenever you can. You
or your division will be blamed for the bad outcome caused by lack of trust
and communication.

------
SideburnsOfDoom
"Don’t Bring Me Problems, Bring Me Solutions" might or might not be a decent
C-level management thing, but it is a terrible engineering practice.

Engineering problems get solved when people discuss issues and bounce ideas
off each other. They need to be able to speak about problems freely. Even if
the solution isn't apparent yet, or not apparent to the person experiencing
it.

Effective teams need the safety to speak freely. (1)

OK, you don't want complaining for the sake of it, but but you also need to be
able to listen though a bad tone and get to the underlying message.

In Engineering, I agree 100% with the last para:

> By inviting people to surface problems early, often, and constructively, you
> reduce fear and increase empowerment and the speed of problem resolution.

> Identifying problems can be a solo sport, but finding solutions rarely is.

1)

[https://www.strategyzer.com/blog/psychological-safety-in-
the...](https://www.strategyzer.com/blog/psychological-safety-in-the-
workplace-a-prerequisite-for-high-performing-teams)

[https://en.wikipedia.org/wiki/Psychological_safety](https://en.wikipedia.org/wiki/Psychological_safety)

------
Mvandenbergh
Interesting. I think that the original phrase was only ever guidance suitable
for:

a) chastising employees with no initiative who enter a wait-state as soon as
they hit the least obstacle.

b) senior managers whose job is in fact to find solutions.

In the first case, I have unfortunately worked with people who just stop at
the first obstacle but this is very rare among tech people. Probably because
part of any programmer's experience of learning to code is long periods of
trying to get things to work, checking google for solutions etc. If anything
coders often work on problems solo for too long rather than not long enough
before escalating. Junior people especially will have had years of writing
code solo in high school and college before they join a team so it's a habit
to get out of.

The second group of people it absolutely applies to.

The important thing to get right is to bring the problem along with the
appropriate context and solutions which have been tried and do not work rather
than just the problem. It's just like writing a good bug report, actually.

How much should be tried to get a solution depends on the seniority of the
person doing it. If they're leading a team then I would expect a quick heads
up early but no more, something like "we're having a performance issue in X,
it might have the following effects on other parts of the project, we're
trying a, b, and c. No action required on your part at this point". On the
other hand if they're a junior member of a dev team on their second day, I
would expect them to escalate an issue that they can't solve themselves in 10
minutes to whoever is doing their onboarding / immediate line manager.

------
pjmorris
"Don't bring me a problem without bringing me a solution."

I blinked once. "Why would I bring you a problem I could solve?"

\- @johannarothman in "Practical Ways to Manage Yourself"

------
lifeisstillgood
Don't bring me solutions, bring me _well-formed problems_

(that are unsolvable at your level of resource allocation.)

But that's far less catchy...

~~~
taneq
Exactly. This is the organisational equivalent of the various "how to ask
questions" lists that have done the rounds over the years. You don't go to
your boss and say "everything's fubar". You go and say "there's a conflict
between X and Y that we can't solve because of Z".

------
at_a_remove
Every time I hear this, it contributes to a little tickling feeling I have
called "What are in this office _for_ , then?" When I hear it, I can only
wonder what it is these managers actually do, if they aren't there to solve
problems?

~~~
adrianN
Imho managers aren't supposed to solve product problems. Managers are
communication hubs between different teams who know enough about out-of-team
needs to prioritize the different tasks that the team can do.

~~~
watwut
They should not be leading teams nor make decisions about process nor about
personal issues. If this is their whole scope they should do nothing outside
of task prioritization and should have much less power.

------
phkahler
>> His team members told me that if they raise an issue or risk, James often
hears failure and reacts by losing his temper and raising his voice.

This "James" character sounds like he's in the wrong position. Incompetent
managers get mad when you bring them problems and say things like "bring me
solutions". If you have competent employees, they solve problems all the time
and only escalate when they are unsure, want additional input, or feel the
scope of the problem - and solution - is beyond their control.

------
paulydavis
Can complaining be healthy? It is usually an emotional reaction to
frustration. Isn't your employees being frustrated a signal that there is a
problem past the problem?

~~~
SideburnsOfDoom
> Can complaining be healthy? It is usually an emotional reaction to
> frustration.

Yes it can and yes.

Frustrated and upset people naturally find it harder to talk calmly about the
thing that's annoying them. You can miss a message by focusing on the tone of
the delivery:

> detracts from the validity of a statement by attacking the tone in which it
> was presented rather than the message itself.

[https://en.wikipedia.org/wiki/Tone_policing](https://en.wikipedia.org/wiki/Tone_policing)

------
ksec
To solve a Problem we must first admit there is a problem.

Which in itself is the biggest problem we have had since birth of humanity.

There are problems that cant be solved in your position or resources. There
are problems that cant be solved without higher level knowledge and
visibility. There may also be a problem that you should not solve, i.e It is a
feature not a bug.

The bring me solution answer may have worked in Engineering fields. But it
surely does not work across most of the industry.

------
dpenguin
There are several nuances. I’d say these:

“don’t bring me solutions.. (for approval). Implement them and show me the
results.”

“You are allowed to bring me problems that you have tried and decided you
cannot solve”(But that’s going to affect how I view you - over time if you
keep bringing me the same type of problems, I’ll decide you’re not good enough
for your job).

I’m generally talking about tech problems here.

~~~
cosmodisk
This is applicable to other areas as well.For instance,my team occasionally
get angry customers on the phone who demand to speak to the manager. I do take
those calls and most of the time they end up being fine. However,some in the
team always have at least one of these angry ones,while others don't have any.
But what I don't see are those who often can't manage the angry ones asking
for help or even think there's probably something missing in the way they
handle calls. That is a problem.

------
eel
Do people in leadership positions actually say this in the real world? I
personally have not seen it in the workplace in 10 years, but maybe I have
been lucky. I am curious to hear if others have heard this saying in the
workplace before and what your reaction was.

As a software developer and individual contributor, I firmly believe in the
saying applied to my own work (with a small modification): I avoid bringing
_open-ended_ problems to my leadership. I'll bring problems with solutions,
I'll bring problems with sets of options, but it's only a last result that I
bring an option with no proposed solutions.

I came to this conclusion after two events. The first was a few years ago when
I joined a company and was given a task to fix a bug in some Perl code on my
first or second week. In my first 1:1 with my manager, I complained about the
task. Why did they use Perl, I don't know Perl, the code isn't documented,
it's ten years old etc. I wasn't trying to get out of the task. My manager had
simply asked me how it was going, and I was just going through the things I
was thinking about at the time. He listened patiently, and after the meeting,
he assigned the ticket to someone else. Whoops. I realized at that time that I
had brought a problem to my manager, and he had chosen to solve it in his own
way. As a result, I did not achieve the outcome I was hoping for (which was to
fix the bug and make a good impression).

The second event was a couple years ago when I stumbled into one of HBR's
classic articles from 1974, Management Time: Who’s Got the Monkey? [1] This
article is about the need for managers to manage their time effectively. If a
manager's reports are bringing too many problems ("monkeys"), then the manager
can get bogged down solving problems on behalf of their reports. Reading this
article about the manager's point of view really helped it click for me: to be
a more effective engineer, I needed to bring results to my manager. Overall, I
think the approach is working well for me.

When I read the 1974 and 2017 articles, I believe both are implying is that
excellent managers should empower their reports to bring solutions rather than
demanding solutions. Rather than demanding solutions, a good manager will
build trust with their reports, encourage critical thinking, and build up the
confidence of their reports.

[1] [https://hbr.org/1999/11/management-time-whos-got-the-
monkey](https://hbr.org/1999/11/management-time-whos-got-the-monkey)

------
qxmat
The "stop solutionising" mantra in agile is equally harmful.

------
SPQT
I had such a boss when I started work - best time ever, I never bothered with
solutions and I didn't report the problems...year and a half of paychecks or
almost 0 work done.

------
zameermfm
It’s time to retire the saying “Don’t bring me problems, bring me solutions.”
Even though advocates of this approach believe it reduces whining, increases
empowerment, helps employees manage up, and boosts careers, it’s fraught with
challenges.

------
jamisteven
"Make it safe. Modify your behavior so that people aren’t afraid to bring you
bad news." Are they serious with this? I swear so much of HBR's recent content
is so politically correct, wayward with the sun, psychobabel BS.

~~~
viraptor
You may want to read up on how hospitals adopted checklists and how part of
the change in the process was enabling workers to question their superiors /
surgeons. It's not politically correct - it's tested in many industries that
if people don't feel safe to raise issues they will let problems happen.

