Interview Question and When It Applies
Tell me about a time you had no formal authority but needed peers or cross-functional partners to support work that was not initially their priority. Explain whose decision or action needed to change, why they did not immediately support the request, how you influenced them, and what happened afterward.
This behavioral question applies to product managers, program managers, engineers, data professionals, designers, and people leaders. It is not a test of charisma or generic teamwork. A valid story has a real authority gap: you could not assign the other person's work, evaluate their performance, or unilaterally reorder their priorities, yet you still needed them to make an observable, voluntary commitment.
Its core task differs from “tell me about a technical disagreement.” A disagreement question mainly tests how you compare options, respect decision rights, and execute after a decision. This question asks what each stakeholder was protecting, whether the resistance came from information, incentives, capacity, or trust, and how you changed the request itself to reduce the other party's cost. Proving that your technical proposal was superior does not explain why anyone chose to act.
Use a real experience. You may anonymize the project, customer, and colleagues, but do not present a direct report following an instruction as influence without authority. The sample below is fictional practice material and must not be claimed as personal experience. Every number in it is a placeholder to replace.
What the Interviewer Evaluates
The first signal is whether the authority gap was real. A strong answer accurately names the authority you did have: perhaps you owned a recommendation, a platform capability, or program coordination, but not another team's schedule or final call. If you managed the stakeholder directly, or an executive had already issued a non-negotiable order, authority is a more plausible cause of compliance than influence.
The second signal is whether you understood the resistance. A stakeholder may lack evidence, protect a different goal, have no capacity, fear a risk, or distrust the proposed path. Treating every objection as “they did not see the value” and repeating the same deck only turns up the volume. A stronger answer shows that you listened first and then changed the evidence, scope, or exchange for different stakeholders.
The third signal is whether your approach changed the cost of action. Data can prove a problem; it does not create engineering time, test coverage, or decision accountability. You might reduce the first phase, own migration tooling, invite a low-risk pilot, make hidden risk comparable across options, or turn vague approval into named owners and dates. The interviewer needs to hear what you did that made commitment easier.
The fourth signal is whether the process was honest and respected boundaries. Influence is not manipulation. Disclose cost and uncertainty, offer genuine options, name the final decision owner, and avoid secretly recruiting an executive to pressure the people involved. Escalation becomes appropriate when a material risk has no owner, a formal deadline is about to be missed, or safety, legal, data, or ethical boundaries are being ignored.
Finally, the interviewer looks for outcomes and reflection. The result should include the commitment you earned, what actually happened, and whether the relationship or follow-on mechanism changed. Even an unsuccessful influence attempt can be a mature story if you explain when you stopped campaigning, how you accepted the decision, and which approach you learned did not work.
Clarifying Questions Before You Answer
- Does the interviewer want past behavior or a hypothetical approach? “Tell me about a time” normally requires a real past event. For “How would you influence?”, give the method and then validate it with a real example. Never present a fictional exercise as lived experience.
- What counts as no formal authority? Separate recommendation, resource, decision, and people-management authority. You might control a platform interface but not when product teams migrate, or own a program outcome without being able to assign cross-functional work. The boundary determines the strength of the story.
- Did you need to change an attitude, a decision, or an action? “People liked the idea” is incomplete. Name the observable commitment: adopting a standard, assigning an owner, joining a pilot, or migrating by a date.
- What caused the resistance? An information gap calls for evidence; a capacity gap needs less scope or help; conflicting goals require a shared outcome; low trust favors a small pilot. Without this diagnosis, the influence tactic may solve the wrong problem.
- Who owned the final call, and when was it due? Without an owner or deadline, debate can continue indefinitely. The boundary also prevents you from describing escalation pressure as influence.
- How will you define the result? Separate the immediate decision, delivery, and longer-term outcome. You can own the work of earning commitment without claiming the team's entire business result.
30-Second Answer Framework
“During [project and deadline], I needed [stakeholders] to support [specific action], but I did not own their schedules. Their main concern was [capacity, risk, or goal conflict]. I first used [one-on-ones or existing evidence] to understand each constraint. I then changed the request from [original request] to [smaller scope, a pilot, or work I would own] and made the costs of acting and not acting explicit. I confirmed the boundary with the actual decision owner, then earned commitments for [owners, dates, and deliverables]. The result was [verifiable result]. In retrospect, I had missed [stakeholder or ineffective tactic], so now I do [specific improvement] earlier.”
Expand it with STAR. Use Situation and Task to establish the authority gap and goal. Spend most of the answer on the judgment and tradeoffs in Action. In Result, separate the commitment, business outcome, and your actual contribution, then close with a change you still apply.
Step-by-Step Deep Dive
Step 1: Choose a story that actually demonstrates influence
A useful story meets five conditions: you lacked direct command authority; the other party had not initially committed; both sides protected reasonable goals; you changed the communication, evidence, or delivery plan; and an observable decision or behavior followed. Routine collaboration, an incidental favor, or implementation after an executive had already decided provides little evidence of influence.
Good sources include cross-team priority changes, platform migrations, process adoption, customer risk, or resource exchanges. Match the scope to the role. A junior candidate can influence teammates to adopt a test practice. A senior IC or lead should usually show multiple teams, different incentives, and a longer chain of accountability. The scale may be modest; the authority and causality cannot be invented.
Step 2: Map stakeholders and resistance
Before writing STAR, fill five columns for each important party:
| Party | Outcome they protect | Cost or risk they bear | Evidence that could change their view | Explicit commitment needed | |---|---|---|---|---| | Decision owner | Final business outcome | Opportunity cost and failure accountability | Option tradeoffs and deadline | Approve direction and boundaries | | Executor | Deliverable workload | Development, testing, and maintenance cost | Small validation and tooling support | Owner, scope, and date | | Affected party | User or operational continuity | Friction from the new process | Real cases and recovery path | Acceptance or feedback method |
This table prevents “stakeholder” from becoming one generic persona. Finance may require an auditable definition, engineering may care about migration and on-call risk, and sales may protect a customer commitment. They can share the same overall goal without accepting the same kind of evidence.
Step 3: Match the tactic to the source of resistance
Different resistance calls for different action:
- Information gap: add user evidence, past incidents, an experiment, or a reviewable cost model, and state what the evidence cannot prove.
- Goal conflict: reconnect the request to an outcome both sides own and expose the opportunity cost. Rephrasing your own metric as a nicer slogan does not create alignment.
- Capacity gap: reduce the first phase, own tooling or documentation, or defer noncritical work. Telling a team to care more does not create an extra hour.
- Risk or trust gap: offer a low-risk pilot, a reversible commitment, stop conditions, and independent review so the stakeholder need not accept the entire claim at once.
- Unclear decision rights: identify who decides, who advises, and when discussion must close. If everyone can object and no one can decide, another meeting only spends trust.
Influence tactics have costs. Taking on work can turn you into a permanent bottleneck. A pilot creates evidence but can delay a hard-deadline change. Pre-wiring one-on-ones surfaces objections, but inconsistent messages can resemble private coalition-building. A strong answer explains why the chosen tactic fit and how you limited its downside.
Step 4: Turn support into a commitment
A positive meeting is not yet buy-in. Before it ends, restate four facts: who will do what, by when, which dependency must move, and which new evidence would reopen the decision. Record the decision and unresolved risks so people outside the meeting can understand the boundary.
Unanimous agreement is unnecessary. A decision owner may choose after hearing dissent, and an executor may commit to limited work while retaining concerns. The result of influence is informed, legible action, not a room full of people declaring you correct.
Step 5: Use STAR to preserve causality without taking team credit
Situation names the project, deadline, stakeholders, and authority gap. Task states the specific decision or action you needed. Action follows the causal chain: how you discovered resistance, which feedback changed the original request, what evidence you supplied, which cost you accepted, and how commitment was secured. Use “I” for your work while correctly attributing other people's advice, approval, and execution.
Result can have three layers. First is the decision, such as four teams naming owners and migration dates. Second is delivery, such as completing the migration on time. Third is the outcome, such as lower risk or controlled user impact. Attribute only what the evidence supports. When many factors drive a business metric, say that your contribution was enabling adoption and reducing execution risk, not single-handedly creating the whole result.
Step 6: Know when to stop influencing or escalate formally
After a stakeholder says no, confirm the reason, decision rights, and what new evidence could change the call. If an informed owner has accepted the risk and no safety, legal, data, or ethical line is crossed, record the choice and stop repeating the campaign. Going around the party to progressively more senior people can turn a business disagreement into a trust failure.
When escalation is necessary, bring facts, prior communication, remaining options, impact, and the latest useful decision time. The goal is to get an accountable owner to decide or allocate resources, not to borrow rank to win an argument. If your first tactic was wrong, state its consequence and correction directly.
Step 7: Replace the sample structure with real evidence
Recover facts from project plans, decision records, tickets, status updates, and retrospectives. Build an evidence sheet with my claim | evidence available then | my action | others' actions | verifiable result | remaining uncertainty. Delete precise numbers you cannot source and check whether you have exaggerated your decision authority.
Then ask someone who knew the project only three questions: “Why were you reluctant to support this?”, “Which thing I did actually changed the action?”, and “Whose contribution is missing from this story?” Their answers expose hindsight editing. Finish by delivering the story in two minutes under follow-up questions, without depending on a long background section to explain the authority gap, resistance, action, and outcome.
High-Quality Sample Answer
The following is a fictional example for structure only and must not be presented as personal experience. The project, time, team counts, effort, percentages, and incident counts are all placeholder data to replace.
“I owned a shared login SDK on a platform team. An external identity service would stop supporting its old token-rotation method in eight weeks; eight weeks is a placeholder and must be replaced. I could change the SDK, but I could not schedule work for four product teams. Three teams initially placed migration behind feature launches. Their concerns were different: mobile regression testing, checkout-conversion risk, and missing troubleshooting context for Support. Four teams and three teams are also placeholder counts to replace.
My task was not to get verbal agreement that the risk existed. It was to earn a commitment from each team on migration scope, an owner, and a validation method before the cutoff. I first sent one standard migration plan and received little response. In separate conversations with technical leads and a Support lead, I learned that my plan had pushed compatibility testing and diagnosis cost onto the product teams. I had misclassified the resistance.
I revised the proposal into three choices: migrate in the current cycle, use a compatibility bridge for one cycle, or knowingly accept the cutoff risk with owner sign-off. I exposed the maintenance and recovery cost of each option rather than presenting the bridge as a free delay. To reduce delivery cost, I built a compatibility adapter, automated contract tests, and a migration status page, then invited one low-risk service to pilot. I had estimated ten engineer-days; the pilot took three engineer-days. Both effort figures are placeholders to replace. The pilot also exposed a mobile clock-skew case, so I added that test to the remaining teams' checklists.
I then asked the program's decision owner to confirm the shared cutoff and acceptable bridge boundary. With each team, I recorded an owner, date, and stop conditions. I did not force one cadence: three teams migrated directly, while one team used the bridge because of a release freeze. Those team counts are placeholders to replace. I owned adapter maintenance and a weekly risk summary; product teams retained their release decisions.
All four teams completed the migration within seven weeks. Login failure rate stayed below 0.2% during cutover, with no severity-one incident. The team count, seven weeks, 0.2%, and incident count are all placeholder data to replace. The teams delivered the outcome together. My specific contribution was diagnosing different sources of resistance, lowering migration cost, and converting vague support into explicit commitments.
In retrospect, I involved Support too late. We discovered frontline diagnosis needs only after bridge design began, which caused rework on the status page. On the next cross-team migration, I would include Support and Operations in the initial stakeholder map instead of speaking only to technical leads.”
When replacing this with your own experience, do not reuse the login SDK, migration plan, or numbers. First identify the authority you genuinely lacked, then name the reasonable outcome the other party protected. Preserve the causal chain of “misread resistance, change the request, reduce cost, earn commitment, attribute accurately, reflect concretely.” If your real outcome is qualitative, state who made which decision and how the later process changed instead of inventing an attractive percentage.
Common Mistakes
- Presenting a direct report's assigned work as influence without authority → Management authority explains the action → Choose an example where you could not schedule, evaluate, or command the stakeholder, and state that boundary.
- Saying only “I persuaded everyone with data” → Data does not address capacity, risk, or incentives → Explain how you diagnosed resistance and how evidence changed the request or cost of action.
- Portraying stakeholders as stubborn or uninformed → The story lacks empathy and evidence of durable collaboration → Name the legitimate outcome they protected and how it changed your plan.
- Making executive pressure the first move → Borrowed authority ends debate but may destroy trust → Communicate directly and expose options and costs first; when escalation is necessary, name its trigger and decision purpose.
- Treating a good meeting as the result → There is no owner, date, or later behavior → Turn support into observable commitments and report what actually happened.
- Offering to own everything in exchange for support → Short-term adoption creates a permanent bottleneck and unsustainable accountability → Bound your contribution, exit condition, and long-term owner.
- Claiming every business result as your own → Cross-functional outcomes include other people's decisions and execution → Separate the decision you enabled, team delivery, and final business metric.
- Inventing precise numbers → Credibility collapses under questions about the denominator or source → Recover numbers from real records; otherwise use a specific qualitative result.
- Ending with “communication is important” → The reflection cannot guide future action → Name the tactic that failed, the party you missed, and the action you now take earlier.
Follow-Up Questions and Responses
Follow-up 1: What did you personally do?
Break the contribution into verbs: the resistance you diagnosed, the request you changed, the evidence or tool you created, the options you proposed, and the commitment you earned. Then attribute approval, implementation, and validation to the right people. Clear personal ownership does not require erasing the team.
Follow-up 2: What if the most important stakeholder still said no?
Ask for the reason, decision rights, and new evidence that could change the call. If an informed owner accepts the risk, document it and stop campaigning. If a material risk has no owner or a hard deadline is exposed, escalate with facts, options, and the latest decision point. Persistence is not “apply pressure until agreement.”
Follow-up 3: What did you give up to earn support?
Name the real tradeoff: perhaps you reduced the first phase, accepted a short-lived compatibility layer, or owned migration tooling. Explain how you bounded the cost and why you rejected a faster but more coercive route. A cost-free win-win answer is rarely credible.
Follow-up 4: How do you know influence, rather than an executive order, caused the result?
Point to observable changes before and after any order: who agreed to a pilot, assigned an owner, or changed a plan despite having no reporting relationship with you, and which of your actions first changed their concern. If an executive made the final call, be honest that you may have influenced decision quality rather than every team's voluntary priority.
Follow-up 5: Is it still a good story if the outcome failed?
It can be, but separate the influence process from the business outcome. Explain the informed commitment you earned, the assumption that failed, when you detected it, how you contained impact, and how you would change the influence approach. Do not use “at least everyone agreed” to avoid the consequences.
Follow-up 6: How would the other stakeholder describe this event?
Offer a view that may differ from yours: the cost they initially carried, how your first approach added friction, and which later adjustment actually helped. Acknowledging that they retained some concern is more credible than saying everyone was won over.
Follow-up 7: What would you do earlier next time?
Choose the earliest decision point that could have changed the outcome: include Operations before proposing the plan, identify the decision owner first, or validate workload with a small pilot. State the cost of that improvement and limit it to cross-team or high-risk situations where it is justified.