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 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
>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.
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.
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.
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'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.
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.
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.
At some point you just have to spend spare cycles on ideas you think matter. What's harder than rejecting an idea is rejecting a finished, working product. And if your team says "I wish you had worked on something else", that's great, but if you're not my boss and and they're happy, who cares? And sometimes even your bosses. If you believe in something hard enough you will build political capital by meeting work obligations and spend it down working on your baby.
The 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 "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?
> "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.
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.
65 comments
[ 243 ms ] story [ 707 ms ] thread> 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.
It takes some wisdom
>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
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.
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.
uh no.
The best way (IMO) is "Look, I've tried that idea and X happened, you might have better luck, but be aware"
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.
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?
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
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?
> 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.
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.