6 ms·

90% of "that won't work" that I've seen in my career is really just "I don't like your idea, I like my idea better" in disguise. If something really won't work

90% of "that won't work" that I've seen in my career is really just "I don't like your idea, I like my idea better" in disguise. If something really won't work because of some fatal flaw or because it's truly a stupid idea, then sure you need to speak up. But if it's just a difference of opinion, then it's fine to propose another idea but it should remain a professional and technical discussion and agreement. But also be supportive of other ideas that aren't your own. I see too many people think other people's different ideas won't work because their ideas are better.

Yoric 5y ago
Years ago, I was leading the R&D in a start-up. The CEO was full of ideas. Some of them were very good, some really bad, most completely ill-matched to our priorities and limited resources. It quickly became clear to me that my job was being the "that won't work guy", in an attempt to make sure that we managed to finish our project before we ran out of funds. Almost all the problems we encountered with the project where things that happened as a consequence of me not shooting down random ideas before said CEO managed to get them started. Whenever I came back from PTO, or conference, etc. I regularly discovered that the CEO had split the already direly understaffed team to work on yet another brilliant idea that would make no sense before we even had our product. A few of the brilliant ideas I managed to shutdown: a reimplementation of git, a home-made bug tracker, a novel abstract interpreter for a programming language that didn't work yet, a transpiler between the old programming language used in-house and the new one, a Google Docs clone, a home-made IDE, a mechanism for storing source code as structured data to a database instead of a flat file... Things I didn't manage to shutdown: a custom NoSQL database, a home-made project tracker, a homemade front-end framework, a custom HTTP server, a custom standard library, a new type system, ... all of which were distinctly inferior from what was already available, and could possibly have become much better, with years of development which we couldn't afford. The company managed to release a first version of the product and folded a few months later, out of funding. Of course, shortly before that, I got fired for "blocking" the development of the company. My conclusion? Yeah, sometimes, "that won't work" is a matter of survival. But if someone needs to throw away their career by being the "that won't work" person, the company risks ending up full of yes people.
- Beldin 5y ago
  Interesting. I read the article as if it was talking about problems that needed solving. You're talking about ideas that (in the interests of the business) need shutting down. I would probably go with "that's not a good idea" for the latter. For the former, when brainstorming solutions, never shut down ideas. That's the whole point of brainstorming! If you want to point out downsides, try a variant of "I think you're on to something there, but how would we handle $DIFFICULTY?"
  - franciscop 5y ago
    It can be both, I read the comment you are answering to as problems that need solving. "A reimplementation of git" or "a home-made bug tracker" could be trying to solve the problem that they didn't have version control nor a bug tracker, but the proposed idea of creating one from scratch instead of using an existing one (in these clear-cut cases) is ill-advised.
    - Yoric 5y ago
      In this specific case, both git and a variety of bug trackers were available and very usable. Neither project answered a precise problem we encountered. Both might possibly have answered problems we might possibly have encountered when scaling up, something that never happened.
  - PeterisP 5y ago
    Sure, you should not shut down ideas when brainstorming solutions, but there's a point between brainstorming and implementation where the ideas do need to be reviewed mercilessly. The problem in the parent poster's company wasn't that they brainstormed about a home-made project tracker, it was that they went through with spending development effort on that. The brainstorming process is designed for generating alternatives, it's not suitable for choosing between alternatives, that needs to be done in a critical "anti-brainstorming" mindset.
- koheripbal 5y ago
  This is why when you apply to a job, it is as much about you interviewing them, as them interviewing you.
watwut 5y ago
Our system has multiple impossible to finish hard to maintain convoluted modules that indeed did not worked.
skeeter2020 5y ago
In my experience as a Dev Manager the easiest way to solve this is to put the expectation for coming up with a solution on the interjector or negative person. This is super effective in filtering the passionate contrarians from the the generally negative because it requires the person to do work, and the default to "no" people rarely will take on the responsibility.
Arete314159 5y ago
There's also "I don't know how to do that, and I don't want to learn how."

Yoric 5y ago

Years ago, I was leading the R&D in a start-up. The CEO was full of ideas. Some of them were very good, some really bad, most completely ill-matched to our priorities and limited resources. It quickly became clear to me that my job was being the "that won't work guy", in an attempt to make sure that we managed to finish our project before we ran out of funds. Almost all the problems we encountered with the project where things that happened as a consequence of me not shooting down random ideas before said CEO managed to get them started. Whenever I came back from PTO, or conference, etc. I regularly discovered that the CEO had split the already direly understaffed team to work on yet another brilliant idea that would make no sense before we even had our product. A few of the brilliant ideas I managed to shutdown: a reimplementation of git, a home-made bug tracker, a novel abstract interpreter for a programming language that didn't work yet, a transpiler between the old programming language used in-house and the new one, a Google Docs clone, a home-made IDE, a mechanism for storing source code as structured data to a database instead of a flat file... Things I didn't manage to shutdown: a custom NoSQL database, a home-made project tracker, a homemade front-end framework, a custom HTTP server, a custom standard library, a new type system, ... all of which were distinctly inferior from what was already available, and could possibly have become much better, with years of development which we couldn't afford. The company managed to release a first version of the product and folded a few months later, out of funding. Of course, shortly before that, I got fired for "blocking" the development of the company. My conclusion? Yeah, sometimes, "that won't work" is a matter of survival. But if someone needs to throw away their career by being the "that won't work" person, the company risks ending up full of yes people.

Beldin 5y ago
Interesting. I read the article as if it was talking about problems that needed solving. You're talking about ideas that (in the interests of the business) need shutting down. I would probably go with "that's not a good idea" for the latter. For the former, when brainstorming solutions, never shut down ideas. That's the whole point of brainstorming! If you want to point out downsides, try a variant of "I think you're on to something there, but how would we handle $DIFFICULTY?"
- franciscop 5y ago
  It can be both, I read the comment you are answering to as problems that need solving. "A reimplementation of git" or "a home-made bug tracker" could be trying to solve the problem that they didn't have version control nor a bug tracker, but the proposed idea of creating one from scratch instead of using an existing one (in these clear-cut cases) is ill-advised.
  - Yoric 5y ago
    In this specific case, both git and a variety of bug trackers were available and very usable. Neither project answered a precise problem we encountered. Both might possibly have answered problems we might possibly have encountered when scaling up, something that never happened.
- PeterisP 5y ago
  Sure, you should not shut down ideas when brainstorming solutions, but there's a point between brainstorming and implementation where the ideas do need to be reviewed mercilessly. The problem in the parent poster's company wasn't that they brainstormed about a home-made project tracker, it was that they went through with spending development effort on that. The brainstorming process is designed for generating alternatives, it's not suitable for choosing between alternatives, that needs to be done in a critical "anti-brainstorming" mindset.
koheripbal 5y ago
This is why when you apply to a job, it is as much about you interviewing them, as them interviewing you.

watwut 5y ago

Our system has multiple impossible to finish hard to maintain convoluted modules that indeed did not worked.

skeeter2020 5y ago

In my experience as a Dev Manager the easiest way to solve this is to put the expectation for coming up with a solution on the interjector or negative person. This is super effective in filtering the passionate contrarians from the the generally negative because it requires the person to do work, and the default to "no" people rarely will take on the responsibility.

Arete314159 5y ago

There's also "I don't know how to do that, and I don't want to learn how."