TL;DR: Explain the competing requirements, the evidence behind your objection and what you did after the decision went against you. Support the permitted plan fully, while preserving an agreed way to respond if the risk materializes.
How to approach it
Choose a real disagreement with enough follow-through to discuss the result. Separate the decision from the relationship: a colleague can choose a different tradeoff without misunderstanding your argument. State your own authority and the decision owner's authority before describing escalation.
A strong answer
Start with the requirement that divided the options. For example, a managed queue may reduce operating work while introducing a service limit that matters during a burst. Explain both positions in terms their owners would recognize. Calling the other design “obviously unscalable” skips the workload and cost assumptions that made the choice difficult.
Then describe the evidence you brought. A representative load test, a recovery rehearsal or a cost model gives the team something to examine. Distinguish a measured result from a concern you could not test in time. If you presented the objection too late, own the timing; being technically correct does not make a last-minute redesign easy to absorb.
Consider this fictional example, which illustrates the reasoning rather than supplying a story to claim as your own. A team must choose between a managed queue and a queue it operates. You favor self-operation because the managed configuration has a tested drain rate of 400 jobs per second. The exercise's peak arrival rate is 300, but an outage could leave 60,000 jobs waiting. With 100 jobs per second of spare capacity, draining that backlog takes ten minutes under constant-rate assumptions.
The team accepts that recovery time because its background-job deadline is thirty minutes and it lacks capacity to operate another stateful service. You had treated faster recovery as mandatory without checking the business deadline. A useful response is to update your position, help implement the managed option and verify the queue-age alarm and recovery procedure. You can still record that a shorter deadline or higher peak rate would require a fresh decision.
If you continue to disagree, describe a concrete commitment. You might own the migration rehearsal, review the failure handling and document the recovery trigger. Avoid withholding effort so the chosen design proves your point. Equally, do not quietly introduce a second architecture “just in case”; that creates an operating obligation the team never approved.
The decision record should identify the accepted assumption and who can reopen it. In the example, sustained arrivals approaching the tested drain rate threaten recovery even before the queue reaches its storage limit. Agree what evidence initiates a capacity review, and distinguish that review from an emergency response to work already missing its deadline.
When reporting the outcome, use the evidence you actually retained. “The first two recovery rehearsals met the agreed deadline” is narrower and more useful than “the architecture was right.” If your concern later materialized, explain the response and your contribution without presenting the incident as personal vindication.
What interviewers probe next
“What would you change about your argument?” Identify a specific improvement, such as checking the recovery requirement before benchmarking or circulating the assumptions before the decision meeting. A different presentation cannot repair missing evidence by itself.
“When would you escalate?” Escalate an unresolved material risk to its authorized owner with the options and decision deadline. An active incident or prohibited action may require immediate escalation; routine disagreement does not require completing an elaborate hierarchy before anyone can decide.
“Does commitment mean implementing any decision?” No. Describe the applicable authority or mandatory constraint and the route for resolving it. A manager choosing an accepted service tradeoff differs from asking you to bypass a required control.
Common mistakes
A story that ends at the meeting leaves your subsequent contribution unexplained. Include what you implemented or verified after losing the argument.
Treating later success as proof that every original concern was wrong erases the conditions under which the decision worked. Keep the workload and observation period attached to the result.
Rehearse by writing two sentences defending the other option, then naming the observation that would change your own recommendation. If you cannot do both, revisit the decision record before memorizing the story.