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.<p>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.
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.<p>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 <i>that they haven't tried to find a solution for</i>.<p>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.<p>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.
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.<p>So we’d say the opposite, “Don’t bring me solutions, bring me problems.”
"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.<p>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.<p>Effective teams need the safety to speak freely. (1)<p>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.<p>In Engineering, I agree 100% with the last para:<p>> By inviting people to surface problems early, often, and constructively, you reduce fear and increase empowerment and the speed of problem resolution.<p>> Identifying problems can be a solo sport, but finding solutions rarely is.<p>1)<p><a href="https://www.strategyzer.com/blog/psychological-safety-in-the-workplace-a-prerequisite-for-high-performing-teams" rel="nofollow">https://www.strategyzer.com/blog/psychological-safety-in-the...</a><p><a href="https://en.wikipedia.org/wiki/Psychological_safety" rel="nofollow">https://en.wikipedia.org/wiki/Psychological_safety</a>
Interesting. I think that the original phrase was only ever guidance suitable for:<p>a) chastising employees with no initiative who enter a wait-state as soon as they hit the least obstacle.<p>b) senior managers whose job is in fact to find solutions.<p>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.<p>The second group of people it absolutely applies to.<p>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.<p>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.
"Don't bring me a problem without bringing me a solution."<p>I blinked once. "Why would I bring you a problem I could solve?"<p>- @johannarothman in "Practical Ways to Manage Yourself"
Don't bring me solutions, bring me <i>well-formed problems</i><p>(that are unsolvable at your level of resource allocation.)<p>But that's far less catchy...
Every time I hear this, it contributes to a little tickling feeling I have called "What are in this office <i>for</i>, then?" When I hear it, I can only wonder what it is these managers actually do, if they aren't there to solve problems?
>> 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.<p>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.
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?
To solve a Problem we must first admit there is a problem.<p>Which in itself is the biggest problem we have had since birth of humanity.<p>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.<p>The bring me solution answer may have worked in Engineering fields. But it surely does not work across most of the industry.
There are several nuances. I’d say these:<p>“don’t bring me solutions.. (for approval). Implement them and show me the results.”<p>“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).<p>I’m generally talking about tech problems here.
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.<p>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 <i>open-ended</i> 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.<p>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).<p>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.<p>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.<p>[1] <a href="https://hbr.org/1999/11/management-time-whos-got-the-monkey" rel="nofollow">https://hbr.org/1999/11/management-time-whos-got-the-monkey</a>
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.
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.
"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.