Tell me about a time you influenced a decision without authority: the senior and staff answer, scored

An influence story gives the interviewer five things to score. Weak answers spend all their time on the argument and skip the rest.

Notice what is not on the list: how good your proposal was. A sound proposal is assumed. Before the Room puts it plainly: being right is the entry fee rather than the win.

Before the Room describes the moves strong engineers reach for when they first meet the authority gap, the distance between what you are accountable for and what you are allowed to command. Three of them show up again as interview answers.

• Be more right. "I gathered more data and they came around." Sometimes true. When the resistance came from an incentive, more evidence can make the proposal look more threatening instead of more persuasive.
• Work harder. "In the end I built it myself over a few late nights." It moved the outcome and taught the organization that the work does not need funding. It is an ownership story, not an influence story.
• Route around. "I escalated to their director." Escalation can be right, but escalating before you understood the other team's cost moves the conflict downstream and makes it personal.

None of the three touches the decision, and the decision is what the question is about.

The story you pick decides most of the score before you speak. Filter your bank with four rules.

• Someone else owned the decision. A design your own team decided is a leadership story, not an influence story. The question wants a decider you could not overrule.
• There was a real no. A polite slip, a "too early to standardize", a review that never quite cleared. If everyone agreed at once, nothing needed moving.
• You carried something in. A memo, a decision record, an options table, a plan. Something that existed after the conversation ended.
• You know what happened a week later. If you cannot say whether the decision held, the story has no ending you can score.

Before the Room runs every situation through three moves, always in this order. Surface: find the decision that is actually being made, who owns it, and the incentive that will decide it. Shift: change that decision with one artifact and the exact words, placed in front of the right owner, before the room. Secure: set the threshold that triggers escalation and the follow-up signal that proves the change held. They also make a clean answer structure.

Keep the first telling to about ninety seconds. The middle three rows carry the score, and a missing one is where the follow-ups will go.

Most stuck work arrives as the top of a stack. "Can you confirm we are on track" sits on a decision about what counts as on track. "Review this design" sits on a decision about who owns the data model afterwards. The book's three cuts take a sentence each: what decision is this scaffolding, who owns that decision, and what incentive will settle it.

In an answer, this is the sentence that separates levels. "They did not want to adopt our library" describes a mood. "Adopting it moved their team from owning the service to being one more customer of ours, and their director would decide based on how that looked at planning" describes a decision, an owner and an incentive. Interviewers write the second one down.

The book's most useful question here is four words: "Whose call is that?" Saying you asked it before arguing tells the interviewer how you work.

The book's premise for this part is the one most candidates skip: when a competent person resists a good technical proposal, they are often being rational from where they sit. A roadmap already promised to their own leadership, an on-call load that is finally survivable, the memory of a migration that slipped last year. Your proposal asks them to pay in that currency while you collect the benefit in yours.

Then the trap on the other side. Not every objection is an incentive in disguise, and an interviewer will test whether you can tell. The book gives three tests that fit in an answer:

• A technical objection is specific and stable. It names a failure mode, and answering it makes it resolve or get sharper. An incentive conflict is vague and mobile: "not ready", "too early".
• A technical objector can name what would change their mind. A test, a benchmark, a rollback drill.
• A technical objection survives a fair trade. Fund their wave, sequence them last, give them a readiness gate. If the no survives and gets more precise, it was real, and the respectful move is to change the plan.

A story where the objection turned out to be correct is still a strong answer. The book has that case: an engineer withdraws his proposal after a replay of production traffic shows the other lead was describing a correctness bug. "I misread the objection, and here is what I did" beats a win you cannot explain.

The weak shift is a better argument at the review. The strong shift is an object placed in front of the owner earlier. The book's line for this: "Influence becomes durable when it leaves the conversation and enters an artifact." A conversation reaches only the people in it and exists a week later in several versions. A one-page memo, a decision record or an options table travels to people who were not there.

In the answer, name the artifact and who saw it first. "The director had the memo on Tuesday, and the skeptical staff engineer the same day, so his concerns could change the proposal before Thursday" tells the interviewer you know where decisions are made.

Expect the follow-up about politics. The book draws the line in one test: if the private conversation would embarrass you to describe in the formal meeting, it is rigging; if describing it would make the meeting more honest, it is pre-alignment. Pre-alignment changes the proposal. Rigging changes the room. If your story includes going to the likeliest dissenter first, say so. Pre-aligning only with allies is the version interviewers distrust.

Most influence stories end in the meeting where the room agreed. That is where the interviewer's next question starts: and then what? A nod in a meeting holds only as long as the pressures that produced it.

The book's Secure move has two parts, and both make good answer sentences. The threshold: the specific condition, stated in advance, under which you would raise the decision to someone with more authority. "I will escalate if this goes badly" is a vague warning. "If the integration test is not passing by Friday, I bring the launch decision to the sponsor" is a threshold. The signal: the evidence you checked, and when. Did the other team's planning change? Did the decision log still say the same thing a week later? Candidates who volunteer the check, unasked, read as people who have watched a decision reverse in a chat thread.

To show the difference, take one of the book's composite scenes and tell it as an interview answer. An engineer proposes consolidating two divergent services into one platform. A director whose team owns one of them calls it "a bit early to standardize on".

The strong column is not a better proposal. In the book, the argument does not improve between the two versions; what changes is where and when the engineer intervened, and what she carried in with her. Read aloud, it is still under two minutes.

The book uses one lens for levels: "A senior engineer solves the problem. A staff engineer changes the decision around the problem. A principal engineer changes the system that keeps producing that decision." Applied to this question:

For a senior role, do not inflate. A decision near your own work, moved cleanly and on the record, beats a vague cross-organization story.

• "Who actually owned that decision?" Tests whether you located it, or argued with whoever was in the room.
• "Why were they saying no?" Tests whether you read the incentive or only the stated objection.
• "What did you write down?" Tests whether the influence outlived the conversation.
• "Did you talk to people before the meeting? How?" Tests the line between preparation and politics.
• "What if they had been right?" Tests whether you can tell a technical objection from an incentive.
• "How did you know it held a week later?" Tests Secure.
• "What did it cost, and who accepted that?" Tests whether you are hiding the trade-off.

Expect one thread pulled several levels deep. A true story survives it, because you remember the exact objection and the date you checked.

Every influence story has a weak spot. What scores is how you handle it when the interviewer finds it.

• When you said "we" too long: "Let me separate my part. The memo and the conversation with their lead were mine; the decision was the director's."
• When you cannot name the owner: "I did not know who owned it at the start, and finding out was most of the work. It turned out to be the director over both teams."
• When your story ends at the meeting: "I should have set a check. What I know is that their next plan included the work; I would now put a date on that check up front."
• When the objection turned out to be right: "I read it as territorial and it was a real failure mode. I withdrew the proposal and made their constraint a requirement for the next version."

An accurate story with a gap beats a smooth one that falls apart at the second follow-up.

Candidates often drop their best material because it did not end in a yes. Before the Room is explicit that the method does not promise agreement. It promises that the no comes from the person who owns the decision, with the cost in view.

So a story can end like this and still score: you took the trade-off to the sponsor, they agreed with the analysis and declined to fund it, and you recorded the decision, the risks they accepted and what would reopen it, then stopped absorbing the gap yourself. A partial yes counts too: the other team goes last, with a funded wave and a readiness gate, and still says they would rather not be doing this now.

What does not score is the story where nobody ever decided, and you kept carrying it quietly. For more on how staff loops weigh this kind of evidence, see the guide to staff engineer interview preparation and the essay on why staff engineers change the decisions a team can make.

How do you answer "tell me about a time you influenced a decision without authority"?

Pick a decision someone else owned that moved because of what you did. Tell it in three moves: how you found the real decision, its owner and the incentive behind the no; the one artifact and the words you used to change it, before the meeting; and the threshold and check that kept it decided a week later. Say "I" for your part and name what the outcome cost.

What if my story ended in a no?

A recorded no can still be a strong answer. If you put the trade-off in front of the person who owned it, with the cost in view, and they declined, say so, say what you stopped absorbing afterwards and what would reopen the question. Interviewers score whether the decision reached its owner, not whether you won.

Is talking to people before the meeting just politics?

Not if every objection you hear in private either changes the proposal or walks into the meeting by name. A useful test: if you would be embarrassed to describe the private conversation in the formal meeting, it was rigging. If describing it would make the meeting more honest, it was preparation.

How is the answer different for senior and staff roles?

Scope. A senior answer moves a decision close to your own work, such as a design your team brings to review. A staff answer moves a decision owned elsewhere, across team boundaries, and leaves an artifact that keeps it closed after you stop watching. Do not inflate a senior story into a staff one; the follow-ups find the gap quickly.