My experience exactly. We used to do this but gave up many years ago. Better to have individuals develop bare-bones ideas and then review with a group. Better yet, have a ranked voting system with a large but somewhat informed group to winnow down the list.
I'm a divergent thinker and like to bounce ideas off other divergent thinkers, so I can work alone or with others, but/ ideally they need to be creative/ open
Once we have a list of ideas, then whittle the list down with the realist and pessimistic people of the group; until there's one obvious way forward or a couple of least worse ideas.
Generally most people are better at telling you what you can't do,
i am too...and i basically cant work at the same level if i'm just sitting alone by myself. so i _have_ to kick stuff aronud with people. unfortunately the longer i stay in the industry the less people are used to working this way.
I've also found brainstorming isn't great for more "creative" thinkers. In a group setting it's easy to say "no that won't work" or not get buy-in on the spot, so ideas that aren't mainstream get shot down right away.
People like me also need time and space to think deeply about certain topics, and a brainstorming session has neither time nor space, so you're immediately limited in the ideas that are presented.
Those people aren't brainstorming; the rules should be that ideas get evaluated later, and that no idea is too outlandish, even if it "won't work". You write every idea down, and cull later, at which point people have had time to think about how something might get done, rather than simply to cancel it off the cuff.
+1. Brainstorming is a way to generate leads by leveraging diverse group of minds/experiences/skills. In a healthy environment, such experience may be even bonding for the team, as long as ranks and seniority are left at the door (which is not easy).
Just clearly write out the scope and purpose, timebox it, and collect/record the ideas, no judgement, not even attribution. Then the next time, see if anything converges, evaluate what can be done.
“as long as ranks and seniority are left at the door.”
100%. We had anyone who wanted to join, and nobody’s ideas were better than others. One of our most beloved features was one that our EA came up with in such a session, because she didn’t have the context to think it was hard to do. A few days later, we found an easier way to do it, but we’d never even have looked if it weren’t for the humility and collaboration in that room that day.
Brainstorming isn't for problem-solving, especially when problems are small and well defined. Communication overhead destroys the efficiency.
I've participated in several team programming competitions. The way every team worked was - everybody read all tasks, quickly decide who works on what, and then we work solo on one problem each in parallel, when somebody finishes (s)he can help others who are stuck or take on another tasks. Talking about the problem all the way was way too slow and didn't much helped.
But problem-solving isn't the only creative thinking people do. When creating a story for table-top RPGs brainstorming works great.
I think the opitmal number of people working on a problem is somewhere between 1 and 2. The amount of communication required obviously scales very poorly, but in principle, having to explain your process to someone else functions well. I prefer pair programming to solo work, usually. I catch more bugs, and am forced to explain things to myself as I explain them to my partner.
I agree, and the premise of going in on a programming contest with a team is presumably that you are all capable of solving some problem on your own. I was merely arguing that there is value to be had in numbers greater than 1, but not numbers greater than 2, in my experience.
I've had SOME great brainstorming sessions that provided great ideas for paths forward when starting new projects. I think that last part is important. Specifically, the "Discover" part of the double diamond design process.
In the cited article, sure the faster problem solvers will solve more individually. But
1) the proper grain to measure success is as the team level, and
2) it's easy to score a problem with a known answer, but it is significantly harder for a group to come to consensus as to what the best answer might be – you can't always just crunch the numbers to see who was right.
The advantages of the brainstorm at the team level can be profound: they can reach consensus as to what these better options are, as well as a shared understanding of the problem space and what the next steps are.
>Brainstorming has become a heuristic, an attempted shortcut, a lossy substitution for psychological safety.
I'm glad this was where the author ended up. As I read this, I kept thinking that I know how to get better ideas out of people than a lot of typical brainstorming scenarios I've experienced in the past. My mind kept going back to how good some of the (Agile) retros I've had, and the one thing they all had in common was psychological safety was key. Creating a safe space allowed people to really express their issues, which made it much easier to address them. I've always understood one of the most important actions in a brainstorming session is the "turkey shoot" by one of the seniors. It's an idea so bad that even interns think, oh, my idea is better than that and so find it easier to participate. Without that, you can very much end up with a session dominated by hierarchy.
Another term that may be more familiar is "ice breaker". The senior person offers up an idea to get the ball rolling. It shouldn't be too complex, it shouldn't sound like the way to go. It's just something to help make other people more comfortable participating, especially people junior to them. It may even be a dumb idea, getting some laughs and breaking the tension.
There seems to be a difference of intent between what Osborn describes (at least the selected quotes) and what the researchers, Diehl and Stroebe, studied. In particular, he describes brainstorming as for developing creative ideas, while the researchers study it as a method for problem solving.
From the quotes by Osborn it seems his purpose for it was to find ideas, no matter how far out there. Whereas the researchers were directing people to use brainstorming to find (what sounds like) one or a small number of viable solutions. Those are two different activities, so an approach could be useful for one and useless (or suboptimal) for the other, but there is no way to conclude how applicable it is to the former based on studies of the latter.
> In particular, he describes brainstorming as for developing creative ideas, while the researchers study it as a method for problem solving.
The article should have been called "Stop Brainstorming to Solve Problems". The title is clickbaity. Brainstorming to solve a problem is just team easter-egging.
In my experience it is best to explain the problem today, and ask about ideas tomorrow. Most people tend to think up ideas on their own time rather than on-demand as if they're some kind of ideas slot machine you can just yank on.
I think it helps to have weekly-or-so discussions about The Problems We're Having Lately, not so much as "brainstorming" but giving people a chance to offer their latest ideas and explain problems encountered with previous ideas.
>“Brainstorming” — the problem-solving technique of coming up with as many ideas as possible in a short period of time
I'm Longstorming-the problem-solving technique of coming up with as many ideas as possible in a long period of time
Now I have over 100 startup ideas, it's kind of hard to keep track anymore. But it is interesting how some ideas synergize with each other and can be combined in order to solve bigger problem.
Many of the Design Sprint brainstorming sessions I've been a part of felt superficial. I can see the value in pushing people to list out lots of ideas very quickly, to force them to explore the solution space and not get stuck on a single idea. But the output is more like idea stubs than ideas, usually a few words on a sticky note.
In the brainstorming sessions I've attended, the next stage involves the facilitator taking all of the idea stubs and grouping them together, then riffing on the idea groups. The whole process (intentionally?) feels like improv comedy. And much like improv, it often seems geared more for the enjoyment of the participants than the quality of the output.
And maybe that's ok, using brainstorming purely as a tool to circulate half-ideas and get the creative juices flowing? But in a design sprint, the brainstorming outputs are often directly used for longer term planning. I've found something like a lightweight RFC process is a much better medium for refining and discussing ideas. RFCs are usually written alone, and discussed as a group.
I see a lot of parallels between this article and a discussion from yesterday about how often to loop in others on your work[0]. Like most things in life, there are a lot of complicated tradeoffs between solo work and group collaboration, and rarely any straightforward answers. That said, one prevelent trend is that whatever is in vogue is probably being over used.
If group brainstorming is top of mind for a lot of executives, it's a good bet that there's way too much of it going on. If a dev team thinks they always do their best work in isolation, they're probably missing out on some major benefits to be had by mixing in more collaboration and pair programming.
> That said, one prevelent trend is that whatever is in vogue is probably being over used.
This is a great rule of thumb, and could likely be applied to itself even, if it become a widespread sentiment.
It's not quite the same thing, but I think there might be a relationship to Goodhart's Law. It may also partially explain why Agile has gone so wrong for so many companies.
I buy the ineffectiveness of brainstorming meetings.
I don’t think it’s as big of a deal as it might seem, though. You still need to get together and decide what to do with your team, it just probably should be a safe space is all. We knew that.
Hardly anything works without safety, and nearly anything works with safety. Sounds good to me.
I can say with certainty that failure to be systematic about idea generation has led to many failed projects that otherwise could have been great successes. These projects were, in hindsight, "almost hugely successful", had we had the correct idea to pivot to. Sometimes only a tweak or an additional feature was required.
Also, a separate comment to this thread:
Edward De Bono's "Six Thinking Hats" is an alternative way of approaching innovative idea generation.
Great ideas comes from individuals; But a combination of ideas as a team effort is what usually solves sizable problems.
There may be narrow use cases where the overhead of brainstorming doesn't add any value; but otherwise, I still believe brainstorming is a good way to consider alternatives for open-ended problems.
It's amazing how much I have built my career around psychological safety (one tends to admit these things a bit more as we get older)
So yes. If anything can improve your work experience, your productivity , it's psychological safetry
Taken to an extreme it would be sensible to give teams a annual bonus at the start of the year. Give them FU money and so be fairly confident they will say FU when it's needed
I take FU money to mean you no longer need a job. For many that means millions. Even with that you may not have psychological safety: being able to say FU and saying FU are 2 different things. You
could instead just get someone leave and say “yeah wanna
go travelling” while actually thinking “fuck that”.
I think the article’s missing an important trick: Brainstorming establishes a shared understanding (depending on the group dynamics, you might call it a fiction) that the group, not any individual, came up with the idea. That sense of ownership is psychologically important for aligning the group during the execution phase: People are usually a lot more motivated to implement a plan that they came up with, and if anyone challenges the idea, much more eager to defend it.
A lot of people do this very badly. They craft a brainstorming session designed to arrive at their pre-selected destination. They either design the process to steer the conversation, or shut down tangents as they go. This always feels manipulative and scummy.
This works on "newbies" until they realize what's going on and then they learn to see through it and begin to resent not only this "trick" but also the people who attempt to use it, which maybe works if you keep churning through people--and this is an industry with enough new blood being injected constantly that maybe that even feels "sustainable"--but I still feel like the people who do it should be judged harshly.
This is a pretty cynical view. It's not actually a bad thing to make folks feel like they have a sense of ownership over an idea; human nature is human nature and motivating people to work hard and feel ownership is its own challenge.
I agree with you. There are enough people in the world who play games to make others suffer that I'm not going to spend much energy resenting people who play games to make others feel good.
I do think the author's final point about psychological safety is a good one.
I think manipulating people into believing something that's not true is a bad thing, even if it improves the bottom line. To think otherwise, I submit, is the truly cynical view.
But it doesn’t matter. If two people think they came to the same design together it doesn’t matter if someone else already did ahead of time.
The important thing is that they have convinced themselves that it makes sense.
You don’t even have to lie. You can go into a meeting as a lead and say that you have an idea of how something might look but you want the group to come up with a design anyway.
I came here to write this, and also to say that on a software team, for example, where the problem is complex, no one person may have a well rounded enough or deep enough grasp of the problem, goals, limitations, etc. to come up with an optimal solution on their own. This is why we have businesses in the first place, to organize teams in a greater-than-the-sum-of-its-parts kind of way. A very basic example of this might be a UI designer coming up with a number of potential interface ideas for a particular problem users are experiencing, and an engineering choosing the design which will cost the least dev hours. Iterating on sketches of such potential solutions will almost certainly get to a better solution than the designer just making a choice their own favorite design and lobbing it over the wall to eng.
Not to dismiss the psychological safety point the article makes, which i believe is very valid.
I think we use the term "brain storming" in different ways, engineering teams coming together to flesh out an idea is often nothing like a "brainstorming" session. Engineering often tends to do "cooperative brain leveraging" :)
I’ve been building software for 20 years, and in my experience good ideas come from anywhere, especially on a high functioning teams where everyone is bought in. Engineers in particular often come up with great leftfield solutions, as they know what’s going on behind the scenes and can find way to leverage that knowledge.
I think this article might be something a litmus test for determining if you believe in such a thing as a functional software (not just engineering) _team_ or not.
Yeah, brainstorming has put a bad name on collaborating next to a whiteboard with pens and post-its.
Brainstorming tries to achieve an unstructured creative session whereas engineering teams are trying to flesh out a structured plan to a complex problem.
Not all whiteboarding in a group is brainstorming. The former usually results in tremendous added value while with the latter I agree it's mostly pointless.
> Brainstorming establishes a shared understanding (depending on the group dynamics, you might call it a fiction) that the group, not any individual, came up with the idea.
IME, brainstorming sessions don't really serve that purpose except when they actually do result in real substantive collaboration. While people may have tribal identity as part of a team, they also tend to be aware of the group dynamics in the team and how decisions are actually made.
But, IME, lot of people in lead and management positions buy into the effectiveness of brainstorming sessions as tools of forging shared fictions in ways which are supported by the way people on the team look at the output.
Yes, the article almost perfectly misses the point of brainstorming. The studies quoted were for groups solving puzzles, not groups designing tools or products. Puzzles have solutions, products can be entirely abandoned.
Almost zero of the brainstorming meetings I've ever attended were of the kind "How do we solve the well-defined problem X", and were almost exclusively of the kind "What do we want to do in the area of <subject>?" or "Can we agree on needs to be solved, and deal out problems to individuals?".
It's actually unclear what type of puzzles we are talking about. One paragraph later mentions a jury judging puzzle solutions and creativity. We could be talking about open ended puzzles. Think "the marshmallow callenge", LEGO building challenges, or Zachtronics style puzzle games (programming puzzles where you can optimize as much as you want, and the game scores you on multiple competing metrics such as code size and cpu cycles used). It's totally possible to measure creative thinking using open ended puzzles where there's more than one solution, or where trade-offs matter. That mention of a jury judging solutions suggests open ended puzzles are employed here.
Those with enough experience can anecdotally measure the success of brainstorming on projects where they've used it. I'd contribute the un-revolutionary idea that brainstorming works well for some teams trying to solve some problems. The trick is knowing when to use it, not to use it all the time, or rule it out entirely.
I would argue that ideation aside, the person responsible for executing said idea needs to have a clear motivation & reward for taking up ownership of actioning it.
Brainstorming might be a throwback term, but it works.
Yep, I’ve got plenty of ideas ready to go. But if I just start implementing them in a silo without the rest of my team, that’s not good for my job or the company. Brainstorming sessions are to get buy-in and validate that things I’ve already thought of are viable and will be considered a group effort.
this article has a clickbait title and religiously abides by it when the discussion is much more nuanced. brainstorming is also not just about idea generation. it is a great way of investing the group in ideas that get picked - so it can be treated as a form of consensus seeking theater. this is why measuring the “performance” of brainstorming is largely a fool’s errand.
why does brainstorming often fail to generate new ideas?
any time there is a sufficiently complex calculus involved in solving a problem, solution generation involves understanding that calculus. a brainstorm session must include people that understand the problem and solution spaces well. otherwise, the brainstorming is often useless.
almost all brainstorming sessions i have seen ignore this concept and result in no useful generation and a lot of wasted time.
99 comments
[ 3.5 ms ] story [ 170 ms ] threadOnce we have a list of ideas, then whittle the list down with the realist and pessimistic people of the group; until there's one obvious way forward or a couple of least worse ideas.
Generally most people are better at telling you what you can't do,
People like me also need time and space to think deeply about certain topics, and a brainstorming session has neither time nor space, so you're immediately limited in the ideas that are presented.
Just clearly write out the scope and purpose, timebox it, and collect/record the ideas, no judgement, not even attribution. Then the next time, see if anything converges, evaluate what can be done.
100%. We had anyone who wanted to join, and nobody’s ideas were better than others. One of our most beloved features was one that our EA came up with in such a session, because she didn’t have the context to think it was hard to do. A few days later, we found an easier way to do it, but we’d never even have looked if it weren’t for the humility and collaboration in that room that day.
I've participated in several team programming competitions. The way every team worked was - everybody read all tasks, quickly decide who works on what, and then we work solo on one problem each in parallel, when somebody finishes (s)he can help others who are stuck or take on another tasks. Talking about the problem all the way was way too slow and didn't much helped.
But problem-solving isn't the only creative thinking people do. When creating a story for table-top RPGs brainstorming works great.
In the cited article, sure the faster problem solvers will solve more individually. But
1) the proper grain to measure success is as the team level, and
2) it's easy to score a problem with a known answer, but it is significantly harder for a group to come to consensus as to what the best answer might be – you can't always just crunch the numbers to see who was right.
The advantages of the brainstorm at the team level can be profound: they can reach consensus as to what these better options are, as well as a shared understanding of the problem space and what the next steps are.
[1] https://www.thefountaininstitute.com/blog/what-is-the-double...
I'm glad this was where the author ended up. As I read this, I kept thinking that I know how to get better ideas out of people than a lot of typical brainstorming scenarios I've experienced in the past. My mind kept going back to how good some of the (Agile) retros I've had, and the one thing they all had in common was psychological safety was key. Creating a safe space allowed people to really express their issues, which made it much easier to address them. I've always understood one of the most important actions in a brainstorming session is the "turkey shoot" by one of the seniors. It's an idea so bad that even interns think, oh, my idea is better than that and so find it easier to participate. Without that, you can very much end up with a session dominated by hierarchy.
The value is creating space where the bar for acceptable ideas is so low that people don't self-censor.
https://liberatingstructures.com/
From the quotes by Osborn it seems his purpose for it was to find ideas, no matter how far out there. Whereas the researchers were directing people to use brainstorming to find (what sounds like) one or a small number of viable solutions. Those are two different activities, so an approach could be useful for one and useless (or suboptimal) for the other, but there is no way to conclude how applicable it is to the former based on studies of the latter.
The article should have been called "Stop Brainstorming to Solve Problems". The title is clickbaity. Brainstorming to solve a problem is just team easter-egging.
But for better defined unstructured problems and then turning to novel solutions, it is great.
It bothers me that corporations don't use it that way MORE. And I dearly HATE meetings.
Also, the hip term these days is "ideation" not "brainstorming". Get with the times, boomer. (Just kidding--almost a boomer here)
I think it helps to have weekly-or-so discussions about The Problems We're Having Lately, not so much as "brainstorming" but giving people a chance to offer their latest ideas and explain problems encountered with previous ideas.
I'm Longstorming-the problem-solving technique of coming up with as many ideas as possible in a long period of time
Now I have over 100 startup ideas, it's kind of hard to keep track anymore. But it is interesting how some ideas synergize with each other and can be combined in order to solve bigger problem.
In the brainstorming sessions I've attended, the next stage involves the facilitator taking all of the idea stubs and grouping them together, then riffing on the idea groups. The whole process (intentionally?) feels like improv comedy. And much like improv, it often seems geared more for the enjoyment of the participants than the quality of the output.
And maybe that's ok, using brainstorming purely as a tool to circulate half-ideas and get the creative juices flowing? But in a design sprint, the brainstorming outputs are often directly used for longer term planning. I've found something like a lightweight RFC process is a much better medium for refining and discussing ideas. RFCs are usually written alone, and discussed as a group.
If group brainstorming is top of mind for a lot of executives, it's a good bet that there's way too much of it going on. If a dev team thinks they always do their best work in isolation, they're probably missing out on some major benefits to be had by mixing in more collaboration and pair programming.
[0]https://news.ycombinator.com/item?id=30074949
This is a great rule of thumb, and could likely be applied to itself even, if it become a widespread sentiment.
It's not quite the same thing, but I think there might be a relationship to Goodhart's Law. It may also partially explain why Agile has gone so wrong for so many companies.
I don’t think it’s as big of a deal as it might seem, though. You still need to get together and decide what to do with your team, it just probably should be a safe space is all. We knew that.
Hardly anything works without safety, and nearly anything works with safety. Sounds good to me.
Also, a separate comment to this thread:
Edward De Bono's "Six Thinking Hats" is an alternative way of approaching innovative idea generation.
https://www.debonogroup.com/services/core-programs/six-think...
https://en.wikipedia.org/wiki/Six_Thinking_Hats
There may be narrow use cases where the overhead of brainstorming doesn't add any value; but otherwise, I still believe brainstorming is a good way to consider alternatives for open-ended problems.
Collective >> Individuals or 1+1=3
So yes. If anything can improve your work experience, your productivity , it's psychological safetry
Taken to an extreme it would be sensible to give teams a annual bonus at the start of the year. Give them FU money and so be fairly confident they will say FU when it's needed
I do think the author's final point about psychological safety is a good one.
The important thing is that they have convinced themselves that it makes sense.
You don’t even have to lie. You can go into a meeting as a lead and say that you have an idea of how something might look but you want the group to come up with a design anyway.
Not to dismiss the psychological safety point the article makes, which i believe is very valid.
Brainstorming tries to achieve an unstructured creative session whereas engineering teams are trying to flesh out a structured plan to a complex problem.
Not all whiteboarding in a group is brainstorming. The former usually results in tremendous added value while with the latter I agree it's mostly pointless.
IME, brainstorming sessions don't really serve that purpose except when they actually do result in real substantive collaboration. While people may have tribal identity as part of a team, they also tend to be aware of the group dynamics in the team and how decisions are actually made.
But, IME, lot of people in lead and management positions buy into the effectiveness of brainstorming sessions as tools of forging shared fictions in ways which are supported by the way people on the team look at the output.
Almost zero of the brainstorming meetings I've ever attended were of the kind "How do we solve the well-defined problem X", and were almost exclusively of the kind "What do we want to do in the area of <subject>?" or "Can we agree on needs to be solved, and deal out problems to individuals?".
Brainstorming might be a throwback term, but it works.
why does brainstorming often fail to generate new ideas? any time there is a sufficiently complex calculus involved in solving a problem, solution generation involves understanding that calculus. a brainstorm session must include people that understand the problem and solution spaces well. otherwise, the brainstorming is often useless.
almost all brainstorming sessions i have seen ignore this concept and result in no useful generation and a lot of wasted time.
The second trick is to have only people that are comfortable with each other in the room.