How to answer interview questions about the Amazon leadership principle “Have Backbone; Disagree and Commit”
The thirteenth Amazon Leadership Principle is “Have Backbone; Disagree and Commit.” If you’re preparing for an interview at Amazon, you should ask yourself what the company means by having backbone and how this leadership principle relates to the role you’re applying for.
If you don’t know about the Amazon leadership principles, consider first reading this article about interviewing at Amazon.
How Amazon explains the “Have Backbone” leadership principle:
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
What does the “Have Backbone” leadership principle mean?
What does the phrase “to have backbone” mean? It’s an English idiom that means to have strength, particularly in the face of adversity. If I “have backbone,” it means I will stand up for my ideas.
Do you fight for your ideas or do you give up on them if someone challenges you?
What if you fight for your idea (meaning you "disagree" with someone) and don't win - what do you do then? Do you support the person who did win ("commit" to their idea) or do you try to work against them because your idea didn't win?
If you haven’t read my post on the “Are Right, A Lot” Amazon leadership principle you should read that, because that leadership principle includes how you manage conflict, which is related to the “Have Backbone” leadership principle. Both leadership principles deal with interpersonal relationships, in particular conflicts that arise between two people, or one person and a group.
How to answer the “Have Backbone” leadership principle interview questions
If you’re someone who thrives in competitive environments, be prepared to demonstrate that you can manage conflict calmly and rationally, that you can convince others with data, not by yelling or being unnecessarily aggressive.
Alternately, having to fight for your idea may make you uncomfortable. If this type of culture intimidates you, give extra attention to your preparation for interview questions related to conflict. If you’re unable to answer the questions directly, you may come across as someone who lacks the backbone to work in a competitive environment. And Amazon really does have a culture of “sharp elbows” (aggression and conflict) so if you want the job, you’ll need to hide your discomfort with conflict or at least show it won’t stand in the way of your leadership.
Include these points in your answer
1. What was your idea?
First, summarize for the interviewer an idea that you had. Tell a story about how you were convinced that your idea was the right way forward.
2. What was the point of conflict?
After you explain your idea, describe how and why someone didn’t agree with your idea. There must be another person who didn’t agree with you, meaning the conflict needs to be with one specific person. You can’t just say “the executives” didn’t agree with me. If you do that your answer won’t be specific enough.
3. How did you convince the other person?
Then, discuss what tactic you used to win the other person over. The best way to impress your interviewer is to describe how you used data in making your argument.
4. If you lost, commit
Finally, if you were unsuccessful in persuading others, explain that you “committed” regardless. It’s okay if you lost the argument, but demonstrate that you were mature enough to support the decision that the company chose. If you were successful in winning support for your idea, skip this step.
Other things to be aware of when creating your answer
Give details of the conflict
Your goal should be to demonstrate how you managed the conflict itself, so don’t fast forward over it. What did you say? What did the other person say? Did you have a meeting? Did you look at data together?
I’ve found that my clients sometimes want to say very little about the actual disagreement and are eager to rush to the solution, which is a mistake. Dwell more on the details of the conflict. I know it may be boring to relate the actual conversations you had, and normally I think that’s too much detail for these stories, but talking about the details is the only way to show how you handle the interpersonal aspect of conflict.
Don’t agree just to agree
Amazon doesn’t want you to agree with your colleague or client just to avoid conflict. They are not a company that values social cohesion. What they like is truth seeking. They want you to figure out the truth, and often the way you do that is through conflict.
Some companies do value social cohesion. If your current company is one of these, you may have trouble constructing good answers to the conflict questions.
If you lose the argument - iterate and fail fast
You may try to convince the other person and still lose. If that happens, of course you want to show that you will support their idea, not undermine it. In fact, this is part of the tension that is built into the Backbone principle.
This principle discourages social cohesion for its own sake and encourages iteration or “failing fast.” If you don’t know the best way forward - if there are two points of view - what is the best course of action? Try something (even if it was the other person’s idea) and see if it works. If it does, good. If it doesn’t, you will learn from this failure.
Interview Questions Related to the “Have Backbone” Leadership Principle
If your interviewer asks about this Amazon leadership principle, she or he might ask one of the following questions:
Describe a situation where other members of your team didn’t agree with your ideas. What did you do?
Tell me about a situation where you had a conflict with someone on your team. What was it about? What did you do? How did they react? What was the outcome?
Tell me about a time when you did not accept the status quo.
Tell me about an unpopular decision of yours.
Tell me about a time when you had to step up and disagree with a team member’s approach.
If your direct manager was instructing you to do something you disagreed with, how would you handle it?
Describe a situation where you thought you were right, but your peers or supervisor did not agree with you. How did you convince them that you were right? How did you react? What was the outcome?
Those are the types of questions associated with this principle, and below are some from “Are Right.” You can see how they are really the same questions. Let’s review some of the questions from the “Are Right” principle:
Tell me about a time you disagreed with a colleague. What is the process you used to work it out?
Tell me about a time that you strongly disagreed with your manager on something you deemed to be very important to the business. What was it about and how did you handle it?
Tell me about a time where someone openly challenged you. How did you handle this feedback?
Give me an example of when you took an unpopular stance in a meeting with peers and your leader and you were the outlier. What was it, why did you feel strongly about it, and what did you do?
When do you decide to go along with the group decision even if you disagree? Give me an example of a time you chose to acquiesce to the group even when you disagreed. Would you make the same decision now?
We see that the “Are Right” and “Have Backbone” principles are related. Show your interviewer that your approach to your work results in you being right a lot, and that you have the courage to fight for your ideas.
How many stories do I need for this leadership principle?
Most people say that you should have two examples for each principle. That’s a good benchmark, but what if you get asked four Have Backbone questions? Will you have enough stories to answer them all?
In the onsite interview the interviewers will divide the principles up and each take two or three, so in one interview you may have more than two questions about a principle. What will you do if that happens?
I suggest that you practice using some questions you’ve developed for other principles to answer Have Backbone questions. A story about a difficult customer can be used for a conflict question, for instance. I think it’s a better idea to have a group of answers you can tailor for the different principles depending on what you get asked.
Sample Answers Related to the “Have Backbone” Leadership Principle
Question: Describe a situation where others you were working with on a project disagreed with your ideas. What did you do?
Answer given by an Engineering Manager
“When I was leading the engineering team at Bank of America in India, I proposed to my U.S. partner that we build architecture capabilities in India. I thought that this would save us money. He was not convinced because he felt that the architecture team needed to collocate with users for a better understanding of user needs, and so needed to be in the U.S.
I still believed that my idea would work, so I proposed that, instead of hiring an architect, we test my idea and assign a senior developer in India to work with the U.S. architecture team. My U.S. partner was amenable to this approach as a “pilot project.”
I onboarded a senior developer, and he started working with the architecture team remotely. He was working on a migration project from Oracle to SAP. This developer, now functioning as a remote member of the architecture team, was able to offer significant contributions to the project from India. He created a proof of concept for moving data across systems, which the team ultimately used as a framework for other work. He also helped the onshore team prepare architecture diagrams.
Once the offshore architect started delivering from India, my U.S. partner’s perspective on the matter began to shift. He asked me to ramp up the architecture team with more remote team members. After building this team, overall delivery improved as offshore had become an extended capability to complement the existing onshore team.”
This story shows that the engineering manager was willing to take different approaches to get her idea across, which is great. However, the story would be stronger if it included more details about how she dealt with the conflict with her U.S. partner. When you are telling a story about how you “Have Backbone,” don’t shy away from talking about the confrontation itself, and how you behaved in that situation. Don’t just rush to the outcome.
Question: Was there a time when you were right but your senior colleagues didn’t agree with you?
Answer given by a UX Designer
“The project was helping the marketing team create campaigns. I had designed a low-fidelity wireframe option and was reviewing it with product management and engineering. Our user was supposed to click on the “Create New Campaign” button, which would then take them to “Create Mode.” After applying a set of filters, the user would then click “Save,” and the campaign page would then go into the “Read Only” mode. At that point, the filters are not accessible to the user. To access the filters again, the user had to click the “Edit Campaign” button. Product management and engineering did not like this flow because they thought that the user should always be in “Edit” mode.
I tried to convince them that my flow was a common design pattern that users would find familiar, demonstrating for example how users added contacts on their phones. They showed me an old desktop enterprise product and said that it was better. Since I was struggling to convince them, I created a flow that was in line with their suggestion and requested that they participate in a usability test of that flow. To me, this usability test was not strictly necessary because I knew from experience that users would find my proposed solution more intuitive and easier to use. I went ahead regardless to convince my colleagues.
I had a group of users try “Option A” (which was my flow) and another group of users try “Option B” (which was their flow). I performed the usability tests with my colleagues so that they could see for themselves how users interacted with each flow. The test results showed what users preferred and how they interact with interfaces of this type. We went with Option A.”
This story is interesting because the UX designer sticks to his principles in the face of adversity. Both product and engineering are aligned against him, and it would have been easier for him to just agree with them. But as a UX designer, he must put users first. That’s his role on the team. So he patiently set up the test to guide his colleagues toward a better way.
