8 ms·

The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions” (2017)

48 points by zameermfm 6y ago

zameermfm 6y ago
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.
at_a_remove 6y ago
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?
- foolfoolz 6y ago
  this is much more about framing communication in a positive way than actually changing the behavior of your work. you can still be stuck with no idea how to proceed. just changing the way you bring it up can make a big difference in how you are perceived. who sounds more competent? “i’m totally out of ideas and don’t know what to do” vs “we haven’t made progress here and i’m going to ask this person next”
  - DangitBobby 6y ago
    Neither of those are solutions; the second one is just a reworded problem. I doubt your manager can't tell the difference between solutions and reworded problems.
- adrianN 6y ago
  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 6y ago
    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.
- muzani 6y ago
  They're not there to solve problems. They are an interface. They are there to route information from one party to another, and act as information abstractions. Arguably, they're making you do the job of abstracting the information for them. But that is not a bad thing either; it's like moving the responsibility of testing to programmers instead of testers. It reduces the back and forth overhead of trying to explain the problem and solution. Ideally the problems are all localized to the people who can solve them, and the manager deals with problems that need resources from multiple departments. But like all "best practices", this can go too far.
- tumetab1 6y ago
  The same feeling I got when faced this "bing me solutions" mantra. I'm tasked with doing X. Encountered problem Y again which outside my responsibilities. Brought Y issue into the manager attention and got the "bring me solutions" :\ The "bring me solutions" mantra is many items a cop-out used by managers because they don't want to deal with an issue and expect their team to do their work from them, e.g., find who responsible for Y, who can fix it and when.
aklemm 6y ago
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.”
- rs23296008n1 6y ago
  Even worse were the people who already tried spectacularly bad solutions and then demand indignantly that you to pick up the pieces. The cherry on top is when they then blame you for not being able to fix that clusterf*ck.
- taurath 6y ago
  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.
- sicromoft 6y ago
  Indeed. A variant of the classic XY problem: https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
- watwut 6y ago
  People have hard time to distinguish between solution and problem. Second, I think a lot of it is insecurity. They feel bad for asking for help. They fear they will look dumb, so they are talking about solution so that they make sure you know they are not completely stupid and know at least something.
- gpsx 6y ago
  I had a similar experience at a startup. The business manager would only bring a technical problem if he had a solution. And of course, he wasn't really in a good position to present solutions to these problems. It is a great trait for him to have in general but in a business setting, as mentioned in many other comments here, it's nice to get problems early and to include the most skilled people in solving them.
paulydavis 6y ago
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?
- muzani 6y ago
  Like sugar, it is healthy in moderation, and better to have too much than too little. But more often than not in our society, there are very unhealthy levels of it.
- SideburnsOfDoom 6y ago
  > 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
dpenguin 6y ago
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 6y ago
  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.
marcus_holmes 6y ago
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 6y ago
  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 6y ago
    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.
  - Mvandenbergh 6y ago
    The correct solution to finding a bug is to open a ticket though, so the immediate problem has been solved and routed into the appropriate workflow.
  - C1sc0cat 6y ago
jamisteven 6y ago
"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.
- Aloha 6y ago
  If your manager blames you for any problem you bring him, you're unlikely to bring him many.
- viraptor 6y ago
  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.
- SideburnsOfDoom 6y ago
  > psychobabel BS. I dug into this a little. What you're looking for is the paper "Psychological Safety and Learning Behavior in Work Teams" Amy Edmondson, June 1999 https://journals.sagepub.com/doi/abs/10.2307/2666999 https://journals.sagepub.com/doi/abs/10.2307/2666999 https://dash.harvard.edu/handle/1/37968728 https://dash.harvard.edu/handle/1/37968728
idoby 6y ago
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.
- somesoftdev 6y ago
  I do agree, focusing on communication is an important part of a job and for sure it makes your work visible across company. The are other pros. Maybe someone else is facing similar issue - communication may lead to collaboration in this case. If you communicate (early!) about some issues, mgmt has time to account for extra risks or delays. So yeah, communication will get you promoted earlier than focusing on your tasks and keeping everything to yourself. I just cannot agree with the 10% for work and 90% for the communication ratio, that seems like way too much overhead. I think I would rather swap those numbers. Because how are you going to do anything meaningful if you work less than an hour a day?
  - idoby 6y ago
    That depends on what you want to achieve with your time. Want to do something meaningful? Start your own business/startup, volunteer or become a cancer researcher (all debatable of course). Want to survive and get promoted in a corporate world? My recipe will get you there. 1 part work for 9 parts politics. If that makes you feel bad you can water it down to 1/8. I define "corporate" as any human org greater than 100 members, including non-profits, academia, military, even your damn scout troop. Also: never communicate early. Communicate after you've solved the issue to look like a go-getter, avoid prolonged discussions and prevent people from taking credit. If you manage to take credit for someone else's hard work (say, if they're not a good communicator), all the better. That will help with maintaining a low work/politics ratio.
lifeisstillgood 6y ago
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 6y ago
  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".
- wyattpeak 6y ago
  I think it's also something that takes a lot of work to teach, and is probably domain-specific. I get it a lot dealing with bug reports. Bug reports without enough information to be reproducible are a well discussed problem, but there are also a subset which have vastly too much detail musing about cause, which are often fairly misguided. In trying to make my job easier, the reporter has spent a lot of time pursuing something unhelpful, because they don't have the knowledge to know what to look for. Writing a truly well-formed bug report requires a reasonable degree of familiarity with bug-finding and -fixing. And I suspect the same is true in many domains.
qxmat 6y ago
The "stop solutionising" mantra in agile is equally harmful.
pjmorris 6y ago
"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"
phkahler 6y ago
>> 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.
SideburnsOfDoom 6y ago
"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-workplace-a-prerequisite-for-high-performing-teams https://www.strategyzer.com/blog/psychological-safety-in-the... https://en.wikipedia.org/wiki/Psychological_safety https://en.wikipedia.org/wiki/Psychological_safety
SPQT 6y ago
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.
eel 6y ago
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
Mvandenbergh 6y ago
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.
deleted 6y ago
[deleted]
ksec 6y ago
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.

48 points by zameermfm 6y ago

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.

at_a_remove 6y ago

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?

foolfoolz 6y ago
this is much more about framing communication in a positive way than actually changing the behavior of your work. you can still be stuck with no idea how to proceed. just changing the way you bring it up can make a big difference in how you are perceived. who sounds more competent? “i’m totally out of ideas and don’t know what to do” vs “we haven’t made progress here and i’m going to ask this person next”
- DangitBobby 6y ago
  Neither of those are solutions; the second one is just a reworded problem. I doubt your manager can't tell the difference between solutions and reworded problems.
adrianN 6y ago
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 6y ago
  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.
muzani 6y ago
They're not there to solve problems. They are an interface. They are there to route information from one party to another, and act as information abstractions. Arguably, they're making you do the job of abstracting the information for them. But that is not a bad thing either; it's like moving the responsibility of testing to programmers instead of testers. It reduces the back and forth overhead of trying to explain the problem and solution. Ideally the problems are all localized to the people who can solve them, and the manager deals with problems that need resources from multiple departments. But like all "best practices", this can go too far.
tumetab1 6y ago
The same feeling I got when faced this "bing me solutions" mantra. I'm tasked with doing X. Encountered problem Y again which outside my responsibilities. Brought Y issue into the manager attention and got the "bring me solutions" :\ The "bring me solutions" mantra is many items a cop-out used by managers because they don't want to deal with an issue and expect their team to do their work from them, e.g., find who responsible for Y, who can fix it and when.

aklemm 6y ago

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.”

rs23296008n1 6y ago
Even worse were the people who already tried spectacularly bad solutions and then demand indignantly that you to pick up the pieces. The cherry on top is when they then blame you for not being able to fix that clusterf*ck.
taurath 6y ago
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.
sicromoft 6y ago
Indeed. A variant of the classic XY problem: https://en.m.wikipedia.org/wiki/XY_problem https://en.m.wikipedia.org/wiki/XY_problem
watwut 6y ago
People have hard time to distinguish between solution and problem. Second, I think a lot of it is insecurity. They feel bad for asking for help. They fear they will look dumb, so they are talking about solution so that they make sure you know they are not completely stupid and know at least something.
gpsx 6y ago
I had a similar experience at a startup. The business manager would only bring a technical problem if he had a solution. And of course, he wasn't really in a good position to present solutions to these problems. It is a great trait for him to have in general but in a business setting, as mentioned in many other comments here, it's nice to get problems early and to include the most skilled people in solving them.

paulydavis 6y ago

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?

muzani 6y ago
Like sugar, it is healthy in moderation, and better to have too much than too little. But more often than not in our society, there are very unhealthy levels of it.
SideburnsOfDoom 6y ago
> 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

dpenguin 6y ago

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 6y ago
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.

marcus_holmes 6y ago

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 6y ago
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 6y ago
  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.
- Mvandenbergh 6y ago
  The correct solution to finding a bug is to open a ticket though, so the immediate problem has been solved and routed into the appropriate workflow.
- C1sc0cat 6y ago

jamisteven 6y ago

"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.

Aloha 6y ago
If your manager blames you for any problem you bring him, you're unlikely to bring him many.
viraptor 6y ago
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.
SideburnsOfDoom 6y ago
> psychobabel BS. I dug into this a little. What you're looking for is the paper "Psychological Safety and Learning Behavior in Work Teams" Amy Edmondson, June 1999 https://journals.sagepub.com/doi/abs/10.2307/2666999 https://journals.sagepub.com/doi/abs/10.2307/2666999 https://dash.harvard.edu/handle/1/37968728 https://dash.harvard.edu/handle/1/37968728

idoby 6y ago

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.

somesoftdev 6y ago
I do agree, focusing on communication is an important part of a job and for sure it makes your work visible across company. The are other pros. Maybe someone else is facing similar issue - communication may lead to collaboration in this case. If you communicate (early!) about some issues, mgmt has time to account for extra risks or delays. So yeah, communication will get you promoted earlier than focusing on your tasks and keeping everything to yourself. I just cannot agree with the 10% for work and 90% for the communication ratio, that seems like way too much overhead. I think I would rather swap those numbers. Because how are you going to do anything meaningful if you work less than an hour a day?
- idoby 6y ago
  That depends on what you want to achieve with your time. Want to do something meaningful? Start your own business/startup, volunteer or become a cancer researcher (all debatable of course). Want to survive and get promoted in a corporate world? My recipe will get you there. 1 part work for 9 parts politics. If that makes you feel bad you can water it down to 1/8. I define "corporate" as any human org greater than 100 members, including non-profits, academia, military, even your damn scout troop. Also: never communicate early. Communicate after you've solved the issue to look like a go-getter, avoid prolonged discussions and prevent people from taking credit. If you manage to take credit for someone else's hard work (say, if they're not a good communicator), all the better. That will help with maintaining a low work/politics ratio.

lifeisstillgood 6y ago

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 6y ago
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".
wyattpeak 6y ago
I think it's also something that takes a lot of work to teach, and is probably domain-specific. I get it a lot dealing with bug reports. Bug reports without enough information to be reproducible are a well discussed problem, but there are also a subset which have vastly too much detail musing about cause, which are often fairly misguided. In trying to make my job easier, the reporter has spent a lot of time pursuing something unhelpful, because they don't have the knowledge to know what to look for. Writing a truly well-formed bug report requires a reasonable degree of familiarity with bug-finding and -fixing. And I suspect the same is true in many domains.

qxmat 6y ago

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

pjmorris 6y ago

"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"

phkahler 6y ago

>> 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.

SideburnsOfDoom 6y ago

"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-workplace-a-prerequisite-for-high-performing-teams https://www.strategyzer.com/blog/psychological-safety-in-the... https://en.wikipedia.org/wiki/Psychological_safety https://en.wikipedia.org/wiki/Psychological_safety

SPQT 6y ago

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.

eel 6y ago

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

Mvandenbergh 6y ago

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.

deleted 6y ago

[deleted]

ksec 6y ago

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.