TL;DR: Steel-man the skepticism first: deployment skeptics aren't under-informed, they're burned. Convert with behavior, not persuasion (early veto power, an unscoped useful deliverable, radical legibility), and end with concrete champion behavior like defending you in a room you weren't in.
How to approach it
Every enterprise deployment has a skeptic, and FDEs can't route around them, because the skeptic usually controls something you need: data access, the ops team, political air cover. The interviewer is testing whether you treat skepticism as an obstacle or as information. The strong answer's signature move is steel-manning: showing you understood why the skeptic was rationally skeptical before you tried to move them. Pick a story where the conversion produced something concrete, the champion did something champions do (defended you in a room you weren't in, expanded the project, staked their name on it).
A strong answer
"The head of data engineering at a logistics customer was openly hostile to our deployment, in the kickoff he said 'I give this six months,' in front of his team.
Step one was diagnosing the skepticism instead of countering it. I asked for 30 minutes one-on-one and opened with: 'You've seen vendors come through before, what did the last one get wrong?' It turned out a previous vendor had built on his pipelines, shipped a demo to execs, then left his team owning an unmaintainable system. His skepticism wasn't about us; it was a rational prior from being burned. That reframe changed my whole approach, the thing to prove wasn't 'our tech works,' it was 'we won't leave you holding the bag.'
So I converted him with behavior, not persuasion, three moves over six weeks. First, I gave him veto power early, I brought him the architecture before it was final and changed it based on his review, visibly, crediting him in the doc. Second, I made his pain my first deliverable: his team was drowning in a manual reconciliation task adjacent to our project, and I spent two days building a small tool that killed it, unscoped, unbilled, just useful. Third, radical legibility: every line we wrote lived in his repos, in his CI, documented to his standards, so leaving was structurally impossible for us to do badly.
The conversion moment came in week seven: in a steering meeting where an exec pushed to cut the ops-handoff phase, he defended it, 'no, this is the part that makes it stick.' By the end of the engagement he was the internal reference for the expansion deal. The lesson I carry: skeptics convert on evidence about your behavior, not evidence about your product, and a converted skeptic is worth three day-one supporters, because everyone knows what it took."
Skeptics are not persuaded by demos. They are persuaded by their own evidence, and the arc has a shape:
| Stage | What moves them |
|---|---|
| Understand the skepticism | It is usually a previous vendor, not you. Ask what happened |
| Find their number | The thing they personally get measured on |
| Make a small, checkable claim | Small enough that being wrong costs nothing |
| Let them test it | Their data, their queries, their judgment, not your demo |
| Give them the credit | The champion is someone whose idea it became |
The last row is the one candidates skip and the one that actually creates a champion. A person who advocates for your system is a person who has something to gain from it working.
If you are transitioning into FDE work and have never had an external customer, do not invent one. The skeptic pattern exists inside every company, and interviewers accept internal versions readily because the mechanics are identical. The SRE who would not approve your deploy after the last team's service paged her for a month straight. The DBA who denied you warehouse access because a previous analyst ran a full-table scan against the primary at noon. The platform team that ignored your migration request because the last three "quick migrations" each became their incident. What makes these the same story is the structure, not the word "customer": someone who controlled something you needed, whose resistance had a specific history you had to go find, and who you converted by changing their evidence about you rather than by arguing. Tell that story with the same spine (diagnose, deliver something unscoped, make yourself legible) and the same concrete ending, and it scores. What does not transfer is a story where the resistance evaporated because a manager overruled it; that is the going-over-their-head move wearing a happy ending.
What interviewers probe next
- "What if he'd stayed hostile?" Show the fallback: keep delivering, keep him informed anyway, ensure the relationship never blocks the customer's outcome, and escalate to the sponsor only as a last resort, factually.
- "Was the unscoped tool scope creep?" Defend the judgment: two bounded days, high trust ROI, cleared with your lead.
- "How do you find the real skeptic early?" In kickoffs, watch who asks no questions, silence is colder than objections.
Common mistakes
- "I presented better data and they came around", skeptics in real deployments aren't under-informed; they're burned.
- Going over the skeptic's head as your main move. It works once and poisons the well forever; interviewers flinch at it.
- No concrete champion behavior at the end. "We got along after that" isn't a champion; defending your project in your absence is.
- Telling it with contempt for the skeptic. The whole point is that their skepticism was reasonable.