Shooting down ideas is not a skill
scottlawsonbc.com
scottlawsonbc.com
> 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.
Ideas need time to be explored, and given a chance.
I owe it to my colleagues to not make them the bad guys by shooting down an idea.
I say this as a semi-reformed naysayer. I am critical of implementation plans, but let ideas breath a bit in a more exploratory setting before I start bringing up constraints.
Then go back, address the objections, and re-propose.
If you can't explain at least a little bit of "why this is worth at least digging into", that's on you.
Ideas are cheap. Everyone has them.
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."
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.
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.
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.
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.
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
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.
Most of the time, when someone raises a hypothetical performance criticism, it is either to further their pet language or as a cheap shot to shoot something down.
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.
If it is not the case that "devs" is not functionally equivalent to saying "DevOps", then "DevOps" doesn't exist. You have an operations group, and you need their buy-in, so they should be invited to the meeting.
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.
How do you explore an idea, other than trying to shoot it down and seeing if it survives the shot?
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"?
That is the point, knowing that it is a point we want to test is valuable. If person B there didn't say he thought it would be an issue you probably wouldn't have tested it, it was valuable for him to say that.
The examples he used included: the plan depends on a different team providing labour and that team is not on board, the business plan for the idea does not make sense.
I suppose they are low effort in the sense that they are very basic 101 criticisms, but i wouldn't call them cheap shots.
Literally no plan is ever going to work if it involves the labour of others without their (or their supperiors) consent. It seems to me a very valid criticism to make. That doesn't mean its the end of the idea, it means you need to have a plan to either get the other stakeholders on board, or a plan to do it without them.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
If they did that much upfront work, it's more than an idea. And if it's that easily shot down, they should have done even more upfront work and probably slowly gotten others involved.
Honestly, it sounds like someone so desperate for credit, so worried that someone will steal the idea, that they feel compelled to unveil it in a large gathering that was convened for some other purpose. And that never goes well.
Ideas truly are a dime a dozen. If one gets shot down, then you can reflect whether that was warranted, and try again with the same idea if not.
If you're really emotionally invested in it, as the guy writing the article seems to be, then you damn well better have more than just an idea, and you should understand enough about human nature to slowly try to bring individuals onboard to help before you put it out in front of a big crowd.
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.
Depends on context. Shooting the shit is valuable.
If the engineer proposes an implementation the devops team doesn’t like, the devops team should come up with a counter proposal that still fulfills their requirements. And if their counter proposal fulfills the requirements but the engineer objects, then whoever’s at the top of both their branches in the org chart should be making the decision.
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 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.
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 burden of proof is on the other side. Prove that Python is too slow for the intended usecase.
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.
You’re doing it absolutely precisely.
Knocking down this persons idea, giving all sorts or rational sounding reasons why this won’t work.
It makes you feel smart.
You contributed nothing.
All you did is dismiss and tear down and smash.
Look how clever you’ve proven yourself to be by stating how much won’t work.
LLM's are an endless source of bad code ideas. Being able to sift through them and find the gems is the exhausting way to be productive.
I agree with the general premise that it is easy to shoot down ideas without thinking. But it's also easy to propose ideas without thinking.
Both are disrespectful if disproportionate to the effort of the other.
The core is not idea generation versus critique. It's the effort spent on each.
When someone is super optimistic and comes forward with an idea where:
- it's actually just a half baked solution for something I already tried to solve 4 years ago
- I'm acutely aware of all the spots it will fall
- they still think it can work, when it really really honestly can not
- they lack the experience to see that it won't work and become frustrated when I point out 20 problems with it and why it's not worth pursuing further
^ what exactly am I supposed to do with the above? You can take the advice/critique or leave it, but if I'm supposed to try to help and nurture a dead end instead of telling you the issues with it, that makes no sense to me.
If this is true, companies wouldn't fail all the time.
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.
Edit: you changed your comment a lot
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 down to discuss this if you want to 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.
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.
He had a comment that said, essentially, “all good ideas eventually win out.” He then heavily edited his comment after I responded. That could be the source of confusion for you here.
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.)
Working in a corporate environment, I have not found this to be the case. Good ideas get nowhere without buy-in
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.
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.
Some failures are not hard to predict. Politics is full of bad ideas that should’ve been shot down early.
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.
"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, ...)"
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.
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.
There are umpteen careerist assholes in corporate environments who reflexively shoot down everyone else's ideas who isn't senior simply to advance their and their friends' ideas to get credit and promotions instead. They refuse to listen honestly and double-down on "their way" with bullshit rationalizations how their ideas are "better". There is no convincing of anything or debating them publicly because it's contrary to their interests.
Politically-motivated adversarial "opposition" to "bad ideas" while silencing better ideas because of non-meritorious factors is distinctly far more troubling than shooting down genuinely worse ideas.
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.
There is more to your reputation than what sounds like a genuine growth mindset.
I'm a bit "spectrumish," so I sometimes miss the niceties.
The Japanese were not reticent about discussing problems. It was fairly brutal, but we made great stuff.
You do have to get to a working system, even if it is on a naive happy path before you can start preparing for the things that can go wrong.
When I encounter someone that is so fragile, that they literally fall apart, if we aren’t cheerleading, then I can’t work with them. I’m a creative, myself[0]. I’m familiar with the process.
It’s my experience, that we often can’t see things that will kill the project, until we start drilling into the details; sometimes, not too far. Finding these things is not a death sentence. It’s the first step to success. They exist; whether or not we choose to see them.
If your feet are wet, and you see pyramids, you’re in de Nile (or a fountain in Vegas).
I have learned that this kind of introspection needs to happen, as soon as possible. It’s the way that I have been trained to work, and I’ve been shipping stuff, for my entire adult life. Shipping is not for the faint of heart. If your idea is meant to be displayed on a refrigerator, then you have the luxury of chasing off disagreement. If it's supposed to be something that people stake their careers on, and pay for, then we need to have a thicker skin.
[EDITED TO ADD] A practical reason for finding the issues early, is who will be solving the problem. The earlier you find the problem, the more likely the person addressing it, will be creative. They will have more room to work, and they will be more invested in the vision, as opposed to the implementation. Late fixes are ugly.
What are you trying to do? Articulate your objectives using absolutely no jargon.
How is it done today, and what are the limits of current practice?
What is new in your approach and why do you think it will be successful?
Who cares? If you are successful, what difference will it make?
What are the risks?
How much will it cost?
How long will it take?
What are the mid-term and final “exams” to check for success?
> The 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.
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.
(I'm also not clear on what would make a typo ironic in this case.)
"Shooting down ideas is not a skill"
"This doesn't mean they know what they're doing. Their thoughts can be bad."What’s ironic here?
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.
Or are you ironically shooting down my idea that it is a skill?
It would be ironic for me to make a typo while bashing your spelling prowess. It would not be ironic if I didn’t.
It is similarly ironic that the Alanis Morrisette song about irony mostly mentions non-ironic things; “rain on your wedding day” isn’t ironic! And that’s ironic!
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?
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.
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.
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.
Its like going up to a tech person at a party and saying "i have a wonderful idea for an app"
In what world do these sound equivalent? Simply saying that something “sounds risky” is not serious criticism and wouldn’t hold any weight at any place I’ve ever worked at. You would have to actually explain why it sounds risky and point to something tangible.
Never point out the problems. There is literally no upside to doing this and plenty of downside. You will be labelled "Mr/Ms Negative". When you are inevitably proven right, you won't be thanked or heeded on future predictions. Instead you will be get feedback and comments about "not being a team player".
This is doubly true if it's in the context of a meeting. What many don't realize is that meetings aren't for feedback or criticism or for changing course. All of those decisions have already happened. The meeting is just there to make official what's already been decided.
If you truly want to influence the outcome, you do it 1:1 and outside meetings. And you create a paper trial so you're not the one left standing then the music stops.
The people who say "shooting down ideas is not a skill" are wrong but it doesn't matter because they somehow rise to positions of leadership anyway and create these toxic environments where the only two outcomes are that they were right or you failed.
>In a way this is virtuous, because I think startups are a good thing. But really what motivates us is the completely amoral desire that would motivate any hacker who looked at some complex device and realized that with a tiny tweak he could make it run more efficiently. In this case, the device is the world's economy, which fortunately happens to be open source.
After a while you learn to ignore criticism. I'm not really interested in what people have to say who would never become users anyway. They're simply not the demographic. It's all noise, and when I was younger and more impressionable it caused serious self-doubt. But when I demo something and I see the eyes light up, and then they say "well, what about this?", that's pure gold.
Valid and useful criticism is rare.
Critics providing other sorts of criticisms fall into a bimodal distribution. There are those who criticize because your proposal seems risky and they don't want to see you fail, and then there are those who criticize because they don't want to see you succeed.
A important word doing a lot of lifting here is "doing". talk is cheap, the problem is never lack of ideas.
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)
This is good for day to day ideas and innivation. Moonshots probably need something else which I am not sure what to propose. Other than POC with some numbers to get more explore time.
They used to have a lot of meetings. One of those meetings was called a “Design Review” meeting, or “DR.”
This was a big meeting, involving multiple departments, and usually involved hard-bitten, intelligent, and frequently, curmudgeonly, engineers, scientists, and managers.
It was their job to shoot holes in your proposal.
Making a presentation to a DR was a stressful thing, but it was also a highly effective forge. What came out of the meeting, was a robust, achievable project, with a solid plan, funding, and “on the record” support from all the teams involved. The idea would have real “legs.”
When you ask others to support your idea, you had damn well better expect them to be skeptical, and it’s a mistake to think of their skepticism as opposition. They often want to help you to make it happen, and anticipating problems, is a very important part of that.
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.
Nor is establishing an "all ideas are good ones!" culture.
However, the essential thing to do is to make sure that you're not shooting down the person. Better still, if you can socratically get them to the point of understanding why their idea won't work, that will have them own the shoot-down, and it may lead to a better idea that addresses the actual problem set more effectively.
When you know why something won't work, get other people there, but do it without being a jerk or crushing in inventive spirit.
I've been leading advanced development and applied science teams for decades. There aren't enough hours in the week to give every idea someone brings to me a full watch-them-realize shake, but I can (and do) take the time to make sure that the next time they have an interesting idea, they still want to bring it up.
Shooting down ideas is absolutely a skill; one that every innovator needs to have for their own ideas and the ideas of their collaborators. The way I learned it was to have others shoot my ideas down, and that's the way I teach it.
This is just not true in my experience, and doubly so after the advent of LLMs. I've seen more half-baked ideas presented than thorough plans.
The sort of meeting described in the article seems custom-made for gatekeeper creation.
If a meeting is about something else, don't raise your irrelevant idea. If a meeting is about your idea, then why are you having it if you haven't fleshed out your idea and already talked individually with a lot of stakeholders?
The only reason I can see for this sort of behavior is a kind of naivete that ascribes immense valuation to ideas, coupled with fear of losing credit if the idea loses association with your name.
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.
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.
No, it's not. Read the rest of his comment. I agree with it wholeheartedly. The article describes a terrible way of surfacing a new idea, and if you keep trying to get buy-in that way, you will keep failing.
> It doesn't help to waste oodles of time learning about mistakes made by others under different contexts and constraints.
Intelligence is practically defined by the ability to learn from others' mistakes.
> Avoiding mistakes is hard.
But useful. I once read about a machinist who started at a new job. His boss caught him trying to rework a piece he had screwed up, took the piece away from him and threw it on the discard pile. "We want you to focus on doing things right the first time, not fixing your mistakes."
1. Generate an idea. 2. Let critics help identify flaws. 3. If it's unsalvageable give up. Otherwise, modify the idea and go to (1).
This works well in a collaborative environment where people share ideas early.
> The person proposing has been thinking about this for weeks or months. They've tested pieces of it in their head or even built proofs of concept. They understand things about the idea that aren't obvious yet. And they're trying to explain all of this to a room full of people encountering it for the first time.
Assuming this blog post is based on real world experience, I want to point out that this describes a very slow feedback loop, and it's not necessarily typical or a good thing.
For instance, consider AI data centres in space: look, everyone knows its a high risk bet. If you do the easy thing of shooting it down, you may "win" the bet often enough. But try to understand that the world works by taking bold bets - each thing you see is a bold bet, not coming from a planned economy. I see my own laptop - the processor, the internet, the screen - everything was a bold bet at one point.
Shooting down ideas is easy and temporarily confers high status on you (since you win the bet more often than not) but in the long run such a game will show itself as ridiculous.
I'll just say that if there are some obvious enormous drawbacks to an idea, then you are responsible for mentioning your counter to them when presenting an idea. "Do X by seemingly breaking the laws of physics" had better be accompanied with at least some mention of how you are not, in fact, breaking the laws of physics.
There are two sides, the one presenting an idea and the one receiving it, and both have responsibilities. The article is about one way that one side often fails to maintain one of its responsibilities. No more than that.
It takes some wisdom
Things that are really worth someone's time are often something that should be well thought out, stress-tested, collectively agreed upon by at least a few. So shoot the unfeasible ones bang on so you don't waste time on it. Just don't make it personal; it's only ideas that need judgement, not the people.
Thanks for pointing out that inherent physiological flaw in humans, it's hard to realize that, this is very meaningful.
""" > None of these people are wrong or stupid. And none of them have added any value. Different opinions and more experience on current topic bring some value. """
I think the article doesn't try to figure it out, but frames the word as an self sufficient concept that is ultimately good. But it's not. A child could have the idea to see what happens if it touches a hotplate. It is certainly a personal lesson, but just because it's an "idea" it's not something that you should always explore.
I've met some people in my professional life where they shoot down virtually every single idea that come across them. And as a result they were right sometimes, never made a bug, and made the team around them extremely slow.
I will gladly shoot down any idea for unnecessary complexity and unnecessary feature, but otherwise it's "where's the demo"?
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.
Rejecting criticism makes systems more fragile.
Of course it's a balance and you also need to nurture new ideas.
Your boss is presenting something that affects you, or someone adjacent is presenting an idea for something that will affect you.
Or if someone asks what you think.
Doesn't that solve most of the complaints about productivity in this thread?
Not in agreement one bit.
Taking generic potshots at critical thinking is not a skill.
The article has good advice. The idea of postponing critique for a little bit to give an idea a chance to breathe, for instance. But then it also comes in with insulting BS like “Shooting down ideas is not a skill.” The whole article is obviously about improving one’s skill at the positive practice of culling bad ideas. Why throw such shade with the title?
The ignorant practice of refusing to consider an idea is not the same as critical thinking. Critical thinkers already feel bad about bringing rain to the parade. Do you have to make them feel even worse about it?
It's tough to write any article about any part of this topic, because there's so much nuance and the nuance matters. Yet none of us would read a post that captured the nuance, it'd be way too long and probably cover too much that is obvious. (But maybe now I'm shooting down someone who might attempt to write such a thing... please do, it's worth a try!)
> 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.
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.
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?
Yeah, the there-are-no-problems-only-opportunities crowd hates to be told that their proposal contains an insurmountable opportunity.
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.
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.
uh no.
The best way (IMO) is "Look, I've tried that idea and X happened, you might have better luck, but be aware"
uhhh, 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.
Others lose it all.
Most scenarios call for a bit of both.