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.

I would diagnose this in four layers: alignment, execution, incentives, and measurement.

First, alignment. I would check whether everyone still agrees on the problem statement and the target outcome. If different leaders define success differently, teams can stay busy without moving the business.

Second, execution. I would review what actually shipped, what was adopted, and where the process slowed down. Busy meetings and shipped deliverables do not prove value if the critical users never changed behavior.

Third, incentives. I would ask whether teams are rewarded for the new outcome or for protecting their own function. If a team is measured on local throughput, it may resist work that helps the overall initiative.

Fourth, measurement. I would compare leading indicators and lagging indicators. For example, if a support automation project shipped six features but ticket volume did not drop, I would look at adoption, usage, and customer behavior before calling it a success.

I would bring leadership a simple readout: what was intended, what changed, where the bottleneck is, and what evidence supports that conclusion. That gives leaders a choice between fixing alignment, adjusting incentives, or changing the plan.

For example, on a two-quarter initiative to reduce customer support ticket volume through a new self-service help center, the four-layer check found: alignment was actually fine, everyone agreed the goal was fewer repeat tickets, not just more help-center pageviews. Execution had shipped six planned articles and a new search widget on time. Incentives were fine too, the support team was measured on ticket deflection and had every reason to want the initiative to work. The real problem was measurement: the team had been reporting help-center pageviews as the success metric, which had gone up 3x, but nobody had checked whether the same customers who viewed an article still opened a ticket afterward. Pulling that number showed 71% of pageviews were followed by a ticket within 24 hours anyway, meaning the articles were being read but weren't actually answering the question. The recommendation to leadership was not to kill the initiative or blame the team, but to replace the pageview metric with a deflection rate (viewed an article and did not open a ticket) and to revise the two articles with the worst deflection rate. Leadership approved continuing the initiative under the corrected metric rather than shutting it down, and deflection rate became the standing measure for the next quarter.

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.

Situation: A senior stakeholder wanted to launch in two weeks, while Operations warned that the support team was not ready.

Task: I needed to reset expectations without slowing the business unnecessarily.

Action: I made the trade-off visible in a simple readiness review. I listed the risks, the likely customer impact, and the mitigation options. I also translated the concern into business language, not just process language. For example, instead of saying Operations was not ready, I showed that we would have limited training coverage and slower incident response if we launched immediately. Then I proposed two paths: launch with a phased rollout and extra monitoring, or delay one week to complete training and testing.

Result: Both sides could support the phased rollout because the risk was named clearly and the plan had guardrails. The stakeholder got speed, Operations got protection, and we agreed on a decision that balanced business urgency with operational readiness.

That experience reinforced that good trade-off decisions are rarely about winning an argument. They are about making the risk and impact clear enough for everyone to support the choice.

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.