Influence and Persuasion Questions

Direct answer

Persuading a skeptical stakeholder starts with diagnosing what kind of resistance you're actually facing, since the same "here's more data" response only works on an evidence-based objection. A political objection or a loss-of-control objection needs a different tactic entirely.

Structured elaboration

Objection taxonomy. Naming the type of resistance before choosing a tactic is what separates a senior answer from "I showed them more data":

Worked example

Situation. At a product org, a UX team relied on manual review of every design change against brand guidelines. A design systems lead proposed an automated linting check for a subset of mechanical rules. One senior designer resisted far more strongly than the proposal's scope seemed to warrant.

Stakes. The designer's review was a required approval gate; without their buy-in, adoption could be blocked or slow-walked indefinitely, regardless of how good the tool was.

The influence moves.

• Noticed the resistance didn't track with the evidence: false-positive-rate numbers didn't move the reaction at all, which was the signal something else was going on.
• Asked directly what was underneath the resistance, and learned it wasn't about accuracy: automating the check felt like it removed the designer's voice and shrank their judgment role.
• Reframed the proposal to preserve their say explicitly: the linter would catch only mechanical rule violations (spacing, contrast ratios), routing anything subjective to the designer's review, unchanged.
• Gave the designer a visible role in defining which rules counted as mechanical versus subjective, turning them from a blocker into the rule-owner.

Resolution. The designer became the tool's internal champion once their judgment role was made explicit rather than replaced.

What a senior candidate does differently. Doesn't try to win a trust objection with more data. A mid-level answer keeps citing the false-positive rate; a senior candidate diagnoses the objection type first and matches the tactic to it.

Trade-offs and pitfalls

• Misdiagnosis wastes your strongest tool. Aiming data at a political or trust objection wastes the one resource that can't solve that problem, and can read as tone-deaf to the stakeholder.
• Political objections sometimes can't be fully resolved through the stated concern, because the real driver is unstated. A senior candidate says plainly when they suspect this is happening rather than pretending the objection was purely rational.
• Preserving a role is not the same as granting a veto. The trade is scoping what the stakeholder keeps control over, not surrendering the decision.

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

Persuading someone senior to fund or change something means leading with the decision you want, naming the cost of the status quo explicitly, pre-empting the single most likely objection before it's raised, and sizing the ask (a phased or capped version) so agreeing feels lower-risk than it would if you asked for everything up front.

Structured elaboration

Anatomy of an executive ask:

1. Lead with the decision, not the narrative. State the ask early; don't make the sponsor wait for the punchline.
2. Name the cost of inaction explicitly, not just the benefit of acting.
3. Pre-empt the most likely objection (revenue impact, cost, risk) before someone else raises it in the room.
4. Size the ask to reduce perceived risk: a phased rollout, a pilot, or a capped budget is an easier yes than the full commitment.
5. Know your sponsor and your skeptic beforehand, and align the skeptic privately when possible.

Same competency, different scale. This shows up from small asks to board-level ones:

Worked example

Situation. At a mid-size company, an engineering manager proposed a platform consolidation project in a leadership review. A senior VP publicly dismissed it in the room as "solving a problem nobody has," undermining the pitch in front of the same audience needed for approval.

Stakes. Losing credibility with that VP risked not just this proposal but every future ask; meanwhile the underlying problem (duplicated infrastructure, rising support cost) was real and getting worse.

The influence moves.

• Didn't re-litigate in the room; took the public pushback as a signal to gather sharper evidence, not an invitation to argue live.
• Went back to the VP one-on-one, not to reopen the room's discussion but to ask directly what would change their mind, and learned the real objection was a past project's failed ROI, not this one's merits.
• Rebuilt the case to address that exact objection: capped the initial ask to a bounded pilot instead of the full six-month rewrite, with a defined stop-loss checkpoint.
• Brought the VP back in as a named reviewer of the revised plan, rather than resurfacing it as a surprise.

Resolution. The VP co-sponsored the revised, phased version at the next review. The earlier public criticism ended up making the final plan tighter and more credible, not dead.

What a senior candidate does differently. Doesn't treat public pushback as the end of the story or take it personally; treats it as the clearest possible signal of the real objection and goes to address it directly with the person who raised it, rather than only preparing a better slide for the same room.

Trade-offs and pitfalls

• Sequencing matters. Leading with the ask before the sponsor is aligned invites exactly this kind of public pushback; senior candidates often pre-wire the most skeptical stakeholder before the room, not after.
• Sizing matters. Asking for the full multi-month or multi-million commitment up front is a harder yes than a capped pilot with a defined checkpoint; the same case is more persuasive staged.
• "Strategic value" still needs a quantified comparison. Even initiatives without near-term revenue need some measured comparison (opportunity cost, cost of inaction), or the ask reads as a hunch.

I would move quickly because a one-week blockage is usually a clarity problem, not a technology problem.

First, I would bring both teams together and restate the facts: what is blocked, what the milestone depends on, and what happens if nothing changes. Then I would ask each team to explain its assumption about ownership. Often the disagreement is about boundaries, not willingness.

Next, I would decide the immediate owner based on capability and dependency, not pride. If needed, I would split the work into a temporary owner for this milestone and a permanent owner for later. For example, one team might own the interface definition while the other implements the code.

If they still cannot agree, I would escalate with options, not complaints: who can do it fastest, who has the right context, and what the risk is for each choice. That keeps the relationship intact because the discussion stays focused on delivery.

After the milestone, I would document the ownership rule so the same dispute does not happen again. The goal is to unblock the work, make the decision fair, and avoid turning a coordination issue into a personal conflict.

For example, on a project one week from a data-pipeline migration milestone, the platform team and the analytics team each believed the other owned writing the schema-validation logic that would catch bad records before they reached the new pipeline. The platform team's assumption was that analytics, as the consumer of the data, should define what counted as valid. The analytics team's assumption was that platform, as the pipeline owner, should implement any validation logic that ran inside the pipeline. Bringing both teams together surfaced that this was exactly a boundary problem: nobody disagreed on doing the work, they disagreed on who was supposed to start it. The immediate decision, made on capability and dependency rather than either team's preference, was that analytics would own defining the validation rules, the business logic of what counts as a bad record, since only they had that context, while platform would own implementing those rules inside the pipeline code, since only they had write access to it and the deployment pipeline. That split unblocked both teams within a day, and the milestone shipped on schedule with the validation logic live. Afterward, the rule, rule-definition belongs to the data consumer, rule-implementation belongs to the pipeline owner, was documented so the next migration didn't reopen the same argument.

When the thing you want to pause or reverse already has executive sponsorship, the challenge isn't proving the numbers, it's giving the sponsor a way to change course without it reading as a loss. Build a case that quantifies the cost of continuing using real, checkable inputs, acknowledge the reasoning behind the original decision instead of implying it was wrong, and pair the ask with a narrow, timeboxed scope rather than an open-ended freeze.

Building the case

• Quantify honestly. Use a plain formula for the cost of continuing built from real categories (rework hours, incident cost, downstream decision risk), and show the arithmetic instead of asserting a headline number. For example, if a team is logging roughly 8 hours a week of data-reconciliation rework at a fully loaded rate of $75/hour, that alone is $600 a week in pure rework cost (8 x 75 = 600), before counting the cost of any decision made on numbers that turned out to be wrong. That number is built from the team's own logged hours, not invented for the pitch.
• Address sunk cost directly. Acknowledge the investment already made and the reasoning that justified it at the time, rather than implying the original call was a mistake. The sponsor's own credibility is tied to that decision.
• Shrink the ask. Propose a scoped, timeboxed pause with explicit acceptance criteria and a re-review date, not an indefinite freeze, so agreeing doesn't mean ceding control of the roadmap.
• Preserve forward motion. Identify what can keep shipping in parallel, a partial freeze scoped only to the affected surface, so the ask doesn't read as blocking everything.
• Give the sponsor an exit ramp. Let them be the one who announces the course correction, or attaches their name to the improved outcome, rather than a challenger who has to publicly concede a mistake.

Worked example

A data platform has recurring data-quality defects: validation failures reaching production, analyst rework, and occasional wrong numbers on dashboards. At the same time, the org is mid-way through a highly visible new feature initiative with strong executive sponsorship but, by the requester's own analysis, weak near-term ROI relative to the quality debt building up underneath it.

Instead of pushing for an outright freeze on all new feature development, the case is built from the team's own recent numbers: roughly 8 hours a week of reconciliation work logged against a $75 fully loaded hourly rate comes to $600 a week in pure rework cost (8 x 75 = 600), a real, checkable figure rather than a headline estimate. That case goes to the sponsor privately first, framed around protecting the sponsor's own initiative ("the numbers you're presenting to leadership next quarter need to be trustworthy"), with a proposed four-week remediation window scoped only to the highest-defect data sources, explicit exit criteria, and a plan to keep a smaller team on the feature work in parallel so it doesn't fully stall.

The sponsor agrees to the scoped pause because it's framed as protecting their own initiative's credibility, not undermining it, and because the ask has a defined end date rather than being open-ended.

What a senior person does differently here: never frames it as "your initiative is wrong," always as "here's what's putting your initiative's own numbers at risk," and offers a bounded, reversible ask instead of an open-ended one.

Trade-offs and pitfalls

• An open-ended freeze is usually the easiest case to make analytically and the hardest to get approved politically; a scoped, timeboxed ask is often the higher-probability path even though it delivers less.
• Presenting the case publicly before the sponsor has heard it privately turns a data conversation into a status conflict in front of others.
• Quantifying only the cost of continuing, without also naming the cost of the pause itself (lost velocity, delayed commitments), reads as one-sided and gives the sponsor an easy reason to dismiss the whole case.