^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
> "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.
> 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.
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.
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.
These are the table stakes of uncertainty, not delving into every little pocket. If the language and ops are under question, this sounds like an entire new project or significant extension. The bit of time it takes to answer all those questions is worth it.
You can fire the shot and then patch the hole at the same time, proposing solutions to the same problem you pointed out, rather than just shooting and letting one person handle defense from every attack.
By proceeding with things that will gather more data—such as prototyping, or further independent research—vs spinning indefinitely on "hypothetical" discussion-only shots.
How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?
>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."
That all sounds fine if they're not the kind of naysayers that will just let the company collapse around them rather than risk putting one of their own ideas out there on the chopping block. All too often nothing is the worst thing we can do, and there are a lot of professional do-nothings out there.
> Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
Power assymetry and tenure are a factor. So is "culture eats strategy for breakfast" realities in organizations.
e.g. Change of pandemic messaging in early 2020 from "covid transmits by droplets and fomites and 2 meters and handwashing keep you safe" to "covid is airborne and fills a room like smoke" (and multiple mitigations around that) was attempted in groups by multiple expert scientists and ultimately took years when it needed to be done fast. One key moment: https://www.google.com/search?q=%22where+is+your+evidence+li... You can come with evidence for those tough questions to support your position, but one grandee scoffs at your suggestion in the meeting you networked hard to get and there's no recovery.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with more or less everything but this one.
I would modify it.
People don't want change? Nah, people like change when it is obvious to them that the change is good for them personally.
You can introduce a change that would be great for the organization and customers, but totally eliminate the current project a team has been working on unsuccessfully for years. You will be shot down no matter how good your idea is. And many times, there is no way to turn it into a "win" for the team that you need to win over to your side due to politics.
So shooting down ideas - for that team - is indeed a skill. A self-preservation skill. I've seen teams able to employ this skill for nearly a decade where it was obvious to any outside observer there were numerous ideas that would eliminate their need to exist altogether.
the "good for them personally" reaction is so true. It's almost like a team-level version of the inonvator's dilemma, where protecting the thing you already own feels more rational than supporting something that might replace it.
you're right that a good idea should be able to survive scrutiny. The issue I'm describing isn't "someone asked a tough question". It's when objections pile up so ast that nothing can survive long enough to be properly evaluated. That's not a rigorous process, that's just a kill zone. The difference between a productive and unproductive kill zone comes down to culture. Teams that default to "here's why it won't work" end up very efficient at producing nothing. The teams I've seen do this well still kill ideas but they just do it after giving them a fair shot. The proposer has to do their homework but the environment has to let them get far enough to do it.
> Can't use Python because it's too slow? Show a proof of concept that is fast.
Python is slow though, and for many use cases it won't work.
For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python. Something like that would even be slow in much "faster" Node.js.
Some stuff you can't really use dynamic langauges for, if you want it to be performant. Low-level stuff usually, of course.
To your point, you could showcase how Python might call out to other languages like Rust, and show why it's convenient to keep some stuff in Python.
> For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python.
Actually, bazaar [0] (now breezy [1]) was a distributed version control system written in Python. It gained some non-Python bits over time, but iirc it was originally all Python.
As a (spiritual) successor to Tom Lord’s Arch [2] it was the second DVCS I used and, while slower than git, was performant enough for my needs at the time I used it.
Most distributed version control is IO bound, and Python isn’t terrible at that.
Mercurial was written entirely in Python for quite a while.
But more to the point, I doubt there are many ideas for which the choice of implementation language is core to the idea. Maybe that's how it was presented, but that's usually because you need a concrete realization of an idea in order for people to even get what you're talking about.
>DevOps won't want to support it? Burn down the company
Still true but you seem to blame the ops. I've been in a job where every dept was allowed free for all tech budgets. They would hire incompetent consultants to dump 3000hrs of work on devops then do it again next week and complain about how devops never gets anything done. Then 5 other departments would do the same thing.
You know how 99% of the work is in that last 5% of the project. Thats how all those consultants would leave everything.
I read that as a frustration with the disparity between "you build it, you run it" and the enterprise-y habit to co-opt terms from free-roaming developers and stripping them of all meaning.
You can still have a central team of operators. When they're expected to deploy and support applications from development or procurement teams, I'd argue that's something else than devops for better or worse.
what I meant with "DevOps won't want to support it" was someone saying this before DevOps had even been asked, and by someone who wasn't even on DevOps, who just assumed that they probably wouldn't like this sort of thing.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with some of what you said, but just want to point out that you're doing the very thing you criticise here.
I think lots of people genuinely don't want change. Hopefully you have great answers to my objection.
In general, I've found the question of "who needs to provide evidence first?" is one of the most casually ignored and maliciously manipulated questions in so much professional discourse. The answer is often implicitly "the person with less role power" which by itself is a terrible answer.
I don't care about my job anymore, that's the problem. One too many good ideas has been shot down, one too many stupid ideas has been pushed through. If my manager and a huge chunk of my coworkers are simply incompetent, then trying to convince people to do something smart gets old very fast.
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.
> With all due respect, if the idea is good, then it will happen.
Not sure if that's survivorship bias or post-facto rationalization. I guess the 'it will happen' implies eventually and since we cannot wait for all time there is no good idea that could qualify as never going to happen.
I know of many good ideas that haven't' happened yet and are unlikely to be brought to fruition in my lifetime. At least Meta-Languages became popular, that only took 60 years.
I think it really depends on the motivations of the business. Some are more R&D and innovation driven. Getting "buy-in" is technically necessary, but trivially easy as long as the biggest cost is only development time. If it's a bad idea, it eventually fades away as other priorities take over.
There is no one singular "corporate environment". This is especially true when a lot of people working there tend to not job hop much. Time both grows that particular work culture, and keeps those people ignorant.
Many good ideas have multiple failed attempts wrt implementation.
Eg: if we accept that transcontinental rail spanning the USofA was a good idea, then it can be seen that several wanna be railroad barons fell by the wayside.
Take a look at the technology sitting in front of you. How many ideas does it incorporate that were tried and failed, or were tried but languished in niche markets for decades before they became an everyday thing?
A lot of ideas fail because they're not ready: they are expensive, they are not reliable (yet), the world is not ready for them. None of those reasons mean an idea is bad. They simply mean it will take more time and effort for them to work.
I am arguing it does. Condescending, dismissive responses aren’t arguments. I am not being absolutist, I am saying you are making it impossible to disagree by definition.
I am down to discuss this if you want to but this isn’t exactly a great start to a productive conversation.
> but this isn’t exactly a great start to a productive conversation.
My thought entirely. Perhaps you think I'm in the camp that believes all good ides come to fruition.
My position is that the world is complex, there are "good ideas" that have a time frame, should they not be implemented with that time frame their time has passed and they're no longer good ideas.
That said, my response above stands - just because a good idea exists and is timely, it does not follow that failures to implement cannot happen, nor does it mean that at least one attempt must succeed, further there are cases with a time window, I have a great idea for improving horse drawn ploughing, for example ...
Also, see @II2II 's peer comment above, another take on possible happenings.
Where I take issue with the content of your comment is specifically:
> what exactly am I supposed to do with the above?
Exactly what you did there: ask a question.
You tried it, you know where the potential failure points are. Don't assume the super optimistic person hasn't considered them. Ask them how they would address those issues. If they have addressed them, maybe there is something workable. If they haven't addressed those failure points, you have given them a choice: to tackle those issues in the background or to set the idea aside.
> The proposer of the idea needs to nurture it and part of that is defending it.
Some people are focusing on the first sentence, but I think this part is key. Obviously, if it's a good idea and you're putting in the work, that's probably a good direction. Critique is useful, defending an idea can help prevent you from being blindsided and help to hone your vision.
One of the things a lot of people seem to struggle with is knowing when it's worth it to keep going and when to let go. When working on something, there can be a lot of people coming from all sides saying, "this won't work," "this will work if you just stick with it", "actually, you're just missing X." There's a lot of noise, and the pushback can be fairly cliche at times.
Sometimes, things like you've mentioned like lack of experience will block them. But, depending on how strongly somebody feels about a concept, when they don't necessarily know if it's a good idea, they may just nurture it and see how everything plays out. It's okay if some things fail.
These are all excuses. I tried this 4 years ago excuse often fails after I try and somehow things magically work. We create blindspots when we focus too deeply for too long. Sometimes when trying things you believe will fail because of past experience you discover you were doing it wrong or time has caught up or some other variable changed.
Sometimes, the only way to get the negative aspects of an idea across to someone with a bright look in their eye is to stand back and let them do it.
Let them fail.
And then, when they run face-first into that brick wall (exactly as predicted), don't point and laugh and say "I told you so!"
Instead, help them to their feet and to get dusted off. You can then share stories of your mutual, independent failures over a beer or something.
(And the next time? You still don't have to tell them that the idea is a dead-end; if they're smart, they'll ask you questions before they burst out in a sprint.)
This is faith in some sort of cosmic truth a la “the invisible hand.” The best ideas do not always win out. We wouldn’t have concepts such as “first mover advantage” if that was true.
Well, you can help nurture it. Prehaps instead of speaking how about how it couldn't work think about what you'd need to do to make it work or where it could work. Tend to the garden!
> think about what you'd need to do to make it work
"This idea will probably work once we can develop just a few new basic technologies that it depends on (time travel, antigravity, unlimited free energy, faster-than-light communication, ...)"
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.
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.
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?
Heilmeier Catechism is really interesting, thanks for linking that. I like how the questions break down different major aspects. It treats risk as one of the dimensions of evaluation but not entire conversation. That's the shift I was trying to describe. Critique is valuable as part of a complete picture, not when it is the only lens.
He's pointing out that it's ironic to come into a thread about not shooting ideas and do nothing more than shoot down the idea. It's literally the exact behavior described in like the first paragraph of the article. It IS ironic.
Ok, I just thought it was ironic that the article was about how being critical of something isn't skillful. And, it appeared to me (but all my downvotes prove I'm in the minority), that you just added a critical comment without doing anything else the author wrote about.
For the record, I was curious about what else you have written, so I read some of your posts and comments. And, you seem to be a very thoughtful and intelligent person. I'm sorry if my comment was offensive, I meant it to be funny.
i dont agree with the self-indemnifying approach. let us apply this concept to itself - what could go wrong with not shooting down ideas? a lot of time could be wasted giving credence to that which is invalid. for example, ive just donated my energy debating the merits of an article that was probably written by a large language model (this is a judgement based on overt presence of negative parallelism, punchy prose, tripartite sentence structure, AI generated image, ...) - on a personal basis id prefer to have spent my time otherwise, as this entire argument can be summed as "be curious, not judgemental". therefore shooting this one down was probably a good idea?
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.
It's definitely a more nuanced topic than I think the article leads on. There is a right and wrong time to apply the brakes, but you can still be critical in either case.
There have been numerous times where I have identified real issues with an idea, advocated we crack on anyway and ended up with good results. Often you can't know for sure if an issue will even be that insurmountable until you get to it.
But there are other times where the risk/reward isn't lining up, or the risk is very well known, you've tried it before etc. Then hit the brakes, back to the drawing board for another try.
I think the danger is when people treat ideas as precious. In a well functioning team, your idea is going to get picked apart, modified, morphed and implemented by others. Get over your attachment to the idea as your baby, and you get to really enjoy the process.
Common failure mode in environments that promote being the best over getting things done: If you went from school to college to industry always identifying with being better than everyone else, because that's what it takes to get in the door, sometimes you miss the transition to when you're already in the door. A lot of people don't realize they were supposed to put their guards down until it's too late. It's too bad but this is what the cutthroat labor pipeline rewards.
The vast majority of software engineers is never tasked to do something genuine. It's the opposite, you are tasked to improve, expand and maintain things under very specific constraints. Corporate work is by default anti innovation, the company has made the innovation and wants you to maximize its profits.
Also many great innovations or discoveries have outlived extreme opposition. The problem isn't people saying no, the problem is having non-sociopathic people being reluctant hearing no.
> 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 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.
If you are doing it yourself shoot for the moon. If you want other people to work on your idea, then yeah you better be able to explain to those other people why the result would be worth it and why the approach is viable (or pay them not to care)
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.
Exactly. "Doing it this way would prevent us from also doing X in the future; are we sure to permanently cross X from the roadmap, and are stakeholders aware?" is a valid and valuable objection. EDIT: and it can be trivially shot down by somebody with enough authority to define a roadmap saying, "we don't care about doing X".
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.
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.
Open source bug trackers tend to not appreciate people who just want them to implement someone else's idea without the other person putting effort in. That is true for both good and bad ideas.
Its like going up to a tech person at a party and saying "i have a wonderful idea for an app"
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.
I like that angle a lot, and this very thoughtful comment. Distinguishing between the idea and the person is a good way to think about it. I think sometimes people cross that line without realizing it. Your point about making sure people still want to bring ideas next time is really what it comes down to.
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.
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.
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.
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.
I'd agree with this take where possible. Trying to explain the idea requires all the listeners to imagine the same thing in their head. If you can show them something, it's worth a thousand words..
I have this with a colleague right now who has a rather solid idea (I think). Trying to convince him that at least some diagramming would help get it across.
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.
If you're pointing out a problem without offering a path through it, that's not contributing.
This is bullshit. Having a solution to a problem has absolutely no bearing on the value of pointing it out. What if someone else who hasn't recognized the problem has a solution? What if no solution exists? What if the problem is complicated and will take hours, days, weeks, months, or years of work to solve? Or if I simply lack the requisite knowledge, intelligence, or skills to solve the problem? Which may not even be technical; as a non-lawyer (or, for that matter, a lawyer in an unrelated practice area), should I refrain from seeking legal advice if I discover a legal problem I'm not personally qualified to solve?
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.
> those who don't learn from history are doomed to repeat it
This is a classic meta shutdown - the exact thoughtless criticism the article rails against.
Make the future, deal with the relevant mistakes one discovers on one's path.
There is an infinite number of mistakes to make. It doesn't help to waste oodles of time learning about mistakes made by others under different contexts and constraints.
Avoiding mistakes is hard. Listening, nous and intuition can help. The biggest trick is to learn how to deal with mistakes as they occur (no matter how obvious they might be to someone with sufficient art).
The biggest mistake is to have too much fear of mistakes to even begin a venture.
If you are making the future yourself, why do you care what anyone else thinks? Just do what you want. Its your time and effort, nobody else has a claim on it.
In the context of the article, the author wanted other people to be involved with implementing his idea. If you want someone else to help, you are going to have to convince them. Nobody wants to put labour into an idea that is half baked, with no clear answer as to why we would want to do it or how we intend to do it.
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"?
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 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.
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.
Realistically, yes. During exploration you need to be able to rapidly iterate and those who close off trees to exploration based on one or two leaf nodes are adding too much cost to the search function. But that's just the difference between exploration and exploitation. When you're discovering, you need a greater ability to differentiate between hard-stops "if I go that direction I fall off a cliff almost certainly" and explorable areas "if I go that direction I can make it work if I do these straightforward things". People have various levels of this, and I suspect it's based on risk and change tolerance.
Some can only operate like how things always were. Others will go right off the cliff. Life doesn't last long if you're the latter. And life isn't fun for me if you're the former. So it's just a question of finding a sufficient group who are at your appropriate spot in the middle and adjusting yourselves.
Overall, because of the much larger number of people online these days and the general meshing of various subcultures into common fora, I just apply filtering tech in order to retain this bubble of alignment among the chaos. I think it's more useful to watch the more-risky explorers than oneself, if only because ideas come out of there, though.
But those who always say "no" to something aren't useful to me. I have yet to encounter one whose ideas I haven't already thought of but have found a pathway that dodges the problem. Anyway, all of this is old ground, explored by https://en.wikipedia.org/wiki/Yes,_and_... and the subsequent business articles that recommend "Yes, and..." everything.
>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.
Yes, the author assumes that the idea was carefully vetted and cultivated. If, in fact, that was the case, then, as other commenters have pointed out, the idea's champion should have ready answers to most obvious critiques.
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.
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.
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.
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
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.
Honestly IMO this kind of thing just depends a lot on tone. “That won’t work because” tends to piss people off and they usually do the thing anyway. “Cool idea! What about …? We tried … years ago and failed because of that” works at least sometimes (and sometimes they have a good answer)
Edit: also, bluntly, sometimes objections have answers that can’t be said. “DevOps won't want to support another service.”…”that’s because our devops engineers all think you’re an overpaid jackass and are strongly inclined to reject your ideas out of the gate. My one other idea they liked, so they’ll probably take a chance on another one.” What’s hard but important to remember is that sometimes you’re the person that things can’t be said to.
> Stop thinking that finding a flaw is a contribution. It's half of a contribution at best. The other half is "and here's how we might solve that." If you're pointing out a problem without offering a path through it, that's not contributing.
So... finding a flaw is "half" of a contribution, but it also isn't a contribution?
Critical thinking is valuable. Yes, it can sometimes be counterproductive, but it can also be steered in a productive direction.
If someone criticizes something, ask them to elaborate. Why couldn't this work? What are the exact roadblocks? Is it based on prior experience, or gut feeling? If it's based on experience, how similar is the current situation to their past experience?
Chances are that after some prodding their criticism turns out to be a non-issue, or far less of an issue than they originally thought. In either case, the discussion itself often steers the group towards a better solution, so bringing up potential concerns, even if they're invalid, is often a good exercise.
The skill is aiming for the right moment to bring it up, having a bit of tact in the delivery, and not burying your head in the sand and being defensive (or offensive). Too often people attach their ideas to their identities, which is the root cause of why design discussions can be frustrating and nonproductive.
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?
That's fair. The title is provocative and probably overstates my actual position, which as you note is closer to "the way people practice critique in meetings is low value and here's how to do it better". The point about making critical thinkers feel worse is taken too. The people I'm describing in the post aren't the careful, thoughtful critics, but instead the reflexive ones. I could have drawn that line more clearly.
Is that a skill or communicating experience? I have a hard time trying to identify when my criticisms are a sort of technique that can be developed. Ofc, even my criticisms can be ill-founded.
This statement is over-generalizing the case. I'm talking about a niche context when trying to "shoot holes in an idea", not some general communication skill (as you've implied) that is practiced. I don't believe what I referenced is a skill.
^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
> "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.
> 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.
> 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 time
Depends on context. Shooting the shit is valuable.
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.
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.
These are the table stakes of uncertainty, not delving into every little pocket. If the language and ops are under question, this sounds like an entire new project or significant extension. The bit of time it takes to answer all those questions is worth it.
>On the other hand, demanding an answer to every little pocket of uncertainty creates a huge burden that prevents exploration.
How do you explore an idea, other than trying to shoot it down and seeing if it survives the shot?
You can fire the shot and then patch the hole at the same time, proposing solutions to the same problem you pointed out, rather than just shooting and letting one person handle defense from every attack.
By proceeding with things that will gather more data—such as prototyping, or further independent research—vs spinning indefinitely on "hypothetical" discussion-only shots.
How do you know if it survives the shot without that, if it's just person A saying "I don't think Python perf will be an issue" and person B saying "I think it will"?
Congrats, you've killed the idea in its infancy because you demanded answers to questions before it could even walk.
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.
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.
> 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.
If your idea is so in its infancy, that you can't explain its business case to people, even just hypothetically, than its too young to share.
Ideas are cheap. Everyone has them.
Sure, but it's sort of dumb for me to bring an idea I value to the table until I have answers to all the obvious questions.
I owe it to my colleagues to not make them the bad guys by shooting down an idea.
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.
Isn’t proving a market exists, building a proof of concept, etc, all examples of exploring an idea? Those seem like perfectly reasonable expectations.
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."
If an idea is dead because it couldn't survive its first public outing, that's probably a good thing.
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.
That all sounds fine if they're not the kind of naysayers that will just let the company collapse around them rather than risk putting one of their own ideas out there on the chopping block. All too often nothing is the worst thing we can do, and there are a lot of professional do-nothings out there.
> Bzzt. Since all of these people are correct and smart, it is now your job to have great answers to their objections.
Power assymetry and tenure are a factor. So is "culture eats strategy for breakfast" realities in organizations.
e.g. Change of pandemic messaging in early 2020 from "covid transmits by droplets and fomites and 2 meters and handwashing keep you safe" to "covid is airborne and fills a room like smoke" (and multiple mitigations around that) was attempted in groups by multiple expert scientists and ultimately took years when it needed to be done fast. One key moment: https://www.google.com/search?q=%22where+is+your+evidence+li... You can come with evidence for those tough questions to support your position, but one grandee scoffs at your suggestion in the meeting you networked hard to get and there's no recovery.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with more or less everything but this one.
I would modify it.
People don't want change? Nah, people like change when it is obvious to them that the change is good for them personally.
You can introduce a change that would be great for the organization and customers, but totally eliminate the current project a team has been working on unsuccessfully for years. You will be shot down no matter how good your idea is. And many times, there is no way to turn it into a "win" for the team that you need to win over to your side due to politics.
So shooting down ideas - for that team - is indeed a skill. A self-preservation skill. I've seen teams able to employ this skill for nearly a decade where it was obvious to any outside observer there were numerous ideas that would eliminate their need to exist altogether.
the "good for them personally" reaction is so true. It's almost like a team-level version of the inonvator's dilemma, where protecting the thing you already own feels more rational than supporting something that might replace it.
you're right that a good idea should be able to survive scrutiny. The issue I'm describing isn't "someone asked a tough question". It's when objections pile up so ast that nothing can survive long enough to be properly evaluated. That's not a rigorous process, that's just a kill zone. The difference between a productive and unproductive kill zone comes down to culture. Teams that default to "here's why it won't work" end up very efficient at producing nothing. The teams I've seen do this well still kill ideas but they just do it after giving them a fair shot. The proposer has to do their homework but the environment has to let them get far enough to do it.
> Can't use Python because it's too slow? Show a proof of concept that is fast.
The burden of proof is on the other side. Prove that Python is too slow for the intended usecase.
> Can't use Python because it's too slow? Show a proof of concept that is fast.
Python is slow though, and for many use cases it won't work.
For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python. Something like that would even be slow in much "faster" Node.js.
Some stuff you can't really use dynamic langauges for, if you want it to be performant. Low-level stuff usually, of course.
To your point, you could showcase how Python might call out to other languages like Rust, and show why it's convenient to keep some stuff in Python.
> Python is slow though, and for many use cases it won't work.
This is actually the only criticism from the article i think is invalid.
Very little in the business world is so performance sensitive that language (as oppossed to algorithms used) make a difference.
If it does make a difference, python is still probably fine for the prototype.
If its still an issue, just use another language. You are at the beginning of the project, its trivial at this stage to switch languages.
All the other criticisms i consider very valid. The language choice example is a stupid one.
> For example, say somebody wanted to build a performant systems type software like version control. You're not really going to do that in Python.
Actually, bazaar [0] (now breezy [1]) was a distributed version control system written in Python. It gained some non-Python bits over time, but iirc it was originally all Python.
As a (spiritual) successor to Tom Lord’s Arch [2] it was the second DVCS I used and, while slower than git, was performant enough for my needs at the time I used it.
Most distributed version control is IO bound, and Python isn’t terrible at that.
[0]: https://en.wikipedia.org/wiki/GNU_Bazaar
[1]: https://en.wikipedia.org/wiki/Breezy_(software)
[2]: https://en.wikipedia.org/wiki/GNU_arch
Mercurial was written entirely in Python for quite a while.
But more to the point, I doubt there are many ideas for which the choice of implementation language is core to the idea. Maybe that's how it was presented, but that's usually because you need a concrete realization of an idea in order for people to even get what you're talking about.
>DevOps won't want to support it? Burn down the company
Still true but you seem to blame the ops. I've been in a job where every dept was allowed free for all tech budgets. They would hire incompetent consultants to dump 3000hrs of work on devops then do it again next week and complain about how devops never gets anything done. Then 5 other departments would do the same thing.
You know how 99% of the work is in that last 5% of the project. Thats how all those consultants would leave everything.
I read that as a frustration with the disparity between "you build it, you run it" and the enterprise-y habit to co-opt terms from free-roaming developers and stripping them of all meaning.
You can still have a central team of operators. When they're expected to deploy and support applications from development or procurement teams, I'd argue that's something else than devops for better or worse.
what I meant with "DevOps won't want to support it" was someone saying this before DevOps had even been asked, and by someone who wasn't even on DevOps, who just assumed that they probably wouldn't like this sort of thing.
> People don't want change? Nah, people like change when it is obvious to them that the change is good.
I agree with some of what you said, but just want to point out that you're doing the very thing you criticise here.
I think lots of people genuinely don't want change. Hopefully you have great answers to my objection.
In general, I've found the question of "who needs to provide evidence first?" is one of the most casually ignored and maliciously manipulated questions in so much professional discourse. The answer is often implicitly "the person with less role power" which by itself is a terrible answer.
> it is now your job
I don't care about my job anymore, that's the problem. One too many good ideas has been shot down, one too many stupid ideas has been pushed through. If my manager and a huge chunk of my coworkers are simply incompetent, then trying to convince people to do something smart gets old very fast.
The skill of shooting down ideas has never been more valuable, actually.
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.
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.
> With all due respect, if the idea is good, then it will happen.
Not sure if that's survivorship bias or post-facto rationalization. I guess the 'it will happen' implies eventually and since we cannot wait for all time there is no good idea that could qualify as never going to happen.
I know of many good ideas that haven't' happened yet and are unlikely to be brought to fruition in my lifetime. At least Meta-Languages became popular, that only took 60 years.
> With all due respect, if the idea is good, then it will happen
Working in a corporate environment, I have not found this to be the case. Good ideas get nowhere without buy-in
I think it really depends on the motivations of the business. Some are more R&D and innovation driven. Getting "buy-in" is technically necessary, but trivially easy as long as the biggest cost is only development time. If it's a bad idea, it eventually fades away as other priorities take over.
There is no one singular "corporate environment". This is especially true when a lot of people working there tend to not job hop much. Time both grows that particular work culture, and keeps those people ignorant.
>With all due respect, if the idea is good, then it will happen
If this is true, companies wouldn't fail all the time.
Many good ideas have multiple failed attempts wrt implementation.
Eg: if we accept that transcontinental rail spanning the USofA was a good idea, then it can be seen that several wanna be railroad barons fell by the wayside.
This logic means you can’t ever be wrong because any case of a good idea not being implemented can be hand waved away as “not yet.”
Edit: you changed your comment a lot
Take a look at the technology sitting in front of you. How many ideas does it incorporate that were tried and failed, or were tried but languished in niche markets for decades before they became an everyday thing?
A lot of ideas fail because they're not ready: they are expensive, they are not reliable (yet), the world is not ready for them. None of those reasons mean an idea is bad. They simply mean it will take more time and effort for them to work.
“a lot of ideas fail because they’re not ready” =/= “all good ideas win out”
> This logic means
No, it doesn't. Maybe wind back on the absolutism a little and look to the wide world where things happen. Warts and all.
I am arguing it does. Condescending, dismissive responses aren’t arguments. I am not being absolutist, I am saying you are making it impossible to disagree by definition.
I am down to discuss this if you want to but this isn’t exactly a great start to a productive conversation.
> but this isn’t exactly a great start to a productive conversation.
My thought entirely. Perhaps you think I'm in the camp that believes all good ides come to fruition.
My position is that the world is complex, there are "good ideas" that have a time frame, should they not be implemented with that time frame their time has passed and they're no longer good ideas.
That said, my response above stands - just because a good idea exists and is timely, it does not follow that failures to implement cannot happen, nor does it mean that at least one attempt must succeed, further there are cases with a time window, I have a great idea for improving horse drawn ploughing, for example ...
Also, see @II2II 's peer comment above, another take on possible happenings.
Where I take issue with the content of your comment is specifically:
> This logic means ...
the reasoning you use there eludes me.
I’m done man
> what exactly am I supposed to do with the above?
Exactly what you did there: ask a question.
You tried it, you know where the potential failure points are. Don't assume the super optimistic person hasn't considered them. Ask them how they would address those issues. If they have addressed them, maybe there is something workable. If they haven't addressed those failure points, you have given them a choice: to tackle those issues in the background or to set the idea aside.
> The proposer of the idea needs to nurture it and part of that is defending it.
Some people are focusing on the first sentence, but I think this part is key. Obviously, if it's a good idea and you're putting in the work, that's probably a good direction. Critique is useful, defending an idea can help prevent you from being blindsided and help to hone your vision.
One of the things a lot of people seem to struggle with is knowing when it's worth it to keep going and when to let go. When working on something, there can be a lot of people coming from all sides saying, "this won't work," "this will work if you just stick with it", "actually, you're just missing X." There's a lot of noise, and the pushback can be fairly cliche at times.
Sometimes, things like you've mentioned like lack of experience will block them. But, depending on how strongly somebody feels about a concept, when they don't necessarily know if it's a good idea, they may just nurture it and see how everything plays out. It's okay if some things fail.
These are all excuses. I tried this 4 years ago excuse often fails after I try and somehow things magically work. We create blindspots when we focus too deeply for too long. Sometimes when trying things you believe will fail because of past experience you discover you were doing it wrong or time has caught up or some other variable changed.
Sometimes, the only way to get the negative aspects of an idea across to someone with a bright look in their eye is to stand back and let them do it.
Let them fail.
And then, when they run face-first into that brick wall (exactly as predicted), don't point and laugh and say "I told you so!"
Instead, help them to their feet and to get dusted off. You can then share stories of your mutual, independent failures over a beer or something.
(And the next time? You still don't have to tell them that the idea is a dead-end; if they're smart, they'll ask you questions before they burst out in a sprint.)
Most of the startups were flawed ideas according to vast majority, this is why success is rare.
You cannot know which solution will succeed, there are many stupid solutions with commerical success while many brilliant solutions without success.
Thinking you can guess what is going to succeed or not going to succeed is dunning kruger.
Predicting success is tough.
Some failures are not hard to predict. Politics is full of bad ideas that should’ve been shot down early.
This is faith in some sort of cosmic truth a la “the invisible hand.” The best ideas do not always win out. We wouldn’t have concepts such as “first mover advantage” if that was true.
Well, you can help nurture it. Prehaps instead of speaking how about how it couldn't work think about what you'd need to do to make it work or where it could work. Tend to the garden!
> think about what you'd need to do to make it work
"This idea will probably work once we can develop just a few new basic technologies that it depends on (time travel, antigravity, unlimited free energy, faster-than-light communication, ...)"
This guy shoots down ideas.
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.
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.
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?
https://www.darpa.mil/about/heilmeier-catechism
Heilmeier Catechism is really interesting, thanks for linking that. I like how the questions break down different major aspects. It treats risk as one of the dimensions of evaluation but not entire conversation. That's the shift I was trying to describe. Critique is valuable as part of a complete picture, not when it is the only lens.
Yes, it is.
> 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.
Oh, the irony...
Knowing how to stop a bad idea is a skill.
Knowing when it's a bad idea is a skill.
Knowing when you don't know is a skill.
There's more than one skill in life. More than one may be applicable to a situation.
Everyone on this forum has probably run into one of the "idea guys" who just need a tech cofounder to do the coding for 2% equity.
He's pointing out that it's ironic to come into a thread about not shooting ideas and do nothing more than shoot down the idea. It's literally the exact behavior described in like the first paragraph of the article. It IS ironic.
I expect the comment was about your (pre-edit) "there doing" vs the current "they're doing", shame you didn't acknowledge your mistake in the change.
At no point did my comment say "there doing".
Great, so what did your comment say the first time?
"Yes, it is."
(I'm also not clear on what would make a typo ironic in this case.)
Can you clarify? The alleged typo is… not there? Or their? Or they’re?
What’s ironic here?
Ok, I just thought it was ironic that the article was about how being critical of something isn't skillful. And, it appeared to me (but all my downvotes prove I'm in the minority), that you just added a critical comment without doing anything else the author wrote about.
For the record, I was curious about what else you have written, so I read some of your posts and comments. And, you seem to be a very thoughtful and intelligent person. I'm sorry if my comment was offensive, I meant it to be funny.
It felt very low effort and did not contribute anything to the comment thread.
i dont agree with the self-indemnifying approach. let us apply this concept to itself - what could go wrong with not shooting down ideas? a lot of time could be wasted giving credence to that which is invalid. for example, ive just donated my energy debating the merits of an article that was probably written by a large language model (this is a judgement based on overt presence of negative parallelism, punchy prose, tripartite sentence structure, AI generated image, ...) - on a personal basis id prefer to have spent my time otherwise, as this entire argument can be summed as "be curious, not judgemental". therefore shooting this one down was probably a good idea?
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."
Well, so the story goes.
Who would want to hide their secrets in ARS?
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.
It's definitely a more nuanced topic than I think the article leads on. There is a right and wrong time to apply the brakes, but you can still be critical in either case.
There have been numerous times where I have identified real issues with an idea, advocated we crack on anyway and ended up with good results. Often you can't know for sure if an issue will even be that insurmountable until you get to it.
But there are other times where the risk/reward isn't lining up, or the risk is very well known, you've tried it before etc. Then hit the brakes, back to the drawing board for another try.
I think the danger is when people treat ideas as precious. In a well functioning team, your idea is going to get picked apart, modified, morphed and implemented by others. Get over your attachment to the idea as your baby, and you get to really enjoy the process.
Common failure mode in environments that promote being the best over getting things done: If you went from school to college to industry always identifying with being better than everyone else, because that's what it takes to get in the door, sometimes you miss the transition to when you're already in the door. A lot of people don't realize they were supposed to put their guards down until it's too late. It's too bad but this is what the cutthroat labor pipeline rewards.
The vast majority of software engineers is never tasked to do something genuine. It's the opposite, you are tasked to improve, expand and maintain things under very specific constraints. Corporate work is by default anti innovation, the company has made the innovation and wants you to maximize its profits.
Also many great innovations or discoveries have outlived extreme opposition. The problem isn't people saying no, the problem is having non-sociopathic people being reluctant hearing no.
> 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 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 always try to remember the quote "Those saying a thing is impossible need to stay out of the way of those doing it"
A important word doing a lot of lifting here is "doing". talk is cheap, the problem is never lack of ideas.
Agree 100%.
If you are doing it yourself shoot for the moon. If you want other people to work on your idea, then yeah you better be able to explain to those other people why the result would be worth it and why the approach is viable (or pay them not to care)
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.
An idea can also reduce value. Or prevent you from producing value in the future. Knowing when an idea is bad or not worth doing is a skill in itself.
Exactly. "Doing it this way would prevent us from also doing X in the future; are we sure to permanently cross X from the roadmap, and are stakeholders aware?" is a valid and valuable objection. EDIT: and it can be trivially shot down by somebody with enough authority to define a roadmap saying, "we don't care about doing X".
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.
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.
Open source bug trackers tend to not appreciate people who just want them to implement someone else's idea without the other person putting effort in. That is true for both good and bad ideas.
Its like going up to a tech person at a party and saying "i have a wonderful idea for an app"
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.
I like that angle a lot, and this very thoughtful comment. Distinguishing between the idea and the person is a good way to think about it. I think sometimes people cross that line without realizing it. Your point about making sure people still want to bring ideas next time is really what it comes down to.
Sure it’s much easier to criticise, but the idea giver especially after months of planing should be able to address those immediate ones
I came to the comments section to shoot down the article, and I see you fine people have already done an excellent job. I just upvoted y'all.
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.
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.
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.
> Perverting the organization into a support ecosystem for naysayers is not a trivial thing.
Nor is establishing an "all ideas are good ones!" culture.
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.
I'd agree with this take where possible. Trying to explain the idea requires all the listeners to imagine the same thing in their head. If you can show them something, it's worth a thousand words..
I have this with a colleague right now who has a rather solid idea (I think). Trying to convince him that at least some diagramming would help get it across.
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.
If you're pointing out a problem without offering a path through it, that's not contributing.
This is bullshit. Having a solution to a problem has absolutely no bearing on the value of pointing it out. What if someone else who hasn't recognized the problem has a solution? What if no solution exists? What if the problem is complicated and will take hours, days, weeks, months, or years of work to solve? Or if I simply lack the requisite knowledge, intelligence, or skills to solve the problem? Which may not even be technical; as a non-lawyer (or, for that matter, a lawyer in an unrelated practice area), should I refrain from seeking legal advice if I discover a legal problem I'm not personally qualified to solve?
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.
> those who don't learn from history are doomed to repeat it
This is a classic meta shutdown - the exact thoughtless criticism the article rails against.
Make the future, deal with the relevant mistakes one discovers on one's path.
There is an infinite number of mistakes to make. It doesn't help to waste oodles of time learning about mistakes made by others under different contexts and constraints.
Avoiding mistakes is hard. Listening, nous and intuition can help. The biggest trick is to learn how to deal with mistakes as they occur (no matter how obvious they might be to someone with sufficient art).
The biggest mistake is to have too much fear of mistakes to even begin a venture.
> Make the future
If you are making the future yourself, why do you care what anyone else thinks? Just do what you want. Its your time and effort, nobody else has a claim on it.
In the context of the article, the author wanted other people to be involved with implementing his idea. If you want someone else to help, you are going to have to convince them. Nobody wants to put labour into an idea that is half baked, with no clear answer as to why we would want to do it or how we intend to do it.
There is a balance somewhere.
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"?
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.
“The only thing that can create value is an idea.”
Not in agreement one bit.
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.
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.
Ideas are cheap
I would use this filter: not whether an idea is absurd, whether someone commits time to build it
Here's an idea. Shoot down an idea if:
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?
Yes it is, but timing is key. Not too early and not too late.
Coming up with bad ideas isn’t a skill either.
Realistically, yes. During exploration you need to be able to rapidly iterate and those who close off trees to exploration based on one or two leaf nodes are adding too much cost to the search function. But that's just the difference between exploration and exploitation. When you're discovering, you need a greater ability to differentiate between hard-stops "if I go that direction I fall off a cliff almost certainly" and explorable areas "if I go that direction I can make it work if I do these straightforward things". People have various levels of this, and I suspect it's based on risk and change tolerance.
Some can only operate like how things always were. Others will go right off the cliff. Life doesn't last long if you're the latter. And life isn't fun for me if you're the former. So it's just a question of finding a sufficient group who are at your appropriate spot in the middle and adjusting yourselves.
Overall, because of the much larger number of people online these days and the general meshing of various subcultures into common fora, I just apply filtering tech in order to retain this bubble of alignment among the chaos. I think it's more useful to watch the more-risky explorers than oneself, if only because ideas come out of there, though.
But those who always say "no" to something aren't useful to me. I have yet to encounter one whose ideas I haven't already thought of but have found a pathway that dodges the problem. Anyway, all of this is old ground, explored by https://en.wikipedia.org/wiki/Yes,_and_... and the subsequent business articles that recommend "Yes, and..." everything.
I like this quote from pg:
>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
This is the exact opposite of the theory of bullshit asymmetry. It’s much easier to come up with bullshit than it is to debunk it.
The real skill is known which ideas to shoot down or heavily rework, which is probably the most valuable thing a senior engineer brings to the table.
Yes, the author assumes that the idea was carefully vetted and cultivated. If, in fact, that was the case, then, as other commenters have pointed out, the idea's champion should have ready answers to most obvious critiques.
> 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.
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.
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.
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
It takes some wisdom
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.
Must say there is substantially more helpful material about critical thinking in the comment section, here, than in the article itself.
Honestly IMO this kind of thing just depends a lot on tone. “That won’t work because” tends to piss people off and they usually do the thing anyway. “Cool idea! What about …? We tried … years ago and failed because of that” works at least sometimes (and sometimes they have a good answer)
Edit: also, bluntly, sometimes objections have answers that can’t be said. “DevOps won't want to support another service.”…”that’s because our devops engineers all think you’re an overpaid jackass and are strongly inclined to reject your ideas out of the gate. My one other idea they liked, so they’ll probably take a chance on another one.” What’s hard but important to remember is that sometimes you’re the person that things can’t be said to.
The author contradicts themself.
> Stop thinking that finding a flaw is a contribution. It's half of a contribution at best. The other half is "and here's how we might solve that." If you're pointing out a problem without offering a path through it, that's not contributing.
So... finding a flaw is "half" of a contribution, but it also isn't a contribution?
Critical thinking is valuable. Yes, it can sometimes be counterproductive, but it can also be steered in a productive direction.
If someone criticizes something, ask them to elaborate. Why couldn't this work? What are the exact roadblocks? Is it based on prior experience, or gut feeling? If it's based on experience, how similar is the current situation to their past experience?
Chances are that after some prodding their criticism turns out to be a non-issue, or far less of an issue than they originally thought. In either case, the discussion itself often steers the group towards a better solution, so bringing up potential concerns, even if they're invalid, is often a good exercise.
The skill is aiming for the right moment to bring it up, having a bit of tact in the delivery, and not burying your head in the sand and being defensive (or offensive). Too often people attach their ideas to their identities, which is the root cause of why design discussions can be frustrating and nonproductive.
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.
e
“pessimists sound smart , but optimists make money”
Some optimists make money.
Others lose it all.
Most scenarios call for a bit of both.
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?
That's fair. The title is provocative and probably overstates my actual position, which as you note is closer to "the way people practice critique in meetings is low value and here's how to do it better". The point about making critical thinkers feel worse is taken too. The people I'm describing in the post aren't the careful, thoughtful critics, but instead the reflexive ones. I could have drawn that line more clearly.
Who is Scott Lawson and why does he have such bad ideas?
Sure kid, go play with that footgun
uh no.
The best way (IMO) is "Look, I've tried that idea and X happened, you might have better luck, but be aware"
Is that a skill or communicating experience? I have a hard time trying to identify when my criticisms are a sort of technique that can be developed. Ofc, even my criticisms can be ill-founded.
> Is that a skill or communicating experience?
uhhh, how is communicating experience not a skill?
> How is communicating experience not a skill?
This statement is over-generalizing the case. I'm talking about a niche context when trying to "shoot holes in an idea", not some general communication skill (as you've implied) that is practiced. I don't believe what I referenced is a skill.