Influence and Persuasion Questions

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.

Direct answer

Tailoring a pitch means finding out what that specific stakeholder is actually measured on or afraid of, and reframing the same underlying facts through that lens, rather than repeating your own rationale and hoping it lands. The facts stay fixed; only the framing and the risk language change per audience.

Structured elaboration

Incentive-mapping framework. Before drafting anything, identify what the stakeholder optimizes for and what they fear, then reframe the same evidence in that currency:

A common variant of this: translating a technical or security risk into business-impact terms to win executive buy-in. The reframe isn't inventing a new argument; it's restating the same risk in the currency the executive is accountable for (revenue at risk, compliance exposure, customer churn) instead of engineering terms (a vulnerability class, a latency percentile).

Worked example

Situation. At a platform company, engineering wanted budget approval to fix an authentication vulnerability class a penetration test had flagged. The CFO's first read was that this belonged in the engineering backlog, not an urgent ask.

Stakes. The unpatched vulnerability class carried real breach and compliance exposure, but it was competing for the same budget cycle as revenue-generating projects, and the CFO wasn't going to fund it on engineering language alone.

The influence moves.

• Learned the CFO's actual incentive: quarterly budget defensibility and avoiding one-time crisis spend, not an abstract security posture.
• Reframed the same evidence in the CFO's terms: translated "session tokens that don't expire" into an exposure-window estimate and a cost comparison against the company's own past incident-response spend, the same kind of trade-off the CFO already used elsewhere.
• Built a separate, differently framed one-pager for the security lead from the same underlying evidence: audit and control-mapping language, naming which control had failed and which policy clause it mapped to, instead of repeating the CFO pitch.
• Verified the incentive rather than assuming it, by asking the CFO's chief of staff beforehand what kind of comparison the CFO typically used to evaluate risk spend.

Resolution. The CFO approved the fix as a scheduled, budgeted project rather than an emergency spend, because the exposure was quantified and mapped to a comparison already familiar from other risk trade-offs.

What a senior candidate does differently. A mid-level candidate builds one deck and hopes it lands for everyone. A senior candidate keeps the underlying evidence fixed and swaps only the framing and incentive language per audience, and can explain, in the room, why that phrasing fits that specific person.

Trade-offs and pitfalls

• Tailoring is not spin. The underlying facts must be identical across audiences. If the CFO version and the CISO version (CISO: Chief Information Security Officer, the same person referred to earlier in this example as "the security lead") would lead a skeptical listener to different conclusions about severity, that's manipulation, not tailoring.
• Guessing the wrong incentive misses as badly as not tailoring at all. Verify the incentive with a quick question rather than assuming it from a title.
• Prep cost. Building a separately framed pitch per audience takes real time; reserve heavy tailoring for stakeholders whose buy-in is genuinely load-bearing for 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

To make another function treat your concern as their problem, translate it into the metric they're already accountable for, not the language you'd use to describe it yourself, and back the translation with evidence in the form that audience actually trusts. A CFO wants a dollar figure with a payback period (how long until the savings cover what you spent). Engineering leadership wants a concrete failure mode and blast radius (which systems and users get pulled in if it goes wrong, and how far that damage spreads). A finance function funding early research wants a leading indicator (an early signal that predicts the outcome before the real result is in), not a promise of eventual revenue.

Structured elaboration

Step 1: identify the audience's native metric and the evidence type they trust.

The general principle underneath all three rows: choose a data-driven argument or a narrative argument based on which one the specific audience actually trusts, not based on which one you find more natural to build. Handing a CFO a story instead of a model reads as dodging scrutiny. Handing an engineering lead a spreadsheet instead of a concrete failure scenario reads as someone who's never had to fix the thing at 2am.

Step 2: for a quantifiable concern, lead with the one-line result, then hold the model in reserve as depth. In the room, a single plain sentence usually does most of the persuading: the annual cost, the payback period (how many years until the fix pays for itself), and the return, stated in plain terms, before any spreadsheet comes out. The full multi-formula build below is depth beyond what most interviews expect as a default opening move: it exists for when a CFO wants to see the model and challenge an input, not as the first thing you lead with. Pin every input explicitly so anyone can re-derive the result.

Translating architectural debt into CFO-facing terms, the three levers are revenue risk, operating cost, and opportunity cost:

$$\text{Revenue per hour} = \frac{\text{ARR}}{8760}$$ $$\text{Annual Outage Cost} = \text{incidents/year} \times \text{downtime hours} \times \text{cost per hour}$$ $$\text{Annual Productivity Loss} = \text{devs} \times \text{hours lost/week} \times 52 \times \text{cost per hour}$$ $$\text{Total Annual Risk} = \text{Outage Cost} + \text{Productivity Loss} + \text{Opportunity Cost}$$ $$\text{Expected Annual Benefit} = \text{Total Annual Risk} \times \text{expected reduction \%}$$ $$\text{Payback Period} = \frac{\text{remediation cost}}{\text{Expected Annual Benefit}}$$ $$\text{3-Year ROI} = \frac{3 \times \text{Expected Annual Benefit} - \text{remediation cost}}{\text{remediation cost}}$$

Step 3: for a non-quantifiable concern (engineering, or early-stage research), use the equivalent translation, just not in dollars. A persuasion strategy tailored to engineering doesn't lead with a business case at all: the translation of "this needs to be fixed" is a specific scenario, which service fails, what it takes down with it, and how long the team is heads-down fixing it instead of shipping, told concretely rather than abstractly, because that's the evidence this audience actually weighs. For a finance function funding a research effort, the translation is a leading indicator: an early signal, like adoption of a prototype or a directional experiment read, that predicts the eventual return, since a fully-realized ROI figure doesn't exist yet to hand them. Framing research ROI in finance's leading indicators, rather than in the eventual (and still unproven) revenue number, is what makes an early-stage ask legible to a function that's used to evaluating already-realized returns.

Worked example

Context: an aging service has been accumulating operational risk, and remediation competes for funding against revenue-facing work. The CFO's question is simple: why should this win over a feature.

Pinned inputs: ARR of $200,000,000 (ARR: Annual Recurring Revenue, the company's total yearly subscription revenue); 4 outage-causing incidents per year averaging 2 hours of downtime each; 10 developers losing an average of 6 hours per week to firefighting and legacy maintenance; a fully-burdened developer cost of $80/hour (fully burdened meaning the total cost to the company per hour of that person's time, including salary, benefits, and overhead, not just their take-home pay); an estimated $300,000/year in opportunity cost from delayed feature work; a remediation cost of $600,000; and an expected 70% reduction in these costs once remediated.

$$\begin{aligned} \text{Revenue/hour} &= \$200{,}000{,}000 / 8760 \approx \$22{,}831 \\ \text{Outage Cost} &= 4 \times 2 \times 22{,}831 = \$182{,}648 \\ \text{Productivity Loss} &= 10 \times 6 \times 52 \times 80 = \$249{,}600 \\ \text{Opportunity Cost (assumed)} &= \$300{,}000 \\ \text{Total Annual Risk} &= 182{,}648 + 249{,}600 + 300{,}000 = \$732{,}248 \end{aligned}$$ $$\begin{aligned} \text{Expected Annual Benefit} &= 732{,}248 \times 0.70 \approx \$512{,}574 \\ \text{Payback Period} &= 600{,}000 / 512{,}574 \approx 1.17 \text{ years} \\ \text{3-Year ROI} &= \frac{3 \times 512{,}574 - 600{,}000}{600{,}000} \approx 1.56 \; (156\%) \end{aligned}$$

The line that actually opens the conversation is the simple one promised above: this risk costs about $732K a year; fixing it pays for itself in about 1.17 years and returns roughly 156% over three years. Everything above is the model behind that sentence, ready if the CFO wants to see it and press on an input. Presenting the full model, when asked for it, means showing a conservative, mid, and optimistic scenario (say, 30%, 50%, and 70% expected reduction) rather than a single confident number, and pairing the payback period with the recurring, compounding nature of the cost if nothing changes.

For the engineering leadership version of the same ask, the translation isn't a spreadsheet, it's the specific scenario: naming which service is most likely to fail next, what downstream systems it takes with it, and how many engineer-weeks get consumed responding versus the smaller, scoped fix now. For a finance stakeholder evaluating whether to keep funding the remediation program itself, the leading indicator to report is the trend in incident frequency and hours lost per sprint since work began, not a revenue number that won't exist for years.

Trade-offs & pitfalls

• A single-scenario financial model reads as overconfident; always show a range and be explicit about which inputs are assumptions versus measured figures.
• Handing an engineering audience the CFO version of this argument (a dollar figure with no concrete failure scenario) tends to read as a mandate from above rather than a shared problem, and gets compliance instead of buy-in.
• Handing a CFO the engineering version (a vivid failure story with no numbers) reads as anecdote, not risk, and won't survive a budget review.
• The most senior version of this skill is knowing which type of evidence a given audience trusts before you build anything, not defaulting to whichever type you personally find easier to produce.

Direct answer

When you believe a decision already in motion (shipping a feature, putting a dataset into production) is flawed, raise it by leading with the decision-maker's own goal, pairing every concern with a bounded alternative you can execute yourself, and defining upfront what would resolve the concern, rather than issuing an open-ended objection.

Structured elaboration

Raising a concern without becoming the blocker:

1. Bring evidence of the specific risk, not a general unease.
2. Reframe the objection around the decision-maker's own success metric. A wrong call reversed publicly later costs them more than a short delay now.
3. Always pair the concern with an alternative you can own and execute: a scoped pilot, a guardrail, a validation step. Never just a "no."
4. Define what would resolve the concern upfront, so the conversation has a clear finish line instead of an indefinite hold.

This is a different shape from generally persuading a skeptic to adopt your own recommendation: here you're pushing back on someone else's plan already underway, so the tactic is as much about how the pushback is delivered as what evidence backs it.

Worked example

Situation. While prepping a customer-segmentation model for production, a data engineer found the training data heavily over-represented customers from one region, sourced through a marketing channel not used elsewhere the segmentation would apply. The PM wanted to ship on the existing timeline.

Stakes. Shipping as-is risked systematically mis-targeting customers outside that region; raising the concern the wrong way risked looking like an engineering veto on a decision that wasn't the engineer's to make.

The influence moves.

• Brought concrete evidence, not a general worry: a distribution breakdown showing the regional and channel skew, plus the specific downstream decisions that skew would distort.
• Framed the concern around the PM's own goal: accurate segmentation everywhere the feature would ship, not "the data isn't perfect."
• Paired the concern with an alternative that didn't require the PM to wait indefinitely: ship to the represented region first, plus a small randomized holdout in other regions to measure real-world impact before expanding.
• Defined upfront what would resolve the concern: specific bias-check thresholds and a monitoring dashboard, so the PM knew exactly what "cleared" looked like instead of facing an open-ended objection.
• Volunteered to own the technical work (the validation checks, the dashboard) rather than flagging the risk and leaving it for someone else to fix.

Resolution. The PM agreed to the staged rollout. The holdout group caught real misclassifications outside the represented region before they reached most customers, and the pause read as a scoped validation step, not a blocked launch.

What a senior candidate does differently. Never frames the concern as "don't ship"; frames it as "ship this way instead," with a concrete alternative already designed, which is what keeps the conversation about the plan instead of about the engineer as an obstacle.

Trade-offs and pitfalls

• A concern with no alternative reads as obstruction, even when it's completely valid. Always show up with the next move, not just the objection.
• Defining resolution criteria upfront prevents an indefinite, moving-target hold, which is what erodes trust with PMs over repeated interactions.
• If overruled anyway, document the risk and the decision rather than silently complying or repeatedly re-litigating it after the call is made.