Playbook / Behavioral (STAR) / Navigating deep technical disagreement with peers

Navigating deep technical disagreement with peers

Evidence status — rewritten from Lucid production architecture conflict, anonymized peers: delivery pressure to keep vendor-coupled EDI/TrueCommerce–SAP paths or push full agent autonomy for speed, versus architecture’s owned-platform + HITL invariants. Replace anonymized roles with private real names before onsite. This replaces the blocked synthetic “demo vs gateway” repo story.

Expected question

"Tell me about a time you strongly disagreed with a peer or partner team on a technical approach. How did you handle the conflict, and what was the outcome?"

Variant forms

Interviewers often probe the same competency with different framing — recognize the archetype and answer with your story:

  • "Tell me about a time you had a conflict with a coworker."
  • "Describe disagreeing with an architect or tech lead on a design — what did you do?"
  • "Tell me about a time you were wrong in a technical debate."
  • "How do you handle it when two Senior/Staff engineers dig in on opposite solutions?"
  • "Describe escalating a disagreement — when is it right vs political failure?"
  • "Tell me about disagree-and-commit: you lost the argument but still executed."
  • "Walk through a design review that got heated — how did you reset it?"
  • "Tell me about conflict across org boundaries (platform vs product)."

The question, as it might actually be asked

"Tell me about a time you strongly disagreed with a peer on a technical decision." Staff+ loops test conflict under ambiguity: evidence over ego, written decision records, and disagree-and-commit without sabotage.

Candidate-owned evidence prompts

  1. Real peer role/name (private) and their exact competing proposal.
  2. What evidence or thin-slice test moved the decision.
  3. Concessions each side made; relationship afterward.
  4. Public-speak boundaries for vendor and team identifiers.

Author reference (do not memorize)

Use role titles in public rehearsal (“Staff engineer on a product cluster,” “operations partner”). Swap in real names only in private prep.

Situation

At Lucid, while delivering the multi-agent supply-chain platform and EDI modernization, the same fight kept showing up. Delivery-oriented peers optimized for near-term case completion. Architecture optimized for owned boundaries and irreversible-action safety (P). Flashpoint: keep accelerating on vendor-coupled TrueCommerce/SAP TM paths — and/or maximize agent autonomy on those flows — versus absorb migration complexity into internal, governable services with HITL on high-risk actions. That second path is what made the later licensing exit operable — the resume ties the broader supply-chain platform to $10M licensing eliminated and $7M annual net (P, STAR bank 2026-08-13 — two numbers, not the stale PDF). In this STAR, lead with the conflict resolution and owned boundary; treat the dollar as a related outcome, not the punchline of the disagreement.

Both sides were acting in good faith. One protecting date and familiar ops muscle memory. The other protecting long-term cost, auditability, and blast-radius control. I don't play this as heroes vs blockers.

Task

Resolve the disagreement without (a) silently accepting vendor lock-in or unsafe autonomy "just this quarter," or (b) blocking the business with purism that shipped nothing. Leave a durable decision record — not a hallway truce that dissolves next sprint.

Action

  1. Restated the shared goal in writing. Keep supply-chain cases flowing and exit license-heavy coupling with controllable automation. Conflict was sequence and risk, not values.
  2. Made options concrete on a page. Stay vendor-coupled; dual-run with a hard exit date; cut over to owned EDI/event boundaries with risk-tiered HITL. Cost, lead time for partner changes, and incident classes — not vibes.
  3. Proposed a narrow compromise. Protect near-term throughput on a dual-run/wave plan. Refuse unrestricted autonomy. Refuse "forever vendor" as the architecture end-state.
  4. Time-boxed the debate with an accountable decision owner and an explicit disagree-and-commit offer if leadership chose the faster residual path — residual risk logged.
  5. Argued from incident class and economics, not seniority. Untracked side effects and recurring license drag vs migration pain.

Result

  • What shipped was owned internal capability for critical EDI/supply-chain workflows plus governed automation — aligning with the resume's licensing-elimination and multi-agent platform outcomes (P).
  • Relationship outcome I'd emphasize: peers could execute the wave plan without losing face; architecture conceded pure big-bang cutover.
  • What stuck: written options, wave migration, risk-tiered autonomy — reused when similar "speed vs ownership" fights showed up across clusters.
  • Honest limit: not every disagreement ends this cleanly. The Staff+ signal is the mechanism, not the happy ending.

The follow-up question you should expect

"What if they still refused?" Escalate on risk and ownership, not personality — who accepts the incident class and continuing license drag if the bypass ships? If leadership accepts, disagree and commit and execute cleanly. If not, help implement the safer wave. Never half-implement to "prove them wrong." That's sabotage dressed as diligence.

Staff+/Principal signal rubric

  • Mid-level: describes a disagreement; may focus on winning.
  • Senior: uses data/options; reaches a team decision.
  • Staff+: writes trade-offs, time-boxes, disagree-and-commit, preserves execution quality.
  • Principal: turns the conflict into an org invariant (owned platform boundary + HITL) so the debate does not recur every quarter.
← A technical bet that did not pay offMentoring and growing engineers toward the next level →