Influence and Persuasion Questions

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

Convincing a skeptical engineering team works the same way convincing any technical peer does: a working prototype and real measurements under realistic conditions, framed around the team's own operational incentives (on-call burden, SLA risk, meaning the risk of missing the SLA, short for service-level agreement, a committed target for uptime or response time that the team is held to, and cost they're accountable for), and a rollout plan that limits their exposure if the bet turns out wrong.

Structured elaboration

Framework:

1. Find the team's actual objection. It's usually operational risk or migration cost, not disagreement with the idea itself.
2. Build the smallest prototype that produces real evidence under realistic traffic, not a synthetic benchmark.
3. Translate the result into the team's own incentives: fewer pages, lower SLA risk, cost they own, not just "it's faster."
4. Propose a reversible rollout: a feature flag, a canary (a canary release: rolling the change out to a small slice of real traffic first, so any problems show up on a limited group before the change reaches everyone), a defined rollback trigger, so agreeing doesn't feel like a one-way door.

Worked example

Situation. At a company serving a vision model through CPU-based microservices, the on-call rotation was regularly paged during traffic peaks. The infra team was skeptical of a GPU-backed migration, worried about operational complexity and vendor lock-in, having been burned before by a migration that added more toil than it removed.

Stakes. Staying on CPU meant recurring SLA breaches and on-call fatigue, but the infra team's skepticism, left unaddressed, meant the migration simply wouldn't happen regardless of the theoretical performance case.

The influence moves.

• Talked to the on-call engineers directly, not just their manager, and learned the real objection wasn't the GPU idea itself but the memory of a prior migration that shipped without runbooks (a runbook is a written, step-by-step guide for operating or recovering a system, so whoever is on call at 2am has an actual procedure to follow instead of improvising) or a rollback path.
• Built a small prototype on a single GPU node and ran it against a slice of real production traffic over a short pilot window, rather than a synthetic load test, so the team could see behavior under conditions they recognized.
• Framed the result in terms the team owned: fewer pages during peak traffic and a lower likelihood of breaching the SLA they were accountable for, not just raw speed.
• Addressed the vendor lock-in and complexity objection directly: proposed a portable, standard runtime rather than a vendor-specific one, and delivered a runbook and autoscaling policy alongside the code, treating operational readiness as part of the deliverable.
• Proposed a gradual, flagged rollout with a defined rollback trigger tied to error-rate and latency regressions (an automatic rule that watches two production health signals, the percentage of requests failing and how slow responses get, and rolls the change back on its own if either one crosses a set threshold), so the team wasn't betting the whole service on day one.

Resolution. The infra team co-owned the rollout plan and adopted the runbook as their own; the prior migration's bad memory stopped being the default reason to say no.

What a senior candidate does differently. Doesn't lead with performance numbers; leads with the team's actual objection (the operational scar tissue from before), and treats the runbook and rollback plan as part of the pitch itself, not paperwork produced after the team says yes.

Trade-offs and pitfalls

• A synthetic benchmark convinces almost nobody who owns the pager. Realistic, even narrow, production traffic carries far more weight than a bigger but synthetic number.
• Skipping operational-readiness work to "prove the architecture works first" is a common mistake; for the team that has to operate it, the runbook and rollback plan are the pitch.
• A migration that can't be rolled back cheaply reads as a one-way door regardless of technical merit, and skeptical teams correctly resist one-way doors more than they resist new technology.

I would treat this as a change-management problem, not just a rollout problem.

First, I would diagnose where adoption is breaking down. I would review usage data, interview a few people from each function, and compare the new process to the old one. I want to know whether people are resisting because the process is too slow, unclear, misaligned with incentives, or simply not useful in their day-to-day work.

Then I would test the rollout design. I would ask: did we train people, give them a reason to care, and remove the old path? For example, if support keeps using the old escalation template, maybe the new process adds friction and does not solve their problem fast enough.

If the issue is execution, I would tighten enablement, add team champions, and publish a clear operating cadence. If the issue is the process itself, I would change it based on the feedback rather than forcing adoption of a bad design.

I would judge success by outcomes, not attendance at meetings. If adoption improves, cycle time drops, and fewer teams revert to the old habit, the rollout is working. If not, I would change the process before asking for more compliance.

For example, when a company rolled out a new cross-functional incident-escalation process across product, engineering, and support, usage data after three weeks showed only 40% of support tickets were being routed through the new template, the rest were still going through the old one. Interviews with five support agents revealed the real problem: the new template required them to fill in a business-impact field that only engineering had the context to answer, so agents defaulted back to the old, faster template rather than get stuck. That pointed to a process-design gap, not a training gap. The fix was to move the business-impact classification to a follow-up step engineering completed after triage, instead of asking support to guess it up front. Within two weeks of that change, template usage rose to 92%, and average escalation cycle time (the time from a ticket being flagged to a fix being assigned) dropped from about 3.5 days to just under 2 days.

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

Credibility with people who have no track record with you is earned in the first few interactions, not argued for. The fastest reliable path is to listen before recommending anything, make your reasoning visible rather than just your conclusions, and deliver one small, real result quickly, before you ever ask them to trust a bigger claim.

Structured elaboration

A framework for the first interactions with a new stakeholder or team.

1. Intake before opinion: understand what decisions they're actually trying to make and what's gone wrong for them before, before offering any recommendation.
2. Show your work: when you do produce something, make the validation visible (trace a number back to its source live, walk through how a result was derived) instead of asking them to trust a polished output.
3. Deliver a small, real win fast: a scoped result within the first couple of weeks does more for trust than a comprehensive plan that ships in month two.
4. Telegraph how you handle being wrong: tell them up front how you'll flag it if something in your work turns out to be off. People trust someone who has already shown you a plan for your own mistakes.

The first 30 days. New cross-functional partners are evaluating you the whole time, not just at the big review. Being proactive about the relationship in the first 30 days, rather than waiting for a natural moment, is itself a credibility move. A first 1:1 with a new partner can open with something like: "What decisions are you trying to make in the next month that you don't feel confident about today?" followed by "What's gone wrong before when someone tried to help with this?" Both questions do real work: the first surfaces what would actually count as a win to them, the second surfaces the specific way trust was broken before, so you don't repeat it by accident.

Three behaviors that quietly erode credibility across teams, and the remediation for each:

Credibility repair is a different problem from rapid trust-building, and worth naming separately. Rebuilding credibility across engineering, product, and customers after an architecture decision failed in production is credibility repair, not the repair of a single personal relationship: it spans multiple functions at once, each of which needs something different. Engineering needs an honest technical postmortem without blame-shifting. Product needs clear, early communication about impact and timeline. Customers need a concrete remediation plan and a channel that doesn't go quiet. Treating this as "smoothing over one relationship" misses that trust has to be rebuilt with several audiences in parallel, each judging you by different evidence.

Worked example

Situation: in the first month partnering with a new team (the fraud-risk team, which had just started requesting weekly modeling support from the analytics group for the first time), the working relationship started skeptical, because past deliverables from this kind of collaboration had shipped late and with numbers nobody trusted.

Actions: an early 30-minute intake conversation confirmed exactly which decisions the partner team needed to make (specifically, which transaction-flagging threshold to set for the coming week) and which metrics actually mattered to them (the false-positive rate on flagged transactions, not just the raw flag count), rather than assuming. A one-page plan with milestones and explicit validation steps went out so expectations were unambiguous. A working version, a weekly false-positive-rate dashboard for the fraud-risk team's review queue, shipped inside the first two weeks, and in the walkthrough, a couple of numbers the partner flagged as surprising (the false-positive rate for one transaction category showing 22% instead of the roughly 8% they expected) were traced live, back to the source data, in the room, instead of being defended from memory. The trace showed the 22% figure was correct: a recent change to that category's flagging rule had not been backed out of the historical comparison period, inflating the apparent rate.

Resolution: the partner team began using the dashboard for real weekly threshold decisions within the two-week window. What changed their minds wasn't the polish of the output, it was watching the 22% number get traced back to its source live and seeing that the plan they'd agreed to up front was the plan that got delivered.

Trade-offs & pitfalls

• Rapid trust-building tactics (intake, quick win, visible validation) and credibility-repair tactics (postmortem, cross-function communication, remediation plan) are not interchangeable; using a "quick win" playbook after a public failure reads as minimizing what happened.
• An intake-only approach that never produces anything can itself read as stalling; the first small delivery needs to land within roughly the same window as the intake conversation, not months later.
• Under-promising protects credibility but can look like low ambition if you don't also communicate what you're deliberately holding back on for now.