In this article
Before you start
This page is one answer in the behavioral interview guide.
Why interviewers ask this
An engineer who cannot get people to support a decision stays blocked, however good the technical idea is. Expect a form like "Tell me about a time you needed people outside your team to back a technical decision."
Behavioral questions assume that how you handled a past situation is evidence of how you will handle the next one. The question shows up in leadership-principle loops and in senior-engineer loops, where working across teams is part of the job. A weak answer says everyone agreed. A strong answer shows who objected and how the work shipped.
Buy-in from first principles
- Buy-in
- Buy-in is the support of the people a decision affects, who understand it, have had a chance to challenge it and will help carry it out, even though the person proposing it has no authority over them. No formal standard defines it; this page uses that working meaning.
- Design doc
- A design doc is a written document that describes a specific problem, surveys possible solutions and explains the chosen approach and its trade-offs, so reviewers can challenge a decision before it is made. Some companies call it a request for comments (RFC) or a tech spec.
In plain words
Think of planning a group trip where you cannot order anyone to come. You ask what each friend cares about. You share the options and let people object before you book. Then you help the chosen plan work. The analogy breaks in one place: at work a decision has a deadline, an owner and real costs.
In one precise sentence, getting buy-in means three things: the people a decision affects understand it, could challenge it and will support it. You have no authority over them. Built In calls this "influencing without authority" and describes it as getting internal stakeholders aligned without overseeing them.
Step 1: Listen first
The first step is to listen to each person's concern before proposing anything. Practitioners describe the habit: Built In quotes a product manager who listens carefully first to understand how each person sees the situation, then plays back what they heard. Amazon's published principles back it, saying leaders "seek diverse perspectives and work to disconfirm their beliefs".
Input: the people your decision touches. Output: a list of each person's concern in their own words. Ask one person at a time, in a short conversation, so nobody has to object in front of a group. In an illustrative case, moving a nightly job to a queue worries the on-call engineer (debugging) and a downstream team (migration work).
Step 2: Write the problem and options down
Put the problem and the options in writing. The usual written tool is the design doc, and StaffEng says "A good design document describes a specific problem, surveys possible solutions, and explains the selected approach’s details."
Include the options you rejected and why. Next to each option, note which concern from step 1 it answers. Input: the concerns you collected. Output: one document that anyone can read alone, so people who are not in the room can react. Keep it short enough to read in one sitting, with the problem in the first paragraph and the decision you need stated near the top.
Step 3: Invite objections before the decision
Invite objections before the decision is made. One company's decision-record format, described by The Pragmatic Engineer, lists two purposes: a "forcing function to get alignment on a decision that needs to be made", and "to codify a decision that's already been made." Only the first invites objection. A document sent after the decision invites none.
Name a review date and who decides, then ask each stakeholder directly; silence in a review is not agreement. Written review also helps avoid design by committee, as Minetto notes. When you disagree with someone, the Amazon Web Services (AWS) Enterprise Strategy Blog advises you to "Respectfully disagree" and to propose an alternative decision framework that addresses the other party's needs. Output: every objection answered, accepted or recorded.
Step 4: Commit after the decision, even when you lost
Commit and execute once the decision is made. Amazon's published principles say leaders are "obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting." They add: "Once a decision is determined, they commit wholly." They also say leaders "do not compromise for the sake of social cohesion," so harmony is not the goal; a clear decision is.
In a story, committing means actions: you shipped it, you wrote down the risk you had raised, and you agreed a check for it. A story that stops at "they agreed" shows you can win. One that continues after a loss shows you can work with people who disagreed, and that is the rubric line the lead promised.
Step-by-step description
- Hear each concern first.
- Put problem and options in writing.
- Ask for objections before deciding.
- Execute once the decision is made.
- Listen to each person's concern before proposing anything.
- Put the problem and the options in writing.
- Invite objections before the decision is made.
- Commit and execute once the decision is made.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
Tell me about a time you needed people outside your team to back a technical decision.
Our team wanted to move a nightly job to a queue, and two other teams depended on its output. I first asked each team what worried them; one feared harder debugging, the other feared migration work. I wrote a short design doc with the problem, three options including keeping the job as it was, and the trade-offs, then gave everyone a week to object.
One reviewer insisted we run the old job and the queue in parallel for two weeks; I argued it doubled on-call load, and the tech lead, who owned the decision, sided with him. I ran the dual period, wrote my load concern down as a risk with a check on alert counts, and added the debugging dashboard the on-call team had asked for. The queue shipped on schedule, and he reviewed my next change.
The story is illustrative; replace every detail with your own. It reads as Staff-level because it names the options you rejected, who decided, and what you did after losing a point.
How to split the answer across STAR
Spend the most time on Action. Northwestern's guide gives the split Situation 15%, Task 10%, Action 50%, Result 25%, while the University of Wisconsin guide gives 15%, 15%, 50% and 20%. They differ, so treat the percentages as guidance, not a standard. In both published splits, Action is half of the answer, so at an illustrative ninety seconds the Action part is 45 seconds, and at an illustrative sixty seconds it is 30 seconds.1 The University of Wisconsin guide advises focusing on your personal contribution instead of speaking generally about what the whole team did.
| Part | Northwestern split (seconds) | Wisconsin split (seconds) |
|---|---|---|
| Situation | 13.5 | 13.5 |
| Task | 9 | 13.5 |
| Action | 45 | 45 |
| Result | 22.5 | 18 |
Text description of the diagram
- In both published splits, Action is half of the answer.
- At ninety seconds the Action part is 45 seconds.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Ownership | Says "we" throughout, so your part is unclear | Uses "I" for your own actions and "we" for the team result | Names what you decided and what you left to others |
| Listening | Goes straight to the solution | Asked each person what worried them | Restated each concern to the person and changed the proposal because of one |
| Objection | Ignores or avoids it | Answers it with evidence | Records it as a risk with an owner and a check |
| After the decision | Story ends at "they agreed" | Says the project shipped | Shows what you did after losing an argument and committing |
| Result | "It went well" | A concrete outcome in plain words | The outcome plus what you would change in the process |
Three variants of this question
Tell me about a time you disagreed with a decision and committed anyway.
Use the same four steps but spend longer on step 4: state your objection and what you proposed, say who decided, then describe what you did to make the decision work. Amazon's wording of both halves is covered in the Amazon leadership principles guide.
How do you influence people who do not report to you?
Describe the process, not a trait: listen, write the options, invite objections, commit. Then give one example. How you phrase it matters as much as the process, so see describing your interpersonal communication.
Describe a time you changed your mind after someone pushed back.
Changing your mind after pushback is step 1 and step 3 turned around. Say what the person objected to, what evidence moved you, and what changed in the document. It fits Amazon's published line about seeking to "disconfirm their beliefs."
Common mistakes
- "Everyone agreed in the end." (wrong) Buy-in does not mean agreement; Amazon's text assumes people disagree and then commit. (right) "Two people disagreed; I recorded why and we agreed who decides."
- "We aligned on the plan." (wrong) The interviewer cannot see your part. (right) "I wrote the proposal and met each reviewer."
- "I compromised so nobody was upset." (wrong) Amazon's published principle says leaders do not compromise for the sake of social cohesion; compromising on substance can be fine, but not just to keep the peace. (right) "I kept the design that answered the concern and changed the part that did not."
- "I convinced them and the project shipped." (wrong) The story ends on a win and shows nothing about disagreement. (right) "I lost on one point, committed, and delivered."
Follow-up questions
What if nobody replies to your design doc?
Treat silence as unknown, not as yes. Ask each named reviewer one direct question, such as which option they would pick and what worries them, and set a decision date so missing replies do not stall the work.
What do you do when a senior person disagrees with your design?
Respectfully state your case, propose an alternative that addresses their need, and accept that the owner decides. If the decision goes against you, commit and record the risk, as in step 4.
How long should the answer be, and where does the time go?
Plan an illustrative 60 to 90 seconds, with half on Action; see the split in "How to split the answer across STAR". The guide to answering interview questions covers general structure.
Should the example be a win or a loss?
Either works if it shows both halves: you challenged openly and you committed afterwards. A win is fine when you show what you changed because of an objection; a loss is stronger when you show what you did next. See common interview questions for neighboring prompts.
How do you say I without sounding like you did everything?
Use "I" for the actions you took and "we" for the result the team delivered. Wisconsin's guide advises focusing on your personal contribution rather than the whole team's, and the teamwork STAR page shows the balance.
- Buy-in is support from people you do not manage, not universal agreement.
- Listen first, write the problem and options down, then invite objections before the decision.
- Commit and execute after the decision, including when you lost.
- Give Action the most time: half of the answer in both published STAR splits.
- Use "I" for your own actions and say what you did after losing.
Sources
- Amazon Leadership Principles — Amazon, 26 Oct 2026
- Amazon Leadership Principles (UK site: Are Right, A Lot; Earn Trust) — Amazon, 26 Oct 2026
- Guts, Part Three: Having Backbone - Disagreeing and Committing — AWS Enterprise Strategy Blog, 26 Oct 2026
- Behavioral Interviewing & The STAR Approach — Northwestern University Career Advancement, 26 Oct 2026
- STAR Method for Behavioral Interview Questions — University of Wisconsin career guide, 26 Oct 2026
- Writing engineering strategy (design docs / RFCs) — StaffEng (Will Larson), 26 Oct 2026
- Companies Using RFCs or Design Docs and Examples — The Pragmatic Engineer, 26 Oct 2026
- How These Product Managers Strive For Stakeholder Influence — Built In, 26 Oct 2026
- Making technical decisions using RFCs — Elton Minetto, 21 May 2021
