Influence and Persuasion Questions

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.

Situation: I needed the Support team to invest time in a new escalation process, but I had no formal authority over them.

Task: My job was to earn their support instead of asking for compliance.

Action: I started by learning what mattered to them. I met with the support manager and a few frontline agents to understand their pain points. The main issue was that they were already overloaded, so any new process had to save time, not add work. I then reframed my initiative in their language. Instead of talking about my project milestones, I showed how the change would reduce repeat tickets and make it easier to resolve customer issues on the first contact. I also offered a small pilot so they could test the idea before committing fully.

Result: Because I tied the request to their goals and reduced the burden, they agreed to participate and became active partners in the rollout.

What I learned is that influence comes from understanding the other function’s priorities, showing respect for their constraints, and making the benefit concrete.

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.

Direct answer

Influencing without authority means moving a decision using credibility, evidence, and reciprocity instead of a title. It's the same underlying competency whether the question calls it "influence" or "persuasion": build credibility before you need it, lead with the other person's problem, bring evidence or a low-cost prototype instead of an opinion, and find an ally rather than going in alone.

Structured elaboration

Core tactics:

1. Build credibility before you need it. A track record of reliable delivery makes the ask land differently than the same ask from a stranger.
2. Lead with their problem, not yours. Frame the ask around what the other person is trying to accomplish.
3. Bring evidence or a prototype, not an opinion. A small, low-cost demonstration beats an argument every time.
4. Trade, don't demand. Small, genuine reciprocity works better than a favor you feel owed.
5. Find one ally before the room. A two-person ask lands differently than a solo one.

Where this shows up. The same competency gets asked about in several shapes:

Worked example

Situation. On a platform team, a senior engineer with no authority over product prioritization noticed a shared upload flow causing repeated failures in a "quick-share" feature product wanted to ship as-is to hit a deadline.

Stakes. Shipping as-is risked a visible failure at launch, but the prioritization decision belonged to product, not engineering.

The influence moves.

• Led with credibility already in the bank: a track record of shipping reliable pieces of the same service, so the ask wasn't coming from a stranger.
• Brought evidence, not opinion: existing logs showing the retry-failure rate on the current flow.
• Built a small, low-cost prototype of just the two risky steps instead of asking for a full rewrite.
• Found an ally: a designer who had already flagged the same UX friction independently, turning a solo request into a two-person, cross-functional ask.
• Framed the pitch around product's incentive (a clean launch) rather than engineering's preference for correctness.

Resolution. Product accepted a scoped fix instead of the full reuse plan, without needing an executive to force the decision.

What a senior candidate does differently. Names the specific tactic used (evidence, prototype, ally, incentive-framing) rather than saying "I just talked to them and they agreed," and can say what they'd have done if it hadn't worked, since escalation is a last resort, not a first move.

Trade-offs and pitfalls

• Persistence is not influence. Repeating your opinion louder doesn't count.
• One tactic alone is weaker than combining them. A common weak answer only ever mentions "I built a good relationship" with nothing concrete behind it.
• Escalating too early burns the informal-influence capital that made the peer relationship work in the first place.

Direct answer

When the blocker is skepticism, not a lack of information, the fastest way through it is to give people something to react to instead of something to be convinced of: a working prototype, a runnable demo, or a scoped pilot that lets them see the outcome rather than take your word for it. The artifact does the arguing; you just have to build the right one for the specific doubt in the room.

Structured elaboration

Step 1: diagnose the shape of the skepticism before picking an artifact. "I don't believe it" comes in different flavors, and the wrong artifact wastes the build effort:

Step 2: design the artifact around the objection, not around what's easiest to build. Scope it to the smallest thing that resolves the specific doubt, timebox it, and agree on pass/fail criteria before you start building, ideally with the skeptic's input, so the result isn't yours to spin.

Step 3: know where this can backfire. A demo built to impress rather than to test invites the objection "that's not how it'll behave in production." A notebook you hand over to build trust can just as easily hand ammunition to an opponent if it surfaces an edge case you hadn't accounted for. A pilot with too small a sample or a novelty effect can look causal and not be. Build the artifact to survive scrutiny, not just to look good once.

Worked example

Situation: a data science team built a new lead-scoring model intended to replace the manual process Sales used to decide which inbound leads to call first. Product also had to sign off, since routing the score into the CRM meant committing engineering time away from the roadmap. Neither audience would take "the model scores well offline" as sufficient: Sales trusted their own read on which leads convert, and Product didn't want to fund an integration for a metric that might not move revenue.

The pilot: rather than opening with the model's offline accuracy numbers, the team proposed a one-month randomized pilot. Every new inbound lead was randomly assigned, evenly, to one of two queues: the existing manual triage order (control) or the model-ranked order (treatment). Reps worked whichever queue they were assigned and were not told which queue was which. This is the deliberate causal design piece: random assignment is what lets a difference in outcomes be attributed to the model rather than to which reps happened to get the stronger leads that month.

Pinned inputs: 800 leads entered the pilot, split 400 to each queue by the randomization. The control queue converted 52 leads to a qualified opportunity. The treatment queue converted 71.

$$\text{Control conversion rate} = 52 / 400 = 13.0\%$$ $$\text{Treatment conversion rate} = 71 / 400 = 17.75\%$$ $$\text{Relative lift} = \frac{17.75 - 13.0}{13.0} \approx 36.5\%$$

Presenting to Product and Sales required two different framings of the same result. For Sales, the pitch led with what a rep actually cares about: working the model-ranked queue closed proportionally more leads for the same headcount and the same hours worked that month, which answers "will this replace my judgment with something worse" with results instead of an abstract accuracy score. For Product, the pitch led with the causal design itself: because assignment was random, the lift could be attributed to the model and not to seasonality, a strong sales month, or which reps happened to be on which queue, which is what justified spending engineering time on the full CRM integration rather than commissioning another manual audit of the leads process.

What a senior person does differently: they design the pilot's comparison before building anything (a held-out or randomly assigned control group, not a before/after on the same population), they pick pinned inputs and show the arithmetic rather than asserting a final lift number, and they prepare two distinct framings of the identical result for Product and Sales rather than one deck that tries to land with both.

Resolution: Sales agreed to route new leads through the model by default going forward, and Product approved the CRM integration in the next sprint. The causal design was what made the result durable: had the comparison been a simple before/after on the same population instead of a randomized control, either team could have credibly attributed the lift to a stronger sales month rather than to the model.

Trade-offs & pitfalls

• Building a good artifact costs real time; it only pays off when the resistance is genuinely about evidence, not about competing priorities or politics. A prototype won't fix a stakeholder who has a different agenda.
• A rehearsed demo and a reproducible artifact earn different kinds of trust: a scripted demo is faster to build but easier to distrust; a notebook or environment the audience can rerun themselves is slower to prepare but harder to dismiss.
• An artifact-driven win still needs a path to the actual ask. A convincing demo that nobody follows up on just becomes "a nice thing we built once."
• Watch for optimizing the artifact for the happy path. If the skeptics' real objection is an edge case, a demo that avoids it doesn't persuade, it confirms the suspicion that you're not taking the concern seriously.