Influence and Persuasion Questions

A strong answer here names a persuasion attempt that genuinely failed, not a near-miss that secretly worked out, and shows real self-awareness about which specific part of the approach was wrong. The most useful version separates whether the argument itself was flawed from whether the delivery, timing, or audience was wrong, and ends with a concrete change in habit, not a vague lesson like 'communicate better.'

What makes this answer land

• Pick something real. Interviewers can usually tell when a "failure" is a disguised success story, and it undercuts exactly the self-awareness signal this question is testing for.
• Diagnose the layer that actually failed: was the underlying analysis incomplete, or was the argument sound but delivered to the wrong audience, at the wrong time, or without the stakeholder who actually needed to be in the room?
• Separate content failure from relationship failure. Sometimes the analysis holds up fine but the way it was delivered damaged the relationship; sometimes the analysis itself was missing something the audience cared about.
• Show the specific, durable change: a new step you now take before making this kind of case, not a general resolution.

Worked example

A proposal to delay a planned platform investment, based on a sensitivity analysis (testing how much the projected return changes if you vary each key assumption one at a time, to see how dependent the conclusion is on any single guess) showing the near-term return was marginal and dependent on assumptions that hadn't been stress-tested, is presented to the finance and marketing leads. They prefer to proceed as planned, because a related campaign is already scheduled and partially committed.

What failed: the presentation covered the numbers thoroughly but never addressed the operational cost of delay (the campaign disruption, the vendor commitments already in motion) that actually mattered most to the people in the room. It was treated as a numbers argument when, for this audience, it was really a timing and operational-risk argument.

After the decision goes ahead as originally planned, the presenter requests short one-on-ones with both decision-makers, acknowledges directly that the proposal hadn't accounted for the operational costs they cared about, and asks what evidence would have actually been persuasive. Both say, essentially, "show me the two paths side by side, including what breaks if we shift the timeline," not just a return estimate.

The concrete change: the presenter builds a revised model that explicitly includes rollout timing and a phased option, and adopts a standing habit of mapping each audience's specific operational constraints before making a numbers-only case in the future. On a later, related decision, the phased framing is adopted from the start.

Trade-offs and pitfalls

• Choosing a "failure" that's really a near-win undercuts the whole point of the question; interviewers are listening for a real cost, not a happy ending in disguise.
• Blaming the audience's receptiveness instead of naming what was actually missing from the case reads as a lack of self-awareness, which is the opposite of what this question is testing for.
• Being genuinely honest about what went wrong carries some risk in the room, but a story with no real cost to the narrator tends to read as evasive rather than reassuring.

Direct answer

Getting several teams that don't report to you to align on a shared priority runs on the same core mechanics regardless of the specific situation: make the shared business impact undeniable, propose measurable objectives everyone can rally around, prove the approach with small low-risk pilots, and build a visible governance rhythm that keeps the alignment from decaying once the room ends. What changes is how you adapt those mechanics to the specific shape of the no-authority problem in front of you.

Structured elaboration

The core approach.

1. Anchor on shared impact first: quantify the customer or business consequence of the status quo (an incident rate, a churn signal, a delivery slip) so the priority feels self-evidently real, not like your personal agenda.
2. Propose measurable, shared objectives: define the metric everyone will be judged against together, not a task list you hand out.
3. Run small pilots with a single owner and a defined hypothesis, rather than asking for a big commitment up front.
4. Build a lightweight, visible governance rhythm (a shared dashboard, a short recurring sync) so alignment doesn't quietly erode after the initial win.
5. Have an escalation path ready, used as a last resort with a concise, decision-ready brief, not a first move.

This ask shows up in different shapes, and each one bends the base approach differently. Treat the table below as a reference, not a checklist to work through top to bottom: shapes involving a single ask, habit, or team (changing a habit, a silent blocker, competing urgent requests, or lacking authority to block a quick fix) are what most candidates will actually hit. Shapes tied to a formal title or a multi-month program (influencing a governance board from outside it, a cross-region rollout, or a sustained transformation) are senior-level or less common: worth recognizing, not the default case to prepare first. One term in the table is worth flagging before you hit it: a sponsor is someone with more standing than you who is willing to vouch for your proposal and carry it into rooms you cannot get into yourself.

Worked example

Situation: three engineering teams, none reporting to the same manager, each owned a service that jointly determined customer-facing reliability. Each had a full roadmap of its own, and there was no formal mandate to reprioritize any of them.

Actions: the case opened with incident data showing the customer-facing impact when the three services interacted badly, not with a request to any one team. From there, two shared leading indicators (an availability target and an error budget, the amount of downtime or failure the team is allowed before it counts as a miss against that target) gave the teams something to rally around jointly rather than three separate asks. Each team then ran a short, narrowly scoped two-week pilot inside its own service, with a single owner and a specific, falsifiable hypothesis, rather than committing to a larger reliability program up front. A shared weekly sync and a public dashboard kept the three efforts visible to each other, so no team's contribution disappeared quietly.

Resolution: once each pilot produced a real, specific result the owning team could point to, the three teams adopted a shared reliability roadmap and governance cadence going forward. What made it hold, compared to a one-time ask, was that shared visibility and a recurring cadence kept the alignment from being a single meeting's decision that decayed afterward.

Trade-offs & pitfalls

• Applying the one-off-ask playbook to a behavior-change problem (like stopping a risky habit) is a common miscalibration: the agreement holds in the room and evaporates the next time there's pressure to cut a corner.
• Spending effort rebutting objections that were never actually voiced, while missing a silent blocker who's quietly not delivering, wastes the entire influence effort on the wrong target.
• A single communication style across regions or functions will land as tone-deaf somewhere; the adjustment is in delivery and channel, not in the underlying facts.
• Sustained, multi-month efforts (a governance body's charter, a multi-team transformation) fail more often from buy-in decaying after the kickoff than from failing to get buy-in in the first place; the governance cadence is not optional overhead, it's the mechanism that keeps the win from reversing.

I would first separate disagreement on the outcome from disagreement on the method. Then I would bring the executives into a short decision session with a one-page brief: the business goal, the options, the trade-offs, and the decision needed. I would make decision rights explicit using RACI, which means Responsible, Accountable, Consulted, and Informed. That way, everyone knows who recommends, who decides, and who simply needs to stay informed.

For example, if one sponsor wants speed, another wants cost savings, and a third wants risk reduction, I would ask which metric is the tie-breaker if they conflict. I would propose a shared scorecard with 2 or 3 measures, such as revenue impact, operational risk, and delivery date, then ask the accountable executive to make the final call in writing.

While the debate is happening, I would keep teams executing on work that is not dependent on the unresolved choice, pause only the parts that could be wasted, and communicate a clear interim plan. The goal is to prevent thrash, protect momentum, and get everyone back to one set of success criteria.

For example, on a customer-onboarding automation initiative, three executives disagreed about halfway through: the VP of Engineering wanted to prioritize system reliability given a recent outage, the VP of Finance wanted to prioritize cost savings from reduced manual onboarding labor, and the VP of Risk wanted to prioritize compliance controls given a pending audit. In the decision session, the RACI mapping made the VP of Product the accountable decision-maker, with all three VPs as consulted. The proposed scorecard used three metrics: onboarding error rate (tied to reliability), manual labor hours saved per month (tied to cost), and number of unresolved audit findings (tied to risk). The accountable VP decided that the audit-findings metric was the tie-breaker for this quarter, since the audit deadline was fixed and immovable, while the reliability and cost metrics would be weighted equally starting the following quarter. While that decision was being finalized in writing, the teams kept building the shared onboarding data pipeline, which every option needed regardless of the outcome, and paused only the specific reporting dashboard whose design depended on which metric ultimately won.

Treat credibility like a limited, rechargeable budget. Rank the initiatives competing for the same stakeholders by expected impact and by how big an ask each one actually requires, spend the smallest ask that moves you closer to the goal first, and save the most expensive kind of ask for the initiative where it buys the most lasting change.

The budget

• Inventory. List every initiative that needs support from the same stakeholders, and rate each on impact (what actually breaks or improves if it happens or doesn't) and on cost (a small favor versus a full re-prioritization).
• Cheap versus expensive asks.

• Sequence across initiatives. Where two initiatives compete for the same stakeholder's goodwill, lead with whichever can be proven cheaply first, bank the resulting trust, and use it to justify the costlier ask on the second initiative rather than spending big on both at once.
• Replenish deliberately. Credibility isn't only spent, it's earned back: deliver on what you said you would, credit others publicly, and be visibly right on the smaller asks. Without replenishment, the sequencing above collapses, because there's nothing left to spend when the second initiative needs it.
• Reserve escalation. Save the most expensive form of capital, going over someone's head or forcing a public reversal, for cases where the cost of not acting clearly exceeds the relationship cost, and even then, spend it having already banked smaller wins with that same stakeholder.

Worked example

A team lead has two initiatives in flight that both need buy-in from the same product stakeholder: a smaller data-quality fix that would quietly improve a metric the stakeholder already cares about, and a larger platform refactor that would require the stakeholder to accept a slower roadmap for a quarter.

Asking for both at once risks getting a lukewarm yes on neither, or a reluctant yes on the small ask while the larger one is flatly refused because there's no banked trust to draw on yet.

The lead sequences deliberately: pitches the data-quality fix first, as a narrowly scoped, low-risk pilot, delivers it, and makes sure the stakeholder gets visible credit for the resulting improvement in their own reporting. Only after that win is delivered and credited does the lead bring the larger refactor ask, explicitly framed against the credibility just built: "the same kind of investment made the number you're now presenting to your leadership possible. This is the same category of work, at a larger scale."

The stakeholder grants the larger ask more readily, because the smaller one was delivered and credited correctly first, rather than both asks being treated as independent, equally costly requests made at the same time.

What a senior person does differently here: never spends the expensive ask first, and always makes sure a stakeholder sees an earlier, smaller win pay off for them personally before asking for something bigger.

Trade-offs and pitfalls

• Spending all your capital early to move fast on every initiative at once usually produces a string of shallow "sure, fine" agreements that dissolve the moment the stakeholder has to defend the decision to someone else.
• Treating every ask as if it costs the same leads to either overspending on trivial requests or badly underestimating the cost of a genuinely expensive one.
• Sequencing only works if you're honest about which initiative actually has the most impact; using credibility to win on the initiative you personally prefer, rather than the one that matters most, burns trust once the mismatch becomes visible.

Situation: I led a launch that needed Product, Engineering, and Support to deliver the same outcome, which was reducing customer setup time.

Task: Each team had different priorities, so I needed one shared goal and a way to surface trade-offs early.

Action: I started with a single business metric, then broke it into team-level commitments. Product owned the user flow, Engineering owned reliability, and Support owned readiness. I held a weekly cross-functional checkpoint where each team shared risks, not just status. When conflicts came up, I made the trade-off explicit. For example, we chose to delay one nonessential feature so we could simplify onboarding and reduce support tickets.

Result: The teams stayed aligned, the launch shipped with fewer surprises, and the process made future collaboration easier because everyone knew how decisions would be made.

The key lesson was that shared outcomes work best when the goal is visible, disagreements are discussed early, and trade-offs are decided openly instead of being left to drift.