> "I haven't heard any customers request this." "We can't use Python for that, it's too slow." "That introduces too much complexity." "We tried something like that before and it didn't work." "DevOps won't want to support another service." "People are used to the way it works now."
> None of these people are wrong or stupid. And none of them have added any value.
Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
No customers requested this? Prove that there is a market that wants it.
Can't use Python because it's too slow? Show a proof of concept that is fast.
Too much complexity? Demonstrate that it's the minimum amount of complexity to achieve all the requirements.
Tried it before unsuccessfully? Explain what's changed since then.
DevOps won't want to support it? Burn down the company and start again: you've managed to undo everything that the word "DevOps" is supposed to convey.
People don't want change? Nah, people like change when it is obvious to them that the change is good. People don't want bad changes, and their justifiable default assumption is that a new change is a bad change. You'll need to overcome that.
And if you can't convince these acknowledged correct-and-smart naysayers, then be glad you didn't chase that rabbit. Come up with a new idea tomorrow.
There is value in critically evaluating ideas and possible endeavors. On the other hand, demanding an answer to every little pocket of uncertainty creates a huge burden that prevents exploration. It's one thing to be exhaustive in the criticism by examining individual scenarios, evaluating cost benefit in a measurable way, etc. That doesn't seem to be what the author is describing. He's describing critical & low effort cheap shots.
The examples he used included: the plan depends on a different team providing labour and that team is not on board, the business plan for the idea does not make sense.
I suppose they are low effort in the sense that they are very basic 101 criticisms, but i wouldn't call them cheap shots.
Literally no plan is ever going to work if it involves the labour of others without their (or their supperiors) consent. It seems to me a very valid criticism to make. That doesn't mean its the end of the idea, it means you need to have a plan to either get the other stakeholders on board, or a plan to do it without them.
It's not a plan, it's an idea. You're shooting down an idea for not being a plan. The best person for coming up with the idea will probably also come up with some of the pieces of the plan, but they're unlikely to be the best person to figure out all of it. That's why you have a company not a sole proprietorship.
The problem with this is, that the article literally says:
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
If they did that much upfront work, it's more than an idea. And if it's that easily shot down, they should have done even more upfront work and probably slowly gotten others involved.
Honestly, it sounds like someone so desperate for credit, so worried that someone will steal the idea, that they feel compelled to unveil it in a large gathering that was convened for some other purpose. And that never goes well.
Ideas truly are a dime a dozen. If one gets shot down, then you can reflect whether that was warranted, and try again with the same idea if not.
If you're really emotionally invested in it, as the guy writing the article seems to be, then you damn well better have more than just an idea, and you should understand enough about human nature to slowly try to bring individuals onboard to help before you put it out in front of a big crowd.
> You're shooting down an idea for not being a plan.
If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's time.
Like maybe its a bit different if you are brainstorming for an acknowledged problem, but that is not what the article made it sound like.
The article made it sound like the idea was being pitched unsolicited, with no clear problem it was trying to solve and no clear plan on how to do it. After all 2 of the so-called cheap criticisms were people asking why we want to do this ("the customers aren't asking for it") and how are we going to do it when it has dependencies on stakeholders who have not bought in ("devops doesnt like it").
Why would anyone care about such an idea? Like if you want to work on something by yourself, you dont have to convince anyone, but if you want other people on board, you are going to have to answer basic questions. Questions like: what benefit would implementing this idea bring me, and will my effort on this idea be a waste because neccesary stakeholders aren't on board.
There are a lot of details that can be sorted out on the way. Things like, why would we even want to do this in the first place, is not one of them.
And shooting down shit is also valuable. It is fine to have ideas without thinking them through, and it is also fine to criticize those ideas without thinking through the criticism. That is how we figure out how the ideas could work.
No one should care about devops’s consent when they’re given a work item that comes from someone higher up on the org chart. Their consent is willful employment. Similarly, no one should care about an engineer’s consent when given a work item in a similar context.
If the engineer proposes an implementation the devops team doesn’t like, the devops team should come up with a counter proposal that still fulfills their requirements. And if their counter proposal fulfills the requirements but the engineer objects, then whoever’s at the top of both their branches in the org chart should be making the decision.
These are all risks. Not all risks need to be mitigated, but some can be. Others can be accepted. Saying “Python is too slow for production scale, but our goal is a small proof of concept,” is a valid answer even if it doesn’t “solve” the complaint. And if you don’t even have that answer, then the burden is not your problem. The lack of due diligence is.
>Ideas need time to be explored, and given a chance.
sure, and the time for that is before you bring them to potential critics.
unless a meeting is intended as a brainstorming session where any thought, no matter how unformed, is welcome, meetings are not a time to present your initial unexplored thoughts to colleagues, bosses, or other departments. take a couple days, think about it without spending other people's time, try to imagine people's objections and have answers to them. then present. shouting things out in a meeting before you've considered and come up with answers to the most obvious counter-arguments is just a time-waster.
You must have very different kinds of meetings than I do. Unless you're going into that meeting with a rehearsed PowerPoint presentation, or there's a strict agenda that doesn't allow any time for exploration, I expect to hear imperfect-ideas-in-infancy. One of the reasons we have meetings is to allow collaboration to happen. It's a format for working together.
Yes, meetings vary profoundly in terms of their quality, purpose, and participation. For instance, is it a meeting of peers, or are managers in the room? If there's a large disparity of roles in attendance (e.g., junior engineers, marketing managers, and maybe one or two executives), it's different than if it's a true meeting of peers. And if managers are capable of attending those meetings without quashing collaboration, hats off to them.
Really depends on the context I think, brainstorming session? Naysaying does have a habbit of stunting an idea's growth in the session. Sometimes you need to imagine you've solved a bunch of hard problems before you can explore the value the idea has.
I say this as a semi-reformed naysayer. I am critical of implementation plans, but let ideas breath a bit in a more exploratory setting before I start bringing up constraints.
If the proof of concept takes an hour to code up, or proving the market exists just takes a bit of googling, then sure, you can prepare that before the first meeting where you suggest the idea.
If the proof of concept requires spending a few days in the machine shop making jigs and parts, purchasing equipment, and a custom PCB, then I really hope you'll bring it up for discussion beforehand in a meeting. Ten minutes of discussion with colleagues might be as useful as several iterations of prototyping. Not so that they'll shoot it down, but because someone might say "oh yeah, we have a spare mcguffin from last year's demo that you can use, should save you lots of time."
With all due respect, if the idea is good, then it will happen. The proposer of the idea needs to nurture it and part of that is defending it.
When someone is super optimistic and comes forward with an idea where:
- it's actually just a half baked solution for something I already tried to solve 4 years ago
- I'm acutely aware of all the spots it will fall
- they still think it can work, when it really really honestly can not
- they lack the experience to see that it won't work and become frustrated when I point out 20 problems with it and why it's not worth pursuing further
^ what exactly am I supposed to do with the above? You can take the advice/critique or leave it, but if I'm supposed to try to help and nurture a dead end instead of telling you the issues with it, that makes no sense to me.
Funny story. I get called an “idea killer,” because I say things like “The hinge is probably going to wear out. We should figure out how to deal with it.”
That makes me a “negative naysayer.”
I’ve learned to just shrug, and walk away from a lost cause. Sometimes, if I care enough, I can have some remedy ready for when the wheels come off. I can do that, because I’m retired. It’s not so easy, if it’s your job; especially when the hinge wears out, and they throw you under the bus for it.
As an engineer, it has always been my job, to Make Things Happen. Not to prevent them from happening. We usually get paid well, because we do difficult things.
We are going to see some real vibe-coding disasters, in the next few years, but the “negative naysayers” that learn to leverage the new tech, will do some pretty awesome stuff.
Strongly disagree. The best teams I’ve been on were the ones in which someone gave a shit enough to articulate why I, or someone more senior, was speaking baloney.
The "what to do instead" section is basically DARPA's "Heilmeier Catechism," which is the framework they use to gauge high-risk high-reward ideas. It doesn't kill ideas, but it places the onus on the proposer to be clear-eyed and explicit about what they're putting forward:
What are you trying to do? Articulate your objectives using absolutely no jargon.
How is it done today, and what are the limits of current practice?
What is new in your approach and why do you think it will be successful?
Who cares? If you are successful, what difference will it make?
What are the risks?
How much will it cost?
How long will it take?
What are the mid-term and final “exams” to check for success?
The RSA algorithm was named after its creators: Adleman, Rivest, Shamir.
Their initials were ordered "RSA" to reflect that Adleman was the "shoot it down" guy: "Rivest and Shamir, as computer scientists, proposed many potential functions, while Adleman, as a mathematician, was responsible for finding their weaknesses."
The least productive teams I've been a part of are the ones where everyone is waiting for their turn to say why an idea is bad. Sometimes being "too smart" can hold you back from building something genuinely new.
Try sheltering every "idea" on an open source issue tracker and report back with a nervous breakdown in a year.
Most ideas are stupid and don't work. Startup ideas are increasingly stupid and only work because many startups are know to fail by the investors but used as a vehicle to transport money from A to B with plausible deniability.
> It takes five minutes to explain how an idea could open up a new market segment. It takes two seconds to say "that sounds risky." But in a meeting, the two feel equivalent.
In what world do these sound equivalent? Simply saying that something “sounds risky” is not serious criticism and wouldn’t hold any weight at any place I’ve ever worked at. You would have to actually explain why it sounds risky and point to something tangible.
If you happen to work at a company of even a moderate size, but particularlly a large company, here's some free advice.
Never point out the problems. There is literally no upside to doing this and plenty of downside. You will be labelled "Mr/Ms Negative". When you are inevitably proven right, you won't be thanked or heeded on future predictions. Instead you will be get feedback and comments about "not being a team player".
This is doubly true if it's in the context of a meeting. What many don't realize is that meetings aren't for feedback or criticism or for changing course. All of those decisions have already happened. The meeting is just there to make official what's already been decided.
If you truly want to influence the outcome, you do it 1:1 and outside meetings. And you create a paper trial so you're not the one left standing then the music stops.
The people who say "shooting down ideas is not a skill" are wrong but it doesn't matter because they somehow rise to positions of leadership anyway and create these toxic environments where the only two outcomes are that they were right or you failed.
Seems like "shooting down ideas" here is just "criticism of my idea whose framing hurts my feelings". If you want to light a fire with wet wood and cry because someone points that out, you probably lack the grit to execute anyway. Nobody owes you a sugarcoated explanation of the ways your idea is shit. Grow up.
>In a way this is virtuous, because I think startups are a good thing. But really what motivates us is the completely amoral desire that would motivate any hacker who looked at some complex device and realized that with a tiny tweak he could make it run more efficiently. In this case, the device is the world's economy, which fortunately happens to be open source.
After a while you learn to ignore criticism. I'm not really interested in what people have to say who would never become users anyway. They're simply not the demographic. It's all noise, and when I was younger and more impressionable it caused serious self-doubt. But when I demo something and I see the eyes light up, and then they say "well, what about this?", that's pure gold.
If you have an idea and believe in it but it's getting shot down create a DACI/RFC. This is initially playing chess with yourself to see if it is a good move. Once done (and if the idea survives that without a pivot or abort) you now have a document other team members can comment on. You cam refine etc.
This is good for day to day ideas and innivation. Moonshots probably need something else which I am not sure what to propose. Other than POC with some numbers to get more explore time.
I often mention that I worked for a storied Japanese company. It was the majority of my career.
They used to have a lot of meetings. One of those meetings was called a “Design Review” meeting, or “DR.”
This was a big meeting, involving multiple departments, and usually involved hard-bitten, intelligent, and frequently, curmudgeonly, engineers, scientists, and managers.
It was their job to shoot holes in your proposal.
Making a presentation to a DR was a stressful thing, but it was also a highly effective forge. What came out of the meeting, was a robust, achievable project, with a solid plan, funding, and “on the record” support from all the teams involved. The idea would have real “legs.”
When you ask others to support your idea, you had damn well better expect them to be skeptical, and it’s a mistake to think of their skepticism as opposition. They often want to help you to make it happen, and anticipating problems, is a very important part of that.
Soooo, either this is a low-effort initial spitball, or it's something bigger that probably should have been broached separately.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
Ohhh, something bigger. Why would you first propose it in a meeting? If the meeting is about something else, it's probably not the right forum. If the meeting was called about this particular idea, then (a) if you really did all that work up front, you probably should have shared first, and (b) you really should be able to anticipate and have answers for the most likely criticisms.
Seriously, doing a bunch of upfront work and then trying to present it as a fait accompli in a meeting to a bunch of people who have never seen it or thought about it is never going to go well.
And whining about the fact that it didn't go well on the internet just makes it obvious that you still don't have any clues about human nature.
Look, you are right that there is often resistance to new ideas. But you are not going to alter human nature, and the right way to get your ideas across is obviously a different approach than the one that you chose.
> Shooting down ideas is easy. The hard part is sheltering the flame long enough to see what it becomes.
As other commenters have discussed, this is simply wrong.
But even more than that, this sentiment, and your whole post say much more about you than the others who you denigrate for "shooting ideas down."
Your attempt to "teach" others about this moment proves that you, yourself, did not learn the correct lessons from it.
It's definitely a skill. Perverting the organization into a support ecosystem for naysayers is not a trivial thing. It often takes years of meticulous, behind-the-scenes manipulation before these people can begin to reliably suppress ideas without getting called out.
Shooting down ideas is absolutely a skill, and it's essential to driving out the mountains of slop people throw out these days.
However, the essential thing to do is to make sure that you're not shooting down the person. Better still, if you can socratically get them to the point of understanding why their idea won't work, that will have them own the shoot-down, and it may lead to a better idea that addresses the actual problem set more effectively.
When you know why something won't work, get other people there, but do it without being a jerk or crushing in inventive spirit.
I've been leading advanced development and applied science teams for decades. There aren't enough hours in the week to give every idea someone brings to me a full watch-them-realize shake, but I can (and do) take the time to make sure that the next time they have an interesting idea, they still want to bring it up.
Shooting down ideas is absolutely a skill; one that every innovator needs to have for their own ideas and the ideas of their collaborators. The way I learned it was to have others shoot my ideas down, and that's the way I teach it.
At some point you just have to spend spare cycles on ideas you think matter. What's harder than rejecting an idea is rejecting a finished, working product. And if your team says "I wish you had worked on something else", that's great, but if you're not my boss and and they're happy, who cares? And sometimes even your bosses. If you believe in something hard enough you will build political capital by meeting work obligations and spend it down working on your baby.
“ The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.”
This is just not true in my experience, and doubly so after the advent of LLMs.
I've seen more half-baked ideas presented than thorough plans.
I think what most successful people do is avoid getting in situation where they have to ask for permission to do things. While there may sometimes be legitimate gate keepers that stop you, be careful not to create a gatekeeper out of people that don't care one way or the other. Just go ahead and do it if you can.
Meh, those who don't learn from history are doomed to repeat it.
You shouldn't listen to every nay-sayer. Sometimes criticism is not convincing and it can be a skill separating out useful criticism from unconvincing criticism. However if someone did X in the past and ran into problem Y, you should probably have an answer to why Y is not a problem for your use case or what you plan to do differently to avoid Y.
If your good idea is so lame it can't even take the tiniest bit of criticism, its probably not a good idea.
Like in the article, the criticism seems pretty valid but they aren't really about the idea. If the criticism is that DevOps doesn't want to do it [do you just mean ops? Isnt this the opposite of the concept of devops?], that is not a criticism of your idea, that is a criticism of you failing to get stakeholders on board who you plan to rely on. If the criticism is "i haven't heard customers request this" that is code for you failed to make a compelling business case for your idea. Those are criticisms of you not your idea.
Where to start. The process I see work well in practice is.
1. Generate an idea.
2. Let critics help identify flaws.
3. If it's unsalvageable give up. Otherwise, modify the idea and go to (1).
This works well in a collaborative environment where people share ideas early.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
Assuming this blog post is based on real world experience, I want to point out that this describes a very slow feedback loop, and it's not necessarily typical or a good thing.
This is how we get 'design by committee', where no one wants to shoot ideas down and there is no vision. Sometimes ideas should be shot down. I would go so far as to say that most ideas should be. Very few people are discovering how to make fire.
I see this happening in modern day politics when it comes to critiquing tech.
For instance, consider AI data centres in space: look, everyone knows its a high risk bet. If you do the easy thing of shooting it down, you may "win" the bet often enough. But try to understand that the world works by taking bold bets - each thing you see is a bold bet, not coming from a planned economy. I see my own laptop - the processor, the internet, the screen - everything was a bold bet at one point.
Shooting down ideas is easy and temporarily confers high status on you (since you win the bet more often than not) but in the long run such a game will show itself as ridiculous.
It depends on the team (ie stupid ideas can def sidetrack you) your working with but the principles of Improv carry over generally to creativity- if someone suggests something go with it and see where it takes you - never say No
I agree with some parts but I mostly don't see the point of this article: shooting down ideas is a skill in academia, in industry, in fields where decisions have huge opportunity costs. One needs to shoot down ideas pretty often, because really good ideas are only a handful.
Things that are really worth someone's time are often something that should be well thought out, stress-tested, collectively agreed upon by at least a few. So shoot the unfeasible ones bang on so you don't waste time on it. Just don't make it personal; it's only ideas that need judgement, not the people.
I wrote below comment when I read 20% of this article, like a person shooting everything down. But the more I read, the more I enjoy.
Thanks for pointing out that inherent physiological flaw in humans, it's hard to realize that, this is very meaningful.
"""
> None of these people are wrong or stupid. And none of them have added any value.
Different opinions and more experience on current topic bring some value.
"""
Maybe it's an conflict in wording, but what is even an idea?
I think the article doesn't try to figure it out, but frames the word as an self sufficient concept that is ultimately good. But it's not. A child could have the idea to see what happens if it touches a hotplate. It is certainly a personal lesson, but just because it's an "idea" it's not something that you should always explore.
^OP if you read this, may I suggest you change the title of the post to "Let 'em cook". Let's assume that shooting down ideas is in fact a skill in the game of work (think prisoner's dilemma). An alternative skill is to play along. "No, because.." becomes "Yes, and..". Improvising off one another is how to play along
There's a gap in communication and vision here. The people on either side believe themselves to be the one who sees and understands more, because anything beyond what you see or understand is out of your consideration, so it's natural to only focus on what you know that the other side doesn't instead of what you don't know that the other side does.
I've met some people in my professional life where they shoot down virtually every single idea that come across them. And as a result they were right sometimes, never made a bug, and made the team around them extremely slow.
I will gladly shoot down any idea for unnecessary complexity and unnecessary feature, but otherwise it's "where's the demo"?
Show, don’t tell. Rather than doing human ceremony around product features, just make it instead. Cost of communication and coordination has increased dramatically relative to what it takes to crank out code. And you get to have some tangible results, skills and deep domain knowledge even if it is discarded later.
The best systems incorporate an adversarial element because this makes them robust to problems and attacks. Science, democracy, freedom of expression culture, etc. are antifragile because of this.
Rejecting criticism makes systems more fragile.
Of course it's a balance and you also need to nurture new ideas.
Feels like the author was still stinging from a personal experience and rushed to write a blog post about it before he fully digested the encounter or thought about the implications of this knee-jerk "objections have no value" emotion.
This article commits exactly the sin that it claims to warn against. It has obligatory positive statements about the value of critical thinking, surrounded by highly disparaging comments about how people practicing critical thinking in good faith are not adding value. The net effect will be to discourage the healthy development of critical thinking practice.
Taking generic potshots at critical thinking is not a skill.
The article has good advice. The idea of postponing critique for a little bit to give an idea a chance to breathe, for instance. But then it also comes in with insulting BS like “Shooting down ideas is not a skill.” The whole article is obviously about improving one’s skill at the positive practice of culling bad ideas. Why throw such shade with the title?
The ignorant practice of refusing to consider an idea is not the same as critical thinking. Critical thinkers already feel bad about bringing rain to the parade. Do you have to make them feel even worse about it?
176 comments
> "I haven't heard any customers request this." "We can't use Python for that, it's too slow." "That introduces too much complexity." "We tried something like that before and it didn't work." "DevOps won't want to support another service." "People are used to the way it works now."
> None of these people are wrong or stupid. And none of them have added any value.
Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
No customers requested this? Prove that there is a market that wants it.
Can't use Python because it's too slow? Show a proof of concept that is fast.
Too much complexity? Demonstrate that it's the minimum amount of complexity to achieve all the requirements.
Tried it before unsuccessfully? Explain what's changed since then.
DevOps won't want to support it? Burn down the company and start again: you've managed to undo everything that the word "DevOps" is supposed to convey.
People don't want change? Nah, people like change when it is obvious to them that the change is good. People don't want bad changes, and their justifiable default assumption is that a new change is a bad change. You'll need to overcome that.
And if you can't convince these acknowledged correct-and-smart naysayers, then be glad you didn't chase that rabbit. Come up with a new idea tomorrow.
> He's describing critical & low effort cheap shots.
The examples he used included: the plan depends on a different team providing labour and that team is not on board, the business plan for the idea does not make sense.
I suppose they are low effort in the sense that they are very basic 101 criticisms, but i wouldn't call them cheap shots.
Literally no plan is ever going to work if it involves the labour of others without their (or their supperiors) consent. It seems to me a very valid criticism to make. That doesn't mean its the end of the idea, it means you need to have a plan to either get the other stakeholders on board, or a plan to do it without them.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
If they did that much upfront work, it's more than an idea. And if it's that easily shot down, they should have done even more upfront work and probably slowly gotten others involved.
Honestly, it sounds like someone so desperate for credit, so worried that someone will steal the idea, that they feel compelled to unveil it in a large gathering that was convened for some other purpose. And that never goes well.
Ideas truly are a dime a dozen. If one gets shot down, then you can reflect whether that was warranted, and try again with the same idea if not.
If you're really emotionally invested in it, as the guy writing the article seems to be, then you damn well better have more than just an idea, and you should understand enough about human nature to slowly try to bring individuals onboard to help before you put it out in front of a big crowd.
> You're shooting down an idea for not being a plan.
If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's time.
Like maybe its a bit different if you are brainstorming for an acknowledged problem, but that is not what the article made it sound like.
The article made it sound like the idea was being pitched unsolicited, with no clear problem it was trying to solve and no clear plan on how to do it. After all 2 of the so-called cheap criticisms were people asking why we want to do this ("the customers aren't asking for it") and how are we going to do it when it has dependencies on stakeholders who have not bought in ("devops doesnt like it").
Why would anyone care about such an idea? Like if you want to work on something by yourself, you dont have to convince anyone, but if you want other people on board, you are going to have to answer basic questions. Questions like: what benefit would implementing this idea bring me, and will my effort on this idea be a waste because neccesary stakeholders aren't on board.
There are a lot of details that can be sorted out on the way. Things like, why would we even want to do this in the first place, is not one of them.
>
If you are pitching an idea out of nowhere, than i think it better have a semblence of a plan, otherwise you are just wasting everyone's timeDepends on context. Shooting the shit is valuable.
If the engineer proposes an implementation the devops team doesn’t like, the devops team should come up with a counter proposal that still fulfills their requirements. And if their counter proposal fulfills the requirements but the engineer objects, then whoever’s at the top of both their branches in the org chart should be making the decision.
Ideas need time to be explored, and given a chance.
>Ideas need time to be explored, and given a chance.
sure, and the time for that is before you bring them to potential critics.
unless a meeting is intended as a brainstorming session where any thought, no matter how unformed, is welcome, meetings are not a time to present your initial unexplored thoughts to colleagues, bosses, or other departments. take a couple days, think about it without spending other people's time, try to imagine people's objections and have answers to them. then present. shouting things out in a meeting before you've considered and come up with answers to the most obvious counter-arguments is just a time-waster.
> Ideas need time to be explored, and given a chance.
Then go back, address the objections, and re-propose.
If you can't explain at least a little bit of "why this is worth at least digging into", that's on you.
Ideas are cheap. Everyone has them.
I owe it to my colleagues to not make them the bad guys by shooting down an idea.
I say this as a semi-reformed naysayer. I am critical of implementation plans, but let ideas breath a bit in a more exploratory setting before I start bringing up constraints.
If the proof of concept requires spending a few days in the machine shop making jigs and parts, purchasing equipment, and a custom PCB, then I really hope you'll bring it up for discussion beforehand in a meeting. Ten minutes of discussion with colleagues might be as useful as several iterations of prototyping. Not so that they'll shoot it down, but because someone might say "oh yeah, we have a spare mcguffin from last year's demo that you can use, should save you lots of time."
If you really believe in an idea, even if you first put it forward to the wrong hostile audience, you will have other opportunities to make your case.
LLM's are an endless source of bad code ideas. Being able to sift through them and find the gems is the exhausting way to be productive.
I agree with the general premise that it is easy to shoot down ideas without thinking. But it's also easy to propose ideas without thinking.
Both are disrespectful if disproportionate to the effort of the other.
The core is not idea generation versus critique. It's the effort spent on each.
When someone is super optimistic and comes forward with an idea where:
- it's actually just a half baked solution for something I already tried to solve 4 years ago
- I'm acutely aware of all the spots it will fall
- they still think it can work, when it really really honestly can not
- they lack the experience to see that it won't work and become frustrated when I point out 20 problems with it and why it's not worth pursuing further
^ what exactly am I supposed to do with the above? You can take the advice/critique or leave it, but if I'm supposed to try to help and nurture a dead end instead of telling you the issues with it, that makes no sense to me.
That makes me a “negative naysayer.”
I’ve learned to just shrug, and walk away from a lost cause. Sometimes, if I care enough, I can have some remedy ready for when the wheels come off. I can do that, because I’m retired. It’s not so easy, if it’s your job; especially when the hinge wears out, and they throw you under the bus for it.
As an engineer, it has always been my job, to Make Things Happen. Not to prevent them from happening. We usually get paid well, because we do difficult things.
We are going to see some real vibe-coding disasters, in the next few years, but the “negative naysayers” that learn to leverage the new tech, will do some pretty awesome stuff.
What are you trying to do? Articulate your objectives using absolutely no jargon.
How is it done today, and what are the limits of current practice?
What is new in your approach and why do you think it will be successful?
Who cares? If you are successful, what difference will it make?
What are the risks?
How much will it cost?
How long will it take?
What are the mid-term and final “exams” to check for success?
https://www.darpa.mil/about/heilmeier-catechism
> The person proposing has been thinking about this for weeks or months.
This doesn't mean they know what they're doing. Their thoughts can be bad.
Their initials were ordered "RSA" to reflect that Adleman was the "shoot it down" guy: "Rivest and Shamir, as computer scientists, proposed many potential functions, while Adleman, as a mathematician, was responsible for finding their weaknesses."
Well, so the story goes.
Who would want to hide their secrets in ARS?
Most ideas are stupid and don't work. Startup ideas are increasingly stupid and only work because many startups are know to fail by the investors but used as a vehicle to transport money from A to B with plausible deniability.
> It takes five minutes to explain how an idea could open up a new market segment. It takes two seconds to say "that sounds risky." But in a meeting, the two feel equivalent.
In what world do these sound equivalent? Simply saying that something “sounds risky” is not serious criticism and wouldn’t hold any weight at any place I’ve ever worked at. You would have to actually explain why it sounds risky and point to something tangible.
Never point out the problems. There is literally no upside to doing this and plenty of downside. You will be labelled "Mr/Ms Negative". When you are inevitably proven right, you won't be thanked or heeded on future predictions. Instead you will be get feedback and comments about "not being a team player".
This is doubly true if it's in the context of a meeting. What many don't realize is that meetings aren't for feedback or criticism or for changing course. All of those decisions have already happened. The meeting is just there to make official what's already been decided.
If you truly want to influence the outcome, you do it 1:1 and outside meetings. And you create a paper trial so you're not the one left standing then the music stops.
The people who say "shooting down ideas is not a skill" are wrong but it doesn't matter because they somehow rise to positions of leadership anyway and create these toxic environments where the only two outcomes are that they were right or you failed.
>In a way this is virtuous, because I think startups are a good thing. But really what motivates us is the completely amoral desire that would motivate any hacker who looked at some complex device and realized that with a tiny tweak he could make it run more efficiently. In this case, the device is the world's economy, which fortunately happens to be open source.
After a while you learn to ignore criticism. I'm not really interested in what people have to say who would never become users anyway. They're simply not the demographic. It's all noise, and when I was younger and more impressionable it caused serious self-doubt. But when I demo something and I see the eyes light up, and then they say "well, what about this?", that's pure gold.
[0] https://paulgraham.com/whyyc.html
A important word doing a lot of lifting here is "doing". talk is cheap, the problem is never lack of ideas.
This is good for day to day ideas and innivation. Moonshots probably need something else which I am not sure what to propose. Other than POC with some numbers to get more explore time.
They used to have a lot of meetings. One of those meetings was called a “Design Review” meeting, or “DR.”
This was a big meeting, involving multiple departments, and usually involved hard-bitten, intelligent, and frequently, curmudgeonly, engineers, scientists, and managers.
It was their job to shoot holes in your proposal.
Making a presentation to a DR was a stressful thing, but it was also a highly effective forge. What came out of the meeting, was a robust, achievable project, with a solid plan, funding, and “on the record” support from all the teams involved. The idea would have real “legs.”
When you ask others to support your idea, you had damn well better expect them to be skeptical, and it’s a mistake to think of their skepticism as opposition. They often want to help you to make it happen, and anticipating problems, is a very important part of that.
https://littlegreenviper.com/problems-and-solutions/
> Someone proposes an idea in a meeting.
Soooo, either this is a low-effort initial spitball, or it's something bigger that probably should have been broached separately.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
Ohhh, something bigger. Why would you first propose it in a meeting? If the meeting is about something else, it's probably not the right forum. If the meeting was called about this particular idea, then (a) if you really did all that work up front, you probably should have shared first, and (b) you really should be able to anticipate and have answers for the most likely criticisms.
Seriously, doing a bunch of upfront work and then trying to present it as a fait accompli in a meeting to a bunch of people who have never seen it or thought about it is never going to go well.
And whining about the fact that it didn't go well on the internet just makes it obvious that you still don't have any clues about human nature.
Look, you are right that there is often resistance to new ideas. But you are not going to alter human nature, and the right way to get your ideas across is obviously a different approach than the one that you chose.
> Shooting down ideas is easy. The hard part is sheltering the flame long enough to see what it becomes.
As other commenters have discussed, this is simply wrong.
But even more than that, this sentiment, and your whole post say much more about you than the others who you denigrate for "shooting ideas down."
Your attempt to "teach" others about this moment proves that you, yourself, did not learn the correct lessons from it.
However, the essential thing to do is to make sure that you're not shooting down the person. Better still, if you can socratically get them to the point of understanding why their idea won't work, that will have them own the shoot-down, and it may lead to a better idea that addresses the actual problem set more effectively.
When you know why something won't work, get other people there, but do it without being a jerk or crushing in inventive spirit.
I've been leading advanced development and applied science teams for decades. There aren't enough hours in the week to give every idea someone brings to me a full watch-them-realize shake, but I can (and do) take the time to make sure that the next time they have an interesting idea, they still want to bring it up.
Shooting down ideas is absolutely a skill; one that every innovator needs to have for their own ideas and the ideas of their collaborators. The way I learned it was to have others shoot my ideas down, and that's the way I teach it.
This is just not true in my experience, and doubly so after the advent of LLMs. I've seen more half-baked ideas presented than thorough plans.
You shouldn't listen to every nay-sayer. Sometimes criticism is not convincing and it can be a skill separating out useful criticism from unconvincing criticism. However if someone did X in the past and ran into problem Y, you should probably have an answer to why Y is not a problem for your use case or what you plan to do differently to avoid Y.
If your good idea is so lame it can't even take the tiniest bit of criticism, its probably not a good idea.
Like in the article, the criticism seems pretty valid but they aren't really about the idea. If the criticism is that DevOps doesn't want to do it [do you just mean ops? Isnt this the opposite of the concept of devops?], that is not a criticism of your idea, that is a criticism of you failing to get stakeholders on board who you plan to rely on. If the criticism is "i haven't heard customers request this" that is code for you failed to make a compelling business case for your idea. Those are criticisms of you not your idea.
1. Generate an idea. 2. Let critics help identify flaws. 3. If it's unsalvageable give up. Otherwise, modify the idea and go to (1).
This works well in a collaborative environment where people share ideas early.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
Assuming this blog post is based on real world experience, I want to point out that this describes a very slow feedback loop, and it's not necessarily typical or a good thing.
For instance, consider AI data centres in space: look, everyone knows its a high risk bet. If you do the easy thing of shooting it down, you may "win" the bet often enough. But try to understand that the world works by taking bold bets - each thing you see is a bold bet, not coming from a planned economy. I see my own laptop - the processor, the internet, the screen - everything was a bold bet at one point.
Shooting down ideas is easy and temporarily confers high status on you (since you win the bet more often than not) but in the long run such a game will show itself as ridiculous.
It takes some wisdom
Things that are really worth someone's time are often something that should be well thought out, stress-tested, collectively agreed upon by at least a few. So shoot the unfeasible ones bang on so you don't waste time on it. Just don't make it personal; it's only ideas that need judgement, not the people.
Thanks for pointing out that inherent physiological flaw in humans, it's hard to realize that, this is very meaningful.
""" > None of these people are wrong or stupid. And none of them have added any value. Different opinions and more experience on current topic bring some value. """
I think the article doesn't try to figure it out, but frames the word as an self sufficient concept that is ultimately good. But it's not. A child could have the idea to see what happens if it touches a hotplate. It is certainly a personal lesson, but just because it's an "idea" it's not something that you should always explore.
I've met some people in my professional life where they shoot down virtually every single idea that come across them. And as a result they were right sometimes, never made a bug, and made the team around them extremely slow.
I will gladly shoot down any idea for unnecessary complexity and unnecessary feature, but otherwise it's "where's the demo"?
Rejecting criticism makes systems more fragile.
Of course it's a balance and you also need to nurture new ideas.
Your boss is presenting something that affects you, or someone adjacent is presenting an idea for something that will affect you.
Or if someone asks what you think.
Doesn't that solve most of the complaints about productivity in this thread?
Not in agreement one bit.
Taking generic potshots at critical thinking is not a skill.
The article has good advice. The idea of postponing critique for a little bit to give an idea a chance to breathe, for instance. But then it also comes in with insulting BS like “Shooting down ideas is not a skill.” The whole article is obviously about improving one’s skill at the positive practice of culling bad ideas. Why throw such shade with the title?
The ignorant practice of refusing to consider an idea is not the same as critical thinking. Critical thinkers already feel bad about bringing rain to the parade. Do you have to make them feel even worse about it?