The first paragraph is killing me. Had that exact situation in a startup I joined. It was annoying and it ruined my passion for the project, because the outcome of that "one" discussion shaped the project for two years.
Guy (formerly a friend) got hired 2 months after me, decided that the backend I'm working on had no architecture, so forced me to discuss architectures with him (he had never designed, developed or worked on web applications before) for two months, in the end filled with animosity, until we settled on an architecture he proposed (because he befriended the CEO better than I did). It frustrates me, whenever I think about how 2 years of problem solving were wasted on a futile architecture that we had to completely rewrite into something more akin to what I initially worked on.
Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a solid simpler designs. Always on projects I was ether fully or partly coding.
I would try to get agreement on the people it would effect and nearly always rejected. Then everything I pointed out would go wrong but:
"This was completely unexpected"
"really interesting problem..."
At one point our ($100 million USD) security monitor product was down for a month until a customer noticed on our behalf and flipped out. Due to a several problems I had repeatedly pointed out (and fixing any one of them would of prevent it).
If I full sailed ahead then I would get alot of grudges. Culminating in "I found this bug and its your fault" (which was nearly always end up being because that very persons regression) or some other baseless attacks during meetings. It was tiring.
My managers always liked me however. shrug
In turns out almost every time my peers and betters actually never understood our discussions (but of course it would look bad if they actually asked questions). As my career went on I would start forcefully asking questions to confirm their understanding. And indeed this was nearly always the case. So I started making really nice layouts and explanations. And this got me a bit further. But if someone is missing years of required background you can't teach them in a realistic amount of time.
I am careful about who I work with now. I establish during interviews that your future team (or teammate) has the needed technical capacity for the problem set they have relative to their position. I think about the problem set the day before and discuss with them how they are solving it and it has saved me many a time. People are often critical of domain specific problems when given in an interview but I always start there and work my way down to the applicable fundamentals. The higher up they can answer the more senior. It also avoids the problem of asking out of scope questions/coding problems.
The structure (who is doing what, seniority, and how both are established) should always be crystal clear and changeable. Something to be aware of are non-formal structure in an org. Like a junior dev. on random team x has the CEO's ear. These are much harder to find and deal with. The worst problems an org can have IMO.
Guy (formerly a friend) got hired 2 months after me, decided that the backend I'm working on had no architecture, so forced me to discuss architectures with him (he had never designed, developed or worked on web applications before) for two months, in the end filled with animosity, until we settled on an architecture he proposed (because he befriended the CEO better than I did). It frustrates me, whenever I think about how 2 years of problem solving were wasted on a futile architecture that we had to completely rewrite into something more akin to what I initially worked on.