I've dealt with a designer before that said very literally and in no uncertain terms that there was no need for me to be involved in the high level feature design because he only needed to talk to the frontend engineer "actually implementing it" -- deeply ironic, given this feature was 95% core backend engineering, and so was in my wheelhouse. And so I ended up silently building the feature the way I suggested, and although he hemmed and hawed, he (and the rest of the team) later on conceded I was right.
FWIW, I view this more a failure of product management than anything. This should never have become an argument or adversarial interaction between engineering and design, and it's occurrence was to me a sign that things had procedurally failed quite a bit earlier. I'm happy I was able to save the project and get it to a successful launch (and certainly took the commensurate amount of credit), but I do wish some designers and product folks had more of a sense of awareness for how frequently this happens.
I think the most interesting things to create are often the work of groups of people who all have very different areas of expertise. Everybody's working together towards the same final product, but everyone has their own mental model of how that process works, and no one person can really see the full picture (like the story about the blind men and the elephant).
I've worked in different sorts of crossfunctional teams over the years at different companies in different industries- sometimes the other people are designers, or scientists, or people from other engineering disciplines who aren't down in the weeds like I am on the software side of things. Or sometimes they're the customers/clients/whatever, and are making specifications in a technical vacuum.
I think it's 100% pure human nature to always assume that one's own piece is the most complicated or meaningful part of a project, whereas other people's roles are more straightforward implementation details. I don't think it's from selfishness or conceit, rather it's plain old cognitive bias that we're all susceptible to. You know much more about all the stuff that needs to be done in your part of the system, and are painfully aware of the risks and challenges. You generally don't know nearly as much about the tasks other people are doing in other layers or fields, and from the outside looking in, it seems like everything is always more simple and straightforward than it actually is.
Even people like managers or designers who generally aren't concerned with minute technical details are susceptible to this type of cognitive bias. They play much more creative roles, in which they're literally deciding what the final thing is going to be, but with little or no guidance for how it should be done. That's up to the worker elves who have to assemble the component parts into the desired gizmo. Since the worker elves' reason for employment is assembling parts into gizmos, the people playing more purely creative roles always face a moral hazard of assuming that problems assembling their visions are due to failings of the worker elves themselves, rather than inherent weaknesses in the vision.
I kinda left off my conclusions from all of that: obviously you don't want a situation where (like in the designer vs web developer example), designers are empowered to dictate designs which would naturally result in poor implementations, and you don't want a situation where designers are subject to the whims of what the engineers do and don't feel like doing, and do or don't know how to do.
So how do you avoid those nonconstructive relationships? IMO/IME, you either need your specialists to have at least some intuition for what the other specialists do, or, failing that, you need to make sure that one group isn't politically empowered over any of the other ones. No one should be dictating terms to anyone else, everyone should have some ability to push back on things they disagree with, but at the same time if there's a clear consensus on something, one lone holdout can't stop the train. Pushing back on pusher-backers has to be possible too, when appropriate and necessary.
I don't think it's a bad thing to have specialists that have intuition about what other specialists do; in fact, that's a core responsibility for being a senior individual contributor. But, (and I covered this in my original comment), I think that this mediating labor is the role of product management, and there is a reason why product management is 100% a full-time job that cannot be skimped out on. I never understood why it needed to exist when I first started in my career, or I thought it was mostly a status-signaling BS role. However, the only way to mitigate that natural tendency of individuals to assume "it's 100% pure human nature to always assume that one's own piece is the most complicated or meaningful part of a project" is for a technical product manager to actually own the ramifications of all design and engineering decisions that are made and orienting the resultant product properly to the longterm strategic goals of the company. There is no substitute. Engineering and design direction are full-time roles in and of theirselves, and so too is product.
FWIW, I view this more a failure of product management than anything. This should never have become an argument or adversarial interaction between engineering and design, and it's occurrence was to me a sign that things had procedurally failed quite a bit earlier. I'm happy I was able to save the project and get it to a successful launch (and certainly took the commensurate amount of credit), but I do wish some designers and product folks had more of a sense of awareness for how frequently this happens.