4 exercises — presenting both options neutrally, defending a technical decision under pressure, negotiating build vs. buy, and conceding a point professionally.
0 / 4 completed
1 / 4
You need to present a technical trade-off between REST and GraphQL APIs to stakeholders including engineers and the product team. Which presentation is most balanced?
Option C is a complete trade-off presentation because it:
1. Presents both options neutrally in parallel: REST's strengths are described as real strengths (not strawmen), GraphQL's weaknesses are stated honestly 2. Names constraints in technical terms: "over-fetch / under-fetch", "network-layer caching" — uses correct vocabulary but with functional explanations 3. Connects the recommendation to the specific context: "three client types and a small backend team" — not a generic recommendation, but one grounded in this team's situation 4. Invites pushback on a specific point: "I'm open to pushback on the caching concern" — names exactly where the recommendation is weakest, which builds trust
Why A fails: Declares a winner without analysis — stakeholders who care about REST will feel their concerns weren't considered
Why B fails: "Hard to say" is not a trade-off analysis, it's an abdication
Why D fails: "More standard" is an authority argument, not a contextual recommendation
Trade-off formula: Option A (strengths + honest trade-off) → Option B (strengths + honest trade-off) → Recommendation grounded in THIS context → Invite pushback on your weakest point
2 / 4
You're defending a technical decision (using PostgreSQL over MongoDB) and a senior engineer challenges it in a design review. Which response best defends the decision?
Option C is a strong decision defense because it:
1. Acknowledges the challenge as a "good" one: signals confidence, not defensiveness 2. Restates the specific technical reasoning: "8–12 tables", "sub-50ms with that join depth" — precise technical evidence 3. Names the specific cost of the alternative: "denormalization adds maintenance complexity" OR "round trips add latency" — shows you actually evaluated MongoDB 4. Finds a partial concession that's honest: "document data in user profiles is a valid gap" — acknowledges where your decision has a weakness 5. Offers a synthesis: "JSONB columns for that subset" — shows a path that incorporates the challenger's concern without abandoning the decision
Why A fails: "I already explained this" is dismissive and signals the decision wasn't thought through well enough to re-articulate
Why B fails: Immediately yielding to pressure suggests the original decision lacked foundation
Why D fails: "Decision already made" cuts off technical dialogue — in a design review, that's the wrong signal
Decision defense formula: Acknowledge challenge → Restate specific technical reasoning → Name the cost of the alternative → Find the valid gap in your position → Offer synthesis
3 / 4
You recommended building an internal authentication library, but your manager prefers buying a third-party solution. You believe the build option is correct. How do you negotiate this respectfully?
Option C is a collaborative build vs. buy negotiation because it:
1. Acknowledges the validity of the manager's preference: "lower upfront cost and faster to integrate initially" — shows you understand why they prefer it 2. States a specific, concrete concern: "multi-tenant isolation" and "custom RBAC integration" — not "vendor lock-in" (generic) but specific technical requirements 3. Provides research to support the concern: "I checked the three leading vendors" — not just an opinion, but evidence 4. Expresses genuine openness to the alternative: "I'm not opposed to buying — I'd actually prefer it if the fit is right" — removes the adversarial dynamic 5. Proposes a bounded validation step: "3-day evaluation sprint" — a small, low-cost test that either validates the manager's preference or confirms the concern 6. Stakes a personal commitment: "I'll drop my build preference immediately" — shows this is about the best technical outcome, not ego
Why A fails: Repeats the position without new reasoning
Why B fails: Uncovers capitulates without sharing the technical concern — leads to a decision that may fail later
Why D fails: "Vendor lock-in" is a generic concern that doesn't reflect the specific technical requirements
Build vs. buy negotiation: Acknowledge preference → State specific concern + evidence → Express genuine openness → Propose bounded evaluation → Personal commitment to accept the result
4 / 4
You need to concede a technical point during a negotiation. Which is the most professional way to yield on a decision?
Option C is a professional concession that preserves your credibility:
1. Names what changed your mind: "[specific new data/argument]" — shows your original position wasn't wrong given the information you had; you're updating based on new information 2. States exactly what you're conceding: "I'm withdrawing my recommendation for [A] and supporting [B]" — precise, not vague 3. Adds a review condition: "I'd want to add one condition: review in Q3 once we have real traffic data" — acknowledges that decisions under uncertainty deserve checkpoints 4. Links the condition to the original concern: "in case the [specific risk I named] materialises" — shows your original concern was valid even if the recommendation changes
Why A and B fail: "Fine" and "you're right" without context — sounds like capitulation under pressure rather than an update based on evidence
Why D fails: "I disagree but I'll go along" — this is the worst pattern; it implies you're not committed to the decision and sets up an "I told you so" dynamic if things go wrong
Professional concession formula: [What changed your mind] → [Exactly what you're conceding] → [Supporting the new option] → [One review condition linked to your original concern]