Manu's Vault

Negotiating with Other Architects

3 min readStatus:Seedling

Core Idea

When negotiating with other architects, focus on data, shared architectural principles, and common goals rather than opinions or positional authority, as technical peers respond best to evidence-based reasoning.

Context: Architects often need to negotiate with other architects within an organization:

  • Enterprise architects
  • Domain architects
  • Peer application architects
  • These negotiations differ fundamentally from discussions with business stakeholders or developers
  • Involve technical peers who understand architecture deeply and may have strong, well-reasoned opinions that conflict with yours

Key to Success - Data-Driven Discussion:

  • Unlike business stakeholders (who care about cost and time) or developers (who focus on implementation feasibility), other architects respond to:
    • Empirical evidence
    • Performance metrics
    • Historical precedent
  • Example: When two architects disagree on microservices vs. modular monolith:
    • Ineffective: “I think microservices are better”
    • Effective: “Our transaction volume of 500/second doesn’t justify the operational overhead of microservices, as shown by this performance analysis”

Use Shared Architectural Principles:

  • Most architects share fundamental values like simplicity, maintainability, and scalability
  • Frame your position in terms of these shared principles
  • Example: “This design follows the Single Responsibility Principle we’ve both advocated for, which reduces coupling and improves testability”

Avoid Positional Authority:

  • Don’t say: “I’m the senior architect, so we’ll do it my way” (destroys trust and collaboration)
  • Don’t cite authorities dismissively: “Martin Fowler says…” without context can appear dismissive
  • Instead: Reference authoritative sources as supporting evidence within a larger argument, not as conversation-ending appeals to authority

Focus on Common Goals:

  • Both architects presumably want the system to:
    • Succeed
    • Meet requirements
    • Be maintainable
  • When disagreements arise, return to shared objectives
  • Example: “We both want this system to handle future growth. Let’s examine which approach better supports our five-year scalability projections based on the data we have”

Technical Trade-off Analysis:

  • Explicitly acknowledge that your proposed solution has downsides—no architecture is perfect
  • By transparently discussing trade-offs, you:
    • Demonstrate intellectual honesty
    • Create space for collaborative problem-solving rather than adversarial debate

Why This Matters

Organizational Impact: Architect-to-architect disagreements can paralyze important decisions and create organizational friction:

  • Poor negotiation approaches lead to:
    • Compromise solutions that satisfy no one
    • Entrenched positions where ego trumps engineering
  • Data-driven, principle-based negotiation:
    • Maintains professional relationships
    • Reaches decisions grounded in evidence rather than politics

Career Implications: In matrix organizations or large enterprises:

  • Architects must frequently align decisions across domains, teams, or product lines
  • The ability to negotiate effectively with technical peers becomes essential for:
    • Career advancement
    • Organizational impact

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks