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.
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.
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?
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.
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.
This is a rubbish position that will ruin productivity.
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.
> 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.
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.
> 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.
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?
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.”
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.
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.
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.
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.
"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.
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.
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".
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.
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?
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.
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.
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.
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”
>> 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.
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?
> 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.
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.
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.
“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).
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.
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.
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.
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.
[+] [-] idoby|5 years ago|reply
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|5 years ago|reply
> 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.
[+] [-] somesoftdev|5 years ago|reply
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?
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] C1sc0cat|5 years ago|reply
[+] [-] marcus_holmes|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] happymellon|5 years ago|reply
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.
[+] [-] watwut|5 years ago|reply
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.
[+] [-] strken|5 years ago|reply
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?
[+] [-] C1sc0cat|5 years ago|reply
[+] [-] aklemm|5 years ago|reply
So we’d say the opposite, “Don’t bring me solutions, bring me problems.”
[+] [-] taurath|5 years ago|reply
[+] [-] sicromoft|5 years ago|reply
[+] [-] watwut|5 years ago|reply
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.
[+] [-] rs23296008n1|5 years ago|reply
[+] [-] gpsx|5 years ago|reply
[+] [-] SideburnsOfDoom|5 years ago|reply
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://en.wikipedia.org/wiki/Psychological_safety
[+] [-] Mvandenbergh|5 years ago|reply
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|5 years ago|reply
I blinked once. "Why would I bring you a problem I could solve?"
- @johannarothman in "Practical Ways to Manage Yourself"
[+] [-] lifeisstillgood|5 years ago|reply
(that are unsolvable at your level of resource allocation.)
But that's far less catchy...
[+] [-] taneq|5 years ago|reply
[+] [-] wyattpeak|5 years ago|reply
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.
[+] [-] at_a_remove|5 years ago|reply
[+] [-] muzani|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] adrianN|5 years ago|reply
[+] [-] foolfoolz|5 years ago|reply
“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”
[+] [-] phkahler|5 years ago|reply
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|5 years ago|reply
[+] [-] SideburnsOfDoom|5 years ago|reply
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
[+] [-] muzani|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] ksec|5 years ago|reply
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|5 years ago|reply
“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|5 years ago|reply
[+] [-] eel|5 years ago|reply
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
[+] [-] qxmat|5 years ago|reply
[+] [-] SPQT|5 years ago|reply
[+] [-] zameermfm|5 years ago|reply
[+] [-] jamisteven|5 years ago|reply
[+] [-] viraptor|5 years ago|reply
[+] [-] Aloha|5 years ago|reply
[+] [-] SideburnsOfDoom|5 years ago|reply
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://dash.harvard.edu/handle/1/37968728