Not a problem if they don't say it since then it's not derailing the conversation. It could even be a benefit if it motivates them to look for actual holes.
you just have to refuse to accept input like 'I don't buy it', 'I tried something like that before and it was a failure', 'thats a code smell', 'I saw a blog post about how that is an anti pattern', and other unsubstantiated disses on an approach. if its so bad, you should really be able to put some real words behind that.
totally. not saying you shouldn't use your experience. but you should use that to really paint a picture of how it can go sidewise instead of just claiming authority. the former really moves everyones understanding forward.
You're not wrong, but the problem is that people sometimes just flat can't see it and think they know better than you.
The example I gave above, I definitely did spent months explaining to them how the risk to a library like that grows unexpectedly over time. How it's a small risk at first but if you don't consider the use of that library over the next few years you don't see where the risk profile ends up.
What's interesting is that I had a similar conversation with a VP recently. What I told him is that sometimes people really just flat out can't see it and in that case you have to "rule by fiat" as it were and issue an edict. If you wait for compromise with someone who just can't see it you'll get nothing done, especially if nothing can ever be agreed upon.
and I say this as someone who is very particular about the battles I'll fight, I'm a fan of compromise but only if everyone in that conversation truly understands all sides of the issue or I think it ultimately doesn't matter (yak shaving).