general

Have Backbone; Disagree and Commit: Amazon Interview Guide

Have Backbone; Disagree and Commit is the Amazon leadership principle with two halves, and interviewers score both. The first half asks whether you will challenge a decision you think is wrong, with reasons, even when the person across the table outranks you. The second asks what you do after you lose the argument: commit fully, or quietly keep fighting.

Most candidates prepare only the first half. They bring a story about standing their ground and winning. That story is incomplete. The principle is named after the uncomfortable case, where you disagreed, were overruled, and then worked as hard for the decision as if it had been your own.

This guide covers the official wording, what the principle looks like day to day, examples from engineering and non-engineering roles, 14 interview questions, a worked STAR answer, and the follow-ups that catch a half-prepared story.

The official wording from Amazon

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting.

That is the first sentence of the principle on Amazon's leadership principles page. The rest asks leaders to have conviction and be tenacious, not to compromise for the sake of social cohesion, and to commit wholly once a decision is made.

The word "obligated" matters. At Amazon, staying silent when you think a decision is wrong is a failure, not a courtesy. Jeff Bezos described the second half in his 2016 letter to shareholders: when there is conviction but no consensus, it saves everyone time to say openly that you disagree and will commit anyway, and he gave the example of approving an Amazon Studios production he personally doubted because the team had the stronger case.

What Have Backbone; Disagree and Commit means in practice

You state your disagreement in the meeting where the decision is being made, not in a side channel afterwards.
You bring the reason and the evidence, not only the opinion. "I think this is wrong" is a feeling; "this doubles our write load and here is the benchmark" is a challenge.
You disagree with the decision, not the person. Tone is part of the score.
You know when to stop. Once the decision is made, you ask what would change it, note that, and move on.
You commit visibly. You tell your own team the decision and the reasons as if they were yours, without the eye roll.
You keep the receipt without using it. If the decision turns out badly, you help fix it instead of saying you told them so.

Have Backbone; Disagree and Commit examples at work

The engineer who lost the database argument. A senior engineer argues in a design review that the team should keep its relational database rather than move a service to a document store. He brings query patterns and a migration cost estimate. The principal engineer and the manager choose the migration anyway, for reasons about team skills he had not weighed. He writes the migration plan himself, and when a data modeling problem appears in month two he fixes it rather than reopening the decision.

The data analyst who challenged the metric. A leadership team wants to report "active users" using a definition that counts anyone who opened the app. The analyst shows, in the meeting, how that number moves with a push notification and proposes a stricter definition. Leadership keeps the broad metric for the board deck but adopts hers for internal goals. She reports both, consistently, without editorializing.

The product manager who disagreed with the launch date. A PM believes the launch is two weeks early and says so to the director, with the open bug list and the support team's capacity. The director holds the date because of a partner commitment. The PM reorganizes the plan around the date, cuts two features openly, and runs the launch. Afterwards she writes the retrospective with the data on what the early date cost, and the next launch gets a buffer.

The finance manager who pushed back on the forecast. A finance manager thinks the regional revenue forecast is 15 percent too optimistic and says so, with last year's seasonality. The VP keeps the number. The manager builds the plan to that target, tracks the gap weekly, and flags it at the first checkpoint with options rather than blame.

Have Backbone; Disagree and Commit interview questions

The interviewer is looking for a real disagreement, with a person who could overrule you, where you can describe both your challenge and your commitment. Prepare for these:

Direct questions

Tell me about a time you disagreed with your manager. What did you say, and what happened?
Describe a situation where you thought you were right but your peers or your manager did not agree. How did you make your case, and what was the outcome?
Tell me about a decision you committed to even though you disagreed with it.
Tell me about a time you had to step up and challenge a team member's approach.
If your direct manager instructed you to do something you disagreed with, how would you handle it? Has it happened?
Tell me about an unpopular decision you made. How did you handle the pushback?
Tell me about a time you did not accept the status quo.

Questions that test it indirectly

Describe a situation where other members of your team did not agree with your ideas. What did you do?
Tell me about a conflict with someone on your team. What was it about, what did you do, and how did it end?
Were you ever frustrated by having to follow a decision you thought was wrong? What did you do with that frustration?
How do you express disagreement about parts of a project you do not control?
Tell me about a time you changed your mind during a disagreement. What changed it?
Tell me about a time you were overruled and the decision turned out to be wrong. What did you do?
When did you last give difficult feedback to someone more senior than you?

A sample STAR answer

Question: tell me about a decision you committed to even though you disagreed with it.

Situation. I was the tech lead for a checkout team when our director decided to rebuild the cart service in a new framework the platform team was standardizing on. We had a stable service with three years of edge cases in it, and we were four months from the peak season.

Task. I needed to make the case against the timing, and if I lost, lead a rewrite I did not believe in without my team picking up my doubts.

Action. I asked for 30 minutes in the next planning meeting and brought three things: the list of 41 edge cases the current service handled, our incident history for the last two peaks, and an estimate showing the rewrite would finish six weeks before peak with no buffer. I proposed starting the rewrite after peak. The director explained that the platform team's support for the old framework ended in the spring, which I had not known, and that a delay would leave us unsupported during the next peak instead. I said I still thought the risk was high but that his reason was better than mine, and that I was in. I then told my team the decision and the support reason in my own words, moved the edge-case list into the new service's test plan so nothing was lost, and asked for a feature freeze on the old service so we were not maintaining two.

Result. We shipped the rewrite seven weeks before peak, with all 41 edge cases covered by tests, and the peak had one minor incident versus four the year before. My director later told me that the edge-case list was the reason the rewrite went well, and that it only existed because I had argued against it.

Why this answer works

The disagreement is specific and evidence-based, with a counter-proposal, not a complaint.
The moment of commitment is explicit: the candidate says why they changed position and what they told their team.
The commitment is active. The edge-case list and the feature freeze show someone working for the decision, not merely tolerating it.

What the interviewer probes next

"What exactly did you say, and to whom?" They want to hear the challenge in your words, with the audience. "I raised concerns" is not enough.
"What did you do after you were overruled?" This is the question most candidates are not ready for. Have a concrete action that shows commitment.
"Did your team know you disagreed?" If you told your team the decision was wrong, you did not commit. If you hid your view entirely, you may not have had backbone.
"Were you right?" Either answer is fine. Being wrong and saying so cleanly can score higher than being right.
"What would make you reopen a decision?" The good answer is new information, not more time or more frustration.

Common mistakes

Only telling the winning story. If you always convinced them, the interviewer has no evidence you can commit.
Only telling the losing story, with resentment. A story that ends with "and I was proven right" and nothing else reads as grudge-keeping.
Disagreeing without data. Conviction is required, but conviction without evidence is stubbornness.
Picking a peer-level squabble. The principle is about challenging decisions, usually made above you. A debate between two equals about tabs and spaces is not it.
Describing a compromise as commitment. Splitting the difference to keep the peace is what the principle explicitly warns against.
Skipping the result for the team. Say what your commitment produced, not just that you stopped arguing.

Related leadership principles

Earn Trust is what makes disagreement survivable: candor and respect in the same sentence.
Are Right, A Lot is why you bring evidence and seek disconfirming views before you dig in.
Ownership is the commit half seen from the other side: once decided, the outcome is yours.

The full list, with questions for each principle, is in our Amazon leadership principles guide. Structure every story with the STAR method and keep them in a story bank so you can pull the right one under pressure.

Want someone who has sat on an Amazon loop to pressure-test your disagreement stories? Get matched with a coach, then read Earn Trust and Are Right, A Lot next.