There’s generally two separate principles at work to resolve disagreements. The first is the general concept of “ownership” - aspects of a specific feature or piece of content “belongs” to a specific developer. The second is that any given team usually has a chain of command, a hierarchy of who gets to overrule who. If the owners of something can’t agree, it is up to the chain of command to determine who wins.
These “owner” developers are usually the ones who get to be the decider, since they are the ones who are building the feature or content and are the ones held responsible if it isn’t working for whatever reason. If things aren’t working, it’s usually up to the owner(s) of the feature to make it work. If the stakeholders can’t agree (e.g. the designer on the feature wants X but the engineer on the same feature disagrees), it goes up the chain of command to someone with the authority to make the call.
The chain of command goes from those of us in the trenches (e.g. combat designer), then the leads we report to (e.g. lead combat designer), their leads (e.g. lead designer), their leads’ leads (creative director), and finally the ultimate authority on the team (executive producer). Thus if I make a decision as a combat designer, the lead combat designer can overrule me. The lead designer can overrule her, the creative director can overrule the lead designer, and the executive producer can overrule the creative director.
One of the team leadership’s responsibilities is to make decisions when their subordinates do not agree. It is generally rare for lead decisions to get overruled by those above them - lead developers are typically given their responsibilities in part because they’ve demonstrated decision-making skills. That isn’t to say it doesn’t happen, but it’s fairly rare. You should note that the escalation up the chain of command means that the decision maker is often less knowledgeable about the details of the design (since she likely is overseeing a lot more than one particular feature), but more knowledgeable about the needs of the project in general.
Usually these kind of disagreements happen because the original design is discovered to be missing some important context that wasn’t discovered until later in the development process. The result is that the design as written cannot stand and a new design that properly handles the new context must be chosen. Multiple valid designs might be proposed, and the decision for which design must be made. In the case where the stakeholders cannot agree, somebody higher up the chain of command makes the call (usually after weighing the various options and the needs of the project, like I mentioned above).
Got a burning question you want answered?