Disagreement is normal in architecture work. Resolution determines outcome quality.
Common sources:
- Stakeholder vs architect — business want X; you think X causes Y problem.
- Architect vs architect — different opinions on technical approach.
- Senior vs junior — politics + expertise mismatch.
- Vendor vs internal — vendor pushes their solution; internal architect prefers different.
Resolution patterns:
1. Surface the disagreement explicitly.
Don't paper over. Name the disagreement; describe each position.
2. Identify the underlying interests.
People disagree because they value different things. Find the underlying concerns:
- Risk aversion?
- Performance vs cost trade-off?
- Familiarity with one tool?
- Past bad experience?
- Schedule pressure?
Once interests are clear, sometimes a third option satisfies both.
3. Document each option with trade-offs.
Write up: Option A (your preference), Option B (their preference), Option C (compromise). Pros/cons of each.
4. Bring data.
Performance projections, cost estimates, risk analysis. Move from opinion to evidence.
5. Bring outside perspective.
Reference architectures, similar past projects, industry patterns. Sometimes "company X did Z" persuades.
6. Escalate appropriately.
When disagreement persists, escalate to a senior architect or sponsor. Don't escalate too early; don't sit on disagreements forever.
7. Document the decision.
When resolved, write an ADR. Captures both the decision and the reasoning, so the disagreement isn't relitigated later.
8. Disagree and commit.
Sometimes you're overruled. Articulate your concerns; if they're not accepted, commit to the chosen path. Don't sabotage.
Common pitfalls:
- Avoidance — pretending agreement exists. Surfaces later.
- Personal attacks — disagree with the position, not the person.
- Stubbornness — winning more important than getting it right.
- Too political — back-channel maneuvering instead of direct discussion.
- Tone-deafness — failing to read when escalation will damage relationships.
Senior architect insight: the goal is the right outcome, not winning. Sometimes the other architect is right and you should change your mind. That's growth.
When you're consistently right, others learn to defer. When you're sometimes wrong but always reasonable, you build credibility for the times you're right.
Particularly hard case: stakeholder wants a clearly bad architectural decision. Your job is to surface the cost clearly, ensure they own the decision, document explicitly, then implement (if you must) while logging the dissent. Sometimes you're right and they have to learn the hard way.