Chapter 25 Flashcards — Negotiation and Leadership Skills
flashcards fsa negotiation leadership
Q: Why must architects negotiate rather than command?
A: Architects rarely have direct authority over developers or business stakeholders. Their influence must be earned through data, clarity, and credibility — org-chart position alone does not make recommendations accepted or implemented.
Q: What is the “business case approach” in architectural negotiation?
A: Every architectural recommendation must be accompanied by a business justification expressed in terms of risk, cost, or time-to-market. Technical quality attributes alone do not persuade business stakeholders.
Q: How should an architect translate a technical concern to a business stakeholder?
A: Replace technical jargon with business-relevant terms. Example: instead of “eventual consistency,” say “data may be slightly out of date for up to 2 seconds.” Instead of “high coupling,” say “changes in one area will require costly coordinated releases across three teams.”
Q: What is the most effective technique when a business stakeholder pushes back on cost or time?
A: Reframe from defending the technical choice to asking “What is the cost of not doing this?” — expressed as future rework cost, risk of incidents, or competitive disadvantage. Back the claim with data (incident history, benchmarks).
Q: What is the antipattern of “architecture by committee”?
A: Too many architects in a decision loop producing diluted, compromise-driven architecture that satisfies no one. The fix is to assign a clear decision owner per domain and use a pre-agreed escalation path when consensus fails.
Q: When should an architect yield vs. stand firm in a peer-level negotiation?
A: Yield when the other architect has domain expertise you lack, the decision is reversible, or the trade-off analysis genuinely favors their approach. Stand firm when the decision creates significant architectural coupling, violates a core quality attribute, or introduces hard-to-reverse technical debt.
Q: What is the difference between building consensus and forcing consensus?
A: Building consensus means all parties understand the decision and can genuinely support it. Forcing consensus means one party capitulates. Forced consensus produces hidden resistance that surfaces during implementation.
Q: What does the Second Law of Software Architecture say, and how does it apply to developer negotiation?
A: “Every architecture decision must be justified.” Applied to developers: always explain why a constraint exists (the quality attribute being protected, the risk being mitigated), not just what the constraint is. Understanding the rationale enables developers to apply it correctly in unanticipated situations.
Q: What is the danger of over-specification when negotiating with developers?
A: It kills creativity, demotivates senior developers who have relevant expertise, and misses better implementation solutions. Architects should specify constraints and goals, not implementation details.
Q: What is the danger of under-specification in architectural guidance?
A: It produces chaos, inconsistency, and architectural drift — each developer makes independent decisions that diverge from the intended architecture.
Q: How do code reviews function as architectural negotiation moments?
A: They provide a low-stakes, collaborative, concrete artifact for discussion. Architects can address architectural concerns without prescribing style, build credibility through technical engagement, and learn from developers about practical implementation constraints.
Q: What are the 4 Cs of Architecture?
A: Communicate (clearly, to all audiences), Collaborate (across teams and disciplines), Clarify (requirements, constraints, assumptions), Compromise (yield on non-essential points; don’t be dogmatic).
Q: Which of the 4 Cs is most frequently exercised, and why?
A: Communicate — architects must maintain multiple communication registers simultaneously: executive summaries for leadership, technical precision for developers, operational framing for DevOps.
Q: Which of the 4 Cs is most frequently under-exercised, and what is the consequence?
A: Clarify — architects often accept vague requirements (“it should be fast,” “it needs to scale”) without pressing for specifics. Unclarified assumptions are the most common source of architectural mismatch discovered late in a project.
Q: How should an architect apply “Compromise” without abandoning quality attributes?
A: Distinguish between essential constraints (non-negotiable — they protect core quality attributes) and preferred approaches (open to trade-offs). A good-enough architecture that ships is superior to a perfect architecture that never does.
Q: What is the “local-optimum trap” for architects?
A: Being too pragmatic — solving today’s problem with today’s tools without considering where the system needs to go. Produces architectures requiring complete rewrites as requirements evolve.
Q: What is the “ivory-tower trap” for architects?
A: Being too visionary — designing for speculative futures, creating complexity that burdens today’s teams. Produces architectures that are technically impressive but practically unmaintainable.
Q: What does “pragmatic visionary” mean as an architect ideal?
A: Solving the immediate problem with a design that can evolve toward anticipated future needs — without over-engineering for speculative futures. The visionary work is often structural (how things connect) rather than functional (what they do).
Q: Why should architects maintain coding involvement?
A: To preserve technical credibility with development teams. Architects who no longer write code find their recommendations questioned not because they’re wrong, but because developers doubt they understand practical constraints.
Q: Name three concrete ways an architect can maintain coding involvement without being a full-time developer.
A: (1) Write proof-of-concept code to validate architectural patterns before mandating them. (2) Contribute to infrastructure code (build scripts, shared libraries). (3) Participate in coding spikes for novel technical challenges.
Q: What does “eat your own dog food” mean for architects?
A: Use the patterns you prescribe. If you mandate a particular service communication pattern, implement it yourself in at least one place. This validates the pattern in practice and demonstrates to developers that it is workable.
Q: Why does architect presence at standups, code reviews, and retrospectives matter?
A: It transforms the architect from a gatekeeper into a genuine collaborator. Standups surface blockers early; code reviews reveal how architecture is actually being implemented; retrospectives expose what patterns are causing friction.
Q: What is the difference between mentoring and micromanaging for architects?
A: Mentoring asks “do you understand why this constraint exists?” and provides context — building autonomous, architecturally-aware developers. Micromanaging prescribes implementation details and creates dependency and resentment.
Q: What is the long-term goal of architectural mentoring?
A: To make the architect less necessary over time by building architectural understanding into the team — enabling developers to make good architectural decisions independently rather than becoming a decision bottleneck.
Q: What is the “ivory tower architect” antipattern?
A: An architect who designs in isolation, rarely interacts with the team, and issues mandates without context. Produces technically coherent but practically ignored architecture.
Q: How should an architect respond when a developer disagrees with an architectural decision?
A: Avoid invoking authority. Instead, ask the developer to articulate their concern in terms of a quality attribute or trade-off. This either surfaces a genuine problem the architect missed, or helps the developer understand why the constraint exists through their own reasoning.
Q: What makes demonstrating patterns through code more effective than diagrams alone?
A: Code is concrete — developers can see exactly what the architect means, ask questions at the implementation level, and adapt the pattern to their specific context with confidence. Diagrams are abstract and leave implementation ambiguities unresolved.
Total Cards: 26
Estimated Review Time: ~20 minutes
Priority: MEDIUM
Last Updated: 2026-05-29