The example that comes to mind for me is a non-engineer suggesting we relax important security constraints in a meeting with non-engineering decision makers present. In this case, the entire line of thinking is that it's acceptable to e.g. store unhashed passwords in the DB and not implement CSRF protection if it gives the team time to do other tasks, and it needs to be made clear that it's totally unacceptable to trade speed for safety.
It's almost always possible to explain why you shouldn't make a bad tradeoff like that, though.
So I was limiting the advice to engineering teams brainstorming solutions together.
Yes: I "only" know why it doesn't work... something I would hope would have extreme value, as I am not simply telling you "you are dumb" and refusing to discuss it, even if you don't understand the math or physics involved and thereby can't tell the difference; and I don't have something else for you that does anything similar: if I had any hope this was possible, I assure you I would be dedicating quite a lot of our resources towards figuring out how to pull it off. I will even admit that maybe, just maybe, you are correct, and what you want somehow can be done because everyone who has ever studied this before is wrong... but it isn't going to anyone on our team--not me, and especially not you, who figures this out--so let's spend our time talking about things that aren't a waste of our time and money. Am I a "negative Nancy"? Sure... if that's what you want to call someone who uses their time effectively."""
-- someone who has often been in the situation of having to have this conversation about the same scant handful of "obvious" ideas over and over again, often times for years (essentially, until the project is scrapped)
4 weeks for a brand new fuel cell is a bit short, but you can just buy them on the open market.
He didn't know that I had some "trial by fire" experience in previous jobs, and I calmly stood my ground. What he was proposing violated the second law of thermodynamics.
Thankfully the person running the meeting proposed tabling the idea. But it remained in the product requirements document for the duration of the project.
I learned that sometimes math and physics are best discussed privately. ;-)
Would you have preferred to remained silent and afterwards having to implement a physical impossible concept?
Also seen the ‘actually it was fine, the objector was just in a bad mood and couldn’t see past their own prior experience and was being a pain in the ass’ more times than I can count.
Which is why hopefully you have senior leadership that can see through the BS and get things moving in a workable direction.
Something might not work, and if you know it won't and know a way that will, sure interfere (hopefully with tact), and steer the conversation towards a more likely solution.
But, if you only know why it won't work, but not of anything else that could work, than it seems useful to discuss further, but can't it be made to work?