The Problem with Saying “Don’t Bring Me Problems, Bring Me Solutions” (2017)
hbr.org
hbr.org
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 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?
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.
The approach you describe sounds like a piece of advise for someone who hates his job. So one would do as little as possible just not to get himself fired. Sounds like an awful position to be in.
Also, you seem to be content with being an individual contributor engineer, which is perfectly fine, but if you want to get ahead, you're not going about it the right way.
I'm actually writing a book about this.
Also, I'm planning for that book to have a slightly narrower focus, so I may have not done the project any justice.
I do have a lot of tech machiavellianism to write about though, from the small, but notable tech community in my country (Israel).
Do you think people would read this though? Maybe in blog form?
> 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.
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.
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.
I often get this as an experienced person I get tasks sent to me requiring a detailed response to a problem - where what should happen is they should have done the research and proposed a solution for me to review.
Its not my job to do both my job and your CTO or team leads job as well
Rather than raising an issue, when I work on an unrelated task you think I should investigate instead? That's how unplanned work happens, and productivity drops.
Problems should be raised, and prioritised, if it impacts the current task and prevents completion then it should be worked on. But as a manager you need to be aware that there is a problem and that it will impact timelines. If it does not impact the current task then there needs to be a business call on the priority, and if the worker should drop the current task to resolve it. Sometimes the worker has the experience to know when the issue is a business priority, but I have been caught out before when something seems important but promises have been made on the original task that were not communicated raising the priority. Communication isn't a bad thing, and not investigating is also not a bad thing.
First, this is not what "don't bring me problems, bring me solutions" means. If I tried to find solution and I am contacting manager, I still dont have solution and I am still bringing problem.
Second, it is management job to know and look for solutions for organizational problems. Or to know who to delegate the problem to.
Employees have their own tasks and responsibilities. Informing management about issue they noticed and then moving on with their days is absolutely valid move. And sing of management incompetence to punish such information.
A deeper issue with the employee, or a deeper issue with the processes and structure of your company? Is the solution to the "tiny problem" dependent on institutional knowledge that only exists inside someone's head? Does the employee have a peer to mentor them, and should you have facilitated that relationship? Is it a confidence issue, where the employee needs to be reassured rather than told off?
Why are they coming to you?
In my experience the most common cause of this is that the employee either doesn't want to do the task, or doesn't feel that they can do the task.
If they don't want to, then that can sometimes be tricky to determine. Worth persevering with, though, because again it can be a sign of a deeper underlying issue.
If they don't feel they can do it, then it's either a problem with their confidence, which can have many causes (everything from a fear of failure to workplace bullying). Or it's that they're right, and they actually can't do this task. Which might be because the task is specified badly, or that their training is incomplete. Or that the task is actually impossible but that's not apparent until you get into the details of it.
So we’d say the opposite, “Don’t bring me solutions, bring me problems.”
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.
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...
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.
I blinked once. "Why would I bring you a problem I could solve?"
- @johannarothman in "Practical Ways to Manage Yourself"
(that are unsolvable at your level of resource allocation.)
But that's far less catchy...
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.
“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”
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.
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.
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.
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.
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.
“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.
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
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