Say it out loud first. Reading the answer teaches you almost nothing.

I ask what decision they'll make with it, and what they do today instead. Nine times out of ten the dashboard is a proxy — they're doing a manual reconciliation every month and they want the answer, not the chart. At [company] I had a request for a spend dashboard that turned out to be one person exporting three systems into Excel every Thursday to answer a single question a VP asked in a Monday meeting. We didn't build a dashboard. We built the answer, on a schedule, into an email. A fifth of the effort, and it got used — which the dashboard wouldn't have been.

Why it works: it answers a method question with a method, then proves it with one concrete case and a comparative outcome. Note that the example ends with something smaller than what was asked for — restraint reads as experience.

I stop asking for their opinion and start watching them work. A twenty-minute screen-share of someone doing the actual task tells me more than an hour of "what would you like it to do", because people describe their process as the policy says it works, not as they actually do it — and the workarounds are the requirements. I come with a straw-man rather than a blank page, because reacting is cheap and inventing is expensive. And I only ever take one thing to them at a time. The teams that get ignored are the ones who show up with a workshop.

Follow-up to expect: "what if they won't even give you twenty minutes?" — the answer is you find the person one level down who actually does the work, and you go via their manager's permission rather than around it.

Six things: the problem in the user's words, the current-state cost with a number on it, what's explicitly out of scope, the data sources with agreed definitions of every field, acceptance criteria that can actually be tested, and the open questions each with a name and a date against them. The out-of-scope section and the open-questions list are the two that save engineering time — everything else is table stakes. And I'd want fifteen minutes with whoever's building it before it gets estimated, because the questions they ask in that meeting are usually the real requirements.

Watch for: this is your own deliverable. Hesitating here is worse than being wrong about anything else on this page. Be able to list all six cold.

When I can state the current-state cost as a number and nobody argues with it, and when the last three conversations have stopped producing surprises. Those two together are a reasonable stopping rule. The failure mode on either side is real — stop too early and you're building on someone's assumption, carry on too long and discovery becomes the deliverable, which is how transformation teams lose credibility. If I'm honest, the second is the more common failure in teams like this, so I'd rather set a date on discovery up front and be explicit about what I couldn't answer in the time.

Why it works: it names both failure modes and then says which one is more likely — a judgment, not a hedge. Volunteering that over-analysis is the bigger risk is quietly reassuring to a build team.

I usually build it their way first, at low fidelity, and let them use it. Arguing in a room is unwinnable — they know their process and I don't, yet. What I'm actually doing is finding the two or three places where the spreadsheet encodes a workaround for something we've since fixed. Then the conversation isn't "your spreadsheet is wrong", it's "these four columns exist because the old system couldn't do X — do you still want them?" They almost always drop them themselves. Ownership of the change has to sit with them or adoption doesn't happen.

Why it works: it's a genuinely counterintuitive move — agreeing in order to disagree later — which is much harder to fake than a principle.

First I check whether it's a real conflict or a definitions problem, because most of the time it's definitions — two people using the same word for different things, which in finance happens constantly with anything like headcount or spend. If it survives that, I don't mediate it. I write both positions down in one paragraph each, name what it costs to do either, and take it to whoever owns the outcome. Mediating between two stakeholders as the requirements person is a trap: you end up owning a decision you have no authority to make, and whichever way it goes you've spent credibility you'll need later.

Why it works: declining to mediate sounds passive but is the senior move, and saying why — credibility is a finite budget — is the part that lands.

I get a rough one fast rather than a precise one slowly. Usually: how many people touch it, how long each says it takes, how often it runs, and how often it goes wrong — four questions, ten people, an afternoon. Then I show the number to the person who'd most like it to be smaller and let them argue it down. The estimate that survives a sceptic is good enough to prioritise with, and precision beyond that is wasted because you're choosing between projects, not building a business case for a board. On [project] that exercise put it at [X hours a month], which was [higher/lower] than anyone expected and changed which thing we did first.

Why it works: "show it to the person who wants it to be smaller" is a concrete technique, not a platitude. Techniques are what distinguish practitioners from describers.

Taking them from one level of the organisation. A manager's mental model of a process is usually a year or two out of date, because the people doing it have quietly changed it around whatever broke. I got this wrong on [project] — I took requirements from the manager, built exactly what was asked for, on time, and usage was about [X]% after six months. The build was fine. The requirements were confidently wrong. Since then I sit with whoever actually does the task at least once. It's an hour and it's the highest-return hour in the whole project.

Why it works: answering a general question with your own failure is the strongest available move. Note it lands on a rule, not on regret.

I start from the assumption that it should be eliminated and make the process earn its existence. Most steps in a finance org exist for one of three reasons, and they want completely different treatment. If it's a control requirement, redesign around the control and automate the evidence rather than the judgment. If it's a workaround for a system limitation that's since been fixed — and a lot of them are — kill the step. If it's one person's preference, that's a conversation with their manager, not a build. The expensive mistake is automating step four of a seven-step process that shouldn't have seven steps. It looks like progress and it locks in the bad design.

Why it works: "make the process earn its existence" is the line to keep. Juniors optimise; veterans delete.

I don't prioritise — I make the trade visible and hand it to whoever owns the portfolio. What I bring to that is a consistent comparison: current-state cost with a number, rough effort, and how reversible it is, which people forget to weigh. A cheap reversible thing beats an expensive irreversible one at equal value, every time. The one thing I'd push for is that the ranking is written down and visible, because the real damage from prioritisation isn't the order, it's that everyone privately believes they're next. Publishing the list costs one uncomfortable conversation and saves ten.

Watch for: the reversibility criterion is the differentiator here — almost nobody mentions it, and it's the one that sounds like scar tissue.

Default to extending what exists, because the true cost of a new thing is not the build, it's that someone owns it for five years. I'd only build when the process is genuinely a differentiator or when nothing on the market fits the data model, and I'd only buy when the problem is common enough that a vendor has seen it a hundred times — which in finance is true more often than teams like to admit. The question I'd ask before any of it is who maintains this in year three, because that usually settles the argument faster than a feature comparison.

Why it works: naming total ownership cost, and specifically "who maintains this in year three", is a question a build lead will be relieved to hear from a requirements person.

When the decision it feeds is made on a schedule. If someone looks at a number monthly and does one of three things depending on what it says, they don't need a dashboard — they need the number pushed to them with the recommendation attached. Dashboards are right when the question is genuinely exploratory and the user changes what they're asking. Most finance requests aren't that; they're a recurring question with a recurring answer, and a dashboard makes the user do the work of remembering to look. That's the difference between something used in month one and something used in month nine.

Why it works: a crisp discriminator (scheduled vs. exploratory) plus the month-nine test, which is how experienced people talk about adoption.

I'd use it where being wrong is cheap and the work is currently human drudgery — drafting variance commentary, extracting fields from invoices and contracts, first-pass classification of exceptions, flagging anomalous submissions against someone's own history. I'd refuse to put a generative model anywhere it produces the number of record. Not because the models aren't good, but because in a close process a confident wrong number is worse than no number — it gets into a deck and someone makes a decision on it. The honest version of most "AI" requests in finance is that deterministic rules would do the job and be auditable, and I'd rather say that than build something impressive.

Why it works: declining to use AI where it isn't warranted, in an AI-titled role, is the single most credible thing you can say. It signals you're solving problems rather than shopping a technology.

By not putting the model there. The architecture does the work, not the prompt: the model extracts or drafts, deterministic logic does the arithmetic and the reconciliation, and anything above a materiality threshold gets a human before it counts. Then before anyone relies on it, I want a labelled set of past cases, a measured accuracy figure, and a stated threshold — "the model seemed good in testing" is not a control. And the audit trail has to show what was proposed, what was posted, and who approved the difference. That last part is usually what determines whether it can be deployed at all, and it's the part people leave until the end.

Watch for: if you find yourself talking about prompt engineering here, you've answered the wrong question. The answer is architectural and control-shaped.

Shadow it first. Run it in parallel against a period that's already closed, where we know the right answer, and measure the gap — not "does it work" but "how wrong is it, and where". Then run it live in parallel with the manual process for a cycle or two, with the humans still doing the work, and compare. The thing I'd watch for is not average accuracy but the tail: an automation that's right on 95% of items and catastrophically wrong on a specific category is much worse than one that's uniformly a bit off, because the first one erodes trust in a way you don't get back.

Why it works: caring about the error distribution rather than the headline accuracy is a genuinely expert distinction, and it's checkable — expect a follow-up asking for an example.

Enough to be useful and not enough to build production systems, and I'd rather you know exactly where the line is. I can read and write SQL, get to the shape of a dataset myself, and prototype something clickable without taking your engineers' time. I can't design a pipeline that survives a backfill, and I won't pretend to estimate one. What I'm actually good at is knowing what a thing will cost you before I promise it to anyone — which is mostly experience of having been wrong about that.

Watch for: overclaiming here is the fastest way to lose a build team, and it always surfaces by month two. Calibrate the middle sentence to what's actually true for you and don't inflate it.

By making it obviously disposable — different tool, no real credentials, sample data, and I say the word "throwaway" every single time I demo it. That's a discipline I learned the hard way. I once demoed something to a [finance director] that was good enough that it quietly became load-bearing for [a quarter], and the team inherited maintenance of something never meant to run twice. The prototype's job is to make the requirements argument concrete and then die. If it survives, I got the scope wrong.

Why it works: "if it survives, I got the scope wrong" reframes a common brag — they loved the prototype! — as a failure. That inversion is very hard to fake.

Building it stopped being the expensive part — I agree with the premise. What didn't get cheaper is knowing which thing is worth building, what the numbers actually mean, and whether anyone will change their behaviour because it exists. In a finance org that's most of the risk. A wrong number that ships fast is worse than no number, because it gets into a deck and someone acts on it. My job is that the thing you generate in an afternoon is the right thing, has definitions everyone signed up to, and has someone still using it in six months.

Watch for: do not get defensive. Conceding the premise immediately and then reframing is what makes the rest land.

I want to know that before it's promised, which means feasibility is a conversation during requirements, not after. When it does happen anyway — and it does — I go back with the cost and two cheaper things that get most of the value, rather than just the bad news. Most finance stakeholders will take seventy per cent of the outcome for twenty per cent of the effort if someone puts it in front of them. What they won't forgive is finding out in month three.

Why it works: "never bring the problem without the two alternatives" is the operating rule underneath it. Say the rule if they push.

An MVP is the smallest thing that tests whether we're right about the value — not version one with fewer features. So I cut breadth before depth: one cost centre rather than all of them, one month rather than a year of history, one user group rather than the whole function. What I don't cut is the thing being tested. If the hypothesis is "people will trust an automated accrual", then the audit trail is in scope even for the MVP, because without it we learn nothing. The most common mistake is trimming the risky part because it's hard, which leaves you with a demo that proves nothing.

Why it works: "cut breadth before depth, never cut the hypothesis" is a genuine principle and instantly usable. Have a real example ready.

I separate the two kinds, because they need opposite responses. If we've learned something — the data isn't what we thought, a user does something we didn't know about — that change is good and I want it in, and the cost of it is a normal cost of doing the work. If someone has simply changed their mind, that's a new request and it goes through the same trade conversation as anything else. Blurring those two is how a build quietly doubles. And I'd tell the build lead which kind it is when I bring it, because the thing that damages that relationship isn't change, it's change arriving without a category.

Why it works: most candidates give one undifferentiated answer about "managing change". Splitting it into learned-versus-changed-mind is the distinction that matters in practice.

By being the person whose work doesn't waste their time. Practically that's three things: a shared backlog they can see rather than a queue in my head, an agreed definition of ready so nothing arrives half-formed, and early feasibility checks so I never promise something upstream that you then have to walk back. Beyond that it's just reliability — if the first three things I bring are well-formed, I get the benefit of the doubt on the fourth. Authority would be nice but it's not what actually moves work in a matrixed org; being the source of good inputs is.

Follow-up to expect: "and if that doesn't work?" — the honest answer is you escalate once, jointly, to whoever owns both sides, and you do it early rather than after a missed date.

Two numbers, and I agree both before we start. One outcome measure in the business's own terms — close days, forecast error, hours in the process — and one usage measure, because a build with a good outcome number and nobody using it usually means the outcome number is measuring something else. Hours saved on its own I'm sceptical of; it's the easiest metric to claim and the hardest to see in a headcount plan, and finance people know that. Cycle time and error rate are harder to game and more likely to survive a conversation with a CFO.

Why it works: being sceptical of "hours saved" — the metric transformation teams reach for by default — is a strong signal, especially to a finance audience who has heard it too often.

Present for a cycle, then deliberately gone. For the first month or two I'd sit with the users through the process — not on a support rota, but close enough to see what they work around, because the workarounds that appear in the first six weeks are the requirements you missed. After that, my job is to hand it to a named owner in the business and stop, because a solution that still needs me is not finished. Where I'd stay involved is the usage number, reviewed monthly, until it's boring.

Why it works: "a solution that still needs me is not finished" is the antidote to the empire-building instinct interviewers are quietly checking for in a role like this.

Adoption is a design constraint, not a phase at the end. Practically: one respected person in the affected team involved from the first prototype — not consulted, involved, with their name on it. The old path turned off on a date everyone knows in advance, because parallel-running forever guarantees the new thing stays optional. And a usage number reviewed monthly, because "rollout complete" and "people are using it" are different facts. On [project] we got to [N]% weekly active within [timeframe]. The one that failed, I skipped the champion step, and it never got past [X]%.

Why it works: three specifics, one success number, one failure number, and the failure is attributed to a named omission rather than to circumstances.

I don't say no, I make the trade visible. "We can do this — it's roughly [X] weeks, which pushes [the other thing] into next quarter. Which do you want?" That converts it from me refusing into them prioritising, which is their job anyway. Where it gets uncomfortable is when the answer is genuinely no because the thing is a bad idea. Then I say it plainly and once, give the reason, and if they still want it I make sure it's written down whose call it was — not to cover myself, so that the retrospective is honest.

Why it works: the last clause is the whole answer. "Not to cover myself, so the retro is honest" separates someone senior from someone defensive.

Mostly by being useful before I need anything. The currency in a matrixed org is that people believe your inputs are good, and that's built in small transactions long before the big ask. Beyond that: I go to people individually before a group meeting, so nobody hears a proposal for the first time in a room where they'd have to react publicly. And I let people improve the idea, which costs me nothing and means it's partly theirs. The version of this that fails is trying to win the meeting — you can be right in a meeting and have nothing happen afterwards.

Watch for: "no surprises in the room" is the specific technique. Without it, this answer is generic.

I take it seriously first, because a VP usually has a reason I can't see — sometimes the build is genuinely about proving the team can deliver, or about a relationship, and that's a legitimate objective even if the artefact isn't. So I'd ask what success looks like to them, and quite often that reframes it. If after that I still think it's low value, I say so once, privately, with the comparison — this versus the thing it displaces. And then I build it well. The failure mode here isn't being overruled, it's doing a visibly half-hearted job of something you argued against, which people remember much longer than the disagreement.

Why it works: assuming a rational reason you can't see is a mature political read, and it's rare in interview answers, which tend to cast stakeholders as obstacles.

Honestly, and early, because they've worked out what's happening long before anyone tells them and the silence is what does the damage. I'd want to know from the sponsor what's actually true — is this headcount reduction or capacity release — and I won't tell someone their job is safe unless I know it is. What I can control is that they're involved rather than done to. In practice the people who know a process best make the best champions for replacing it, if you're straight with them and if the thing they get back is more interesting than what they lose. If it isn't, no amount of change communication fixes that.

Why it works: refusing to promise something you can't guarantee, in an interview, is a strong integrity signal — and the specific line "I won't tell someone their job is safe unless I know it is" is the memorable part.

[Situation — one sentence: who, what they wanted, why it conflicted with what I thought was right.] I'd got it wrong in one respect, which was [X], and I found that out by [how]. What I did was [action — private conversation, written comparison, escalation to the person who owned the outcome]. We landed on [outcome], which was [closer to their position / mine / a third thing]. What I'd do differently is [X] — I left it [two weeks / a month] longer than I should have because I was hoping it would resolve itself, and it doesn't.

Watch for: the answer must contain something you got wrong, and the other person must come out of it as reasonable. A conflict story where you were entirely right and they were difficult is the worst possible answer to this question.

Answer first, one slide, and know which number they'll challenge. Senior finance people read a page in about fifteen seconds and then go straight to the figure they don't believe, so the structure that works is: here's the recommendation, here's what it costs, here's the one risk — and then everything else is appendix for the question they actually ask. What I avoid is the journey. Walking a CFO through how you got there reads as needing credit for the work, and it burns the attention you need for the decision.

Why it works: "know which number they'll challenge" is concrete preparation advice, and the observation about not narrating the journey is the kind of thing only learned by getting it wrong.

The out-of-scope section in the requirements does most of the work, because creep is usually not a request — it's an assumption that was never contradicted. Writing down what we're not doing, early, converts a future argument into a present one, which is much cheaper. Beyond that, every addition gets priced against what it displaces, in the same conversation. What I've learned not to do is absorb small things silently to keep everyone happy. Three of those and the date moves, and then you're explaining a slip you caused by being accommodating.

Why it works: "creep is an assumption that was never contradicted" is a genuinely good reframe and directly justifies the out-of-scope section you claim to write.

I'd want to know first where the accrual value actually comes from, because the answer changes the whole shape. The part sitting in open POs with a goods receipt and no invoice is systematic — that's deterministic automation, no model needed, and it's usually the biggest single chunk. The recurring-vendor part is modellable from run-rate and seasonality, and I can prove it beats the manual estimate by backtesting against last year's true-ups. The genuinely hard part is the manual submissions from cost-centre owners, and there the real problem isn't the arithmetic, it's that several hundred non-finance people are being chased in the first three days of a close and nobody is measured on the quality of what they send.

So the outcome measures I'd propose are close days, the share of accrual value auto-generated, and accrual accuracy against the true-up — which I'd expect nobody measures today. And the control question comes before the build, not after: the model proposes, a human disposes above materiality, and the audit trail shows what was proposed, what was posted, and who approved the difference.

Watch for: lead with rules-not-models. Reaching for AI on the part that's deterministic is exactly the tell they'd be listening for in a role with "AI" in the title.

The first deliverable isn't a chart, it's a definition. Every organisation I've seen attempt this has failed at least once, and it's never the visualisation — it's that Finance, HR and Recruiting each mean something different by "headcount". Filled versus approved versus requisitioned, bodies versus FTE, contractors in or out. Two teams reporting different numbers are usually both right under their own definition.

So: one agreed meaning per field, one named source of truth per attribute, and then three decisions that determine the whole data model — how we treat someone who transfers cost centre mid-month, whether a reorg restates history or preserves what was true at the time, and which hierarchy we report on when the manager and cost-centre structures disagree. Get those written down and the build is genuinely straightforward. Skip them and you'll ship something that two directors contradict in the first week, and you don't get that trust back.

Why it works: the as-is versus as-was question is the insider detail. Very few candidates raise it and it's the decision that most shapes the model.

The difficulty is unglamorous: inputs arrive at different grains — one by vendor, one by cost centre, one by project — on different timings, with the same commitment appearing twice, and with no signal about how firm any of it is. A contracted renewal and someone's rough guess get added together as though they're the same kind of number, which is why the aggregate is never trusted.

So I'd do three things. A common taxonomy and one named owner per input, because unowned inputs go stale silently. A confidence tier on every line — contracted, committed, planned, estimated — which lets you show leadership a range instead of a false point estimate, and that single change usually alters the conversation more than any model does. And then measure forecast error by category and by owner, not just in aggregate, because aggregate-only is exactly why nothing improves: nobody can see whose estimates are wrong. That gives you an outcome metric a CFO will accept.

Why it works: the confidence tier is the idea to lead with — it's cheap, unfamiliar to most people, and immediately obviously right.

Honestly, that's one of the things I want to understand better today, and I'd rather agree it than assume it. My working view is that the strategy side owns the business problem, the process design and the relationship; I own turning that into something buildable — the requirements, the data definitions, the prototype, the interface — so what reaches the build team is estimable and testable. I'm not redoing discovery. The place I'd want to be explicit is who talks to the stakeholder about scope, because that's where roles like this usually go wrong. My preference is that it's them, and I'm in the room.

Critical: this must come out the same way to every interviewer. If two of them compare notes and hear different boundaries, that's the fail. Rehearse until it's under forty-five seconds.

Solution definition — the layer between an agreed process design and an engineer's estimate. Your process map tells me what should happen; it doesn't tell a developer which field is authoritative, what the acceptance criterion is, or what the screen does when the source system is a day behind. That's the gap I'd fill, and I'd rather be judged on an artefact I own end to end than on being a link in a chain. If it turns out that gap doesn't exist here because you already close it, that's genuinely worth knowing today — it would change what I'd be most useful doing.

Why it works: the last sentence is the senior part. Being willing to say "then maybe this isn't the shape of the job" reads as confidence, and it invites them to tell you what they actually need.

Lightly, and with one artefact rather than a process. A single document per initiative that both sides edit — problem, decisions made and by whom, open questions with owners, what's out of scope. Two gates on it: nothing goes to build until the open questions are closed or consciously accepted, and nothing is called done until someone has measured usage. Everything else I'd want to see how you already work before adding to it. Most transformation teams don't need more process, they need the same document to be true for both sides.

Why it works: proposing less process than they expect, and deferring to how they already work, defuses the "here comes a new layer" fear on both sides.

Raise it once, with the specific reason, to you — not in front of the stakeholder. If you've heard it and still want to go that way, we go that way, and I'll build it properly rather than half-heartedly. I've been on both sides of that. The version where the solution person keeps relitigating the design in stakeholder meetings poisons the relationship and doesn't even work. What I'd ask for is that we write down what we expect to be true if the design is right, so that six months later we're looking at evidence rather than re-arguing from memory.

Why it works: "write down what we expect to be true" converts disagreement into a testable prediction. It's disarming and it's a habit of people who've been in long-running programmes.

You do, and I'd want that to be unambiguous. I'd be in the room for solution-level conversations — what it does, what it won't do, what we're assuming — but I'd never renegotiate scope or commit to a date in a meeting you're not in. That's the discipline that keeps a two-team structure working. Where I'd want a bit of freedom is direct access to the people actually doing the work, for observation rather than negotiation, because requirements taken second-hand are the ones that turn out to be wrong.

Why it works: conceding the relationship fully, then asking for one specific, narrow thing, is much stronger than a vague claim to partnership.

[One sentence on where you've been — the arc, not the CV.] [Two sentences on what you've become good at, phrased as a capability rather than a job title: turning undefined problems into things that get built and used.] [One sentence on why you're in this room — what specifically about FIT's remit.] …which is why the remit here interested me. Where would you want someone in this role to start?

Watch for: ninety seconds maximum, and end by handing it back with a question. The handback is what turns a rehearsed intro into a conversation, and it lets you aim everything that follows.

[Project]. We built what was asked for, on time, and usage was about [X]% after six months. The reason was that I'd taken requirements from the manager and not from the five people doing the work, and the manager's model of the process was two years out of date. The build was fine. The requirements were confidently wrong. Since then I don't sign off on requirements I've only heard from one level of an org, and I sit with whoever actually does the task at least once. It's an hour, and it's the highest-return hour in the whole project.

Why it works: the failure is specific, owned, quantified, and produces a rule you still follow. That last part is what makes it a strength rather than a confession.

[Situation and what I believed.] I was confident enough that I'd [committed to it publicly / built on the assumption], which is what made it expensive. What changed my mind was [the specific evidence — a number, a user, a failed test], and I'd say I held on to it about [two weeks] longer than the evidence justified. The cost was [X]. What I do differently now is [the specific habit] — I try to write down in advance what would change my mind, because it's much easier to notice the evidence when you've already named it.

Watch for: use a different story than the adoption one. Two stories with the same shape reads as having only one. And the answer must include a lag — admitting you were slow to update is more credible than a clean reversal.

[Situation — ideally one where the problem statement itself was wrong or missing.] There was no agreed definition of [the thing], so the first fortnight wasn't analysis, it was getting [N] people to agree what we were even measuring. What I did was [the specific move — a straw-man definition circulated for people to attack, rather than a workshop]. That produced [outcome], and the actual build was [smaller/different] than what had originally been asked for. The thing I took from it is that in an ambiguous problem the first deliverable is almost always a definition, not an analysis.

Why it works: it rhymes with the headcount case answer, which is deliberate — a consistent worldview across unrelated questions is what makes seniority legible.

[Situation — who, and what they were committed to.] I didn't argue it in the meeting, because they'd have had to back down publicly. I [built the small thing / pulled the actual numbers / sat with the users] and took it to them privately with [the specific evidence]. What actually moved them wasn't the analysis, it was [the concrete thing — seeing a user struggle, a number they hadn't seen]. They changed position within [timeframe] and, importantly, presented it as their own, which was the point. The lesson I keep is that people change their minds in private and announce it in public, so never make the ask in the room.

Why it works: "people change their minds in private and announce it in public" is memorable, true, and demonstrates political fluency without any cynicism.

[The feedback, stated in their words rather than softened.] It was hard because I thought [what I believed about myself], and it was accurate. The evidence was [specific — a project, a relationship, a pattern someone had noticed]. What I changed was [concrete behaviour, not attitude], and the way I know it worked is [evidence — someone said so later, a measurable difference]. I wouldn't say it's fully solved; under pressure I still [the honest residual].

Watch for: the residual at the end is essential. A perfectly resolved weakness reads as a rehearsed non-answer, and this is the question interviewers most expect to be dodged.

I've done the version of this job with a bigger title and less contact with the actual problem, and I didn't enjoy it much. What's interesting here is that FIT is early enough that the problems are still undefined — accruals, headcount, spend consolidation are all genuinely hard and genuinely unsolved. I'd rather be doing that at manager level than managing a portfolio of solved ones. I'm also clear-eyed that this is a build-adjacent role rather than a strategy chair, and that's what I want right now.

Why it works: naming the limitation of the role yourself removes their need to test it. Vagueness about seniority is what makes an interviewer worry you'll be disappointed.

The thing that would make me leave is not having work that's actually hard, and from what I've seen that isn't the risk here. What I'd want to know from you is what this role looks like in two years if it goes well — not a promotion promise, just whether the scope grows as the team does. That's a more honest answer than a number of years, and it's the thing I'd actually be assessing.

Why it works: it declines to give the fake "five years" answer and turns it into a legitimate question. Answering a retention question with a retention question is only safe if you're calm about it — practise the tone.

No, and I'd be more worried if I were the most experienced person in the room on every axis. You both know this org, these stakeholders and what's already been tried — I don't. My first ninety days are mostly listening and earning enough credibility to be worth disagreeing with. Where I'd expect to add value early is pattern recognition on things that have gone wrong elsewhere, and that's only useful once I've earned the right to say it.

Why it works: "worth disagreeing with" reframes credibility as something earned rather than carried in from a previous job.

[One sentence, forward-looking and true.] The honest version is [what you want more of], and [current situation] doesn't have much of it — not through anyone's fault, it's just [the structural reason]. I'd rather move toward something than away from something, and what's here that isn't there is [the specific thing].

Watch for: never criticise a current employer, and don't over-explain. Two sentences is plenty; length here reads as unresolved feelings about it.

[A real one, with a cost attached.] The one that's cost me most is [X] — on [project] it meant [specific consequence]. What I do about it is [structural mitigation rather than willpower: a person I check with, a habit, a step in the process]. It's managed rather than fixed. The other honest answer is depth: I'm not going to be the person who designs your pipeline, and if the role needs that, I'm the wrong shape for it.

Why it works: a structural mitigation rather than "I'm working on it" is what distinguishes a real answer. Volunteering the technical boundary again is safe here and pre-empts a concern.

First thirty, almost entirely listening — sit through a close, sit with the people submitting accruals, and read whatever's already been tried, because the fastest way to lose credibility in a transformation team is to propose something that failed here two years ago for reasons you didn't ask about. Days thirty to sixty, pick one small thing and finish it, end to end, including adoption — not the most valuable thing, the most finishable thing, because the team needs evidence that work handed to me comes back. Days sixty to ninety, the definitional groundwork on something bigger. I'd be suspicious of any plan that has me presenting a strategy in week three.

Why it works: "most finishable, not most valuable" is the counterintuitive move, and the last line quietly rules out the answer most candidates give.

Two things. If the boundary between the teams never gets agreed, I'd spend my time negotiating rather than delivering, and I'd become a layer rather than a help — that's the one I'd actively manage from week one. The other is if the work turns out to be mostly documenting decisions other people have already made. I'm not much use as a scribe, and I'd rather say that now than discover it in month four. Both are more about how the role is set up than about capability, which is why I keep asking about the boundary.

Why it works: answering honestly about structural risk, rather than performing a fake weakness, is exactly the register you want — and it justifies the boundary questions you've been asking all interview.

Most likely we built for the people who asked rather than the people who'd use it — that's the failure I've actually made, and it's the one that repeats. Second most likely, we never turned the old path off, so the new thing stayed optional and optional things don't get learned. Third, we picked something too big to finish in a year and there's nothing to adopt yet. The reason I'd bet on the first is that it's invisible while it's happening; everyone's happy right up until go-live.

Why it works: ranking the failure modes, and picking the one you've personally caused, is far stronger than listing risks. "Invisible while it's happening" is the line to keep.

Autonomous agents doing the close. The demos are genuinely impressive and the constraint isn't model capability — it's that a control environment requires someone accountable for each posting, and "the agent decided" isn't an answer an auditor accepts. So the realistic near-term shape is a model that proposes and a human that disposes, and the value is in the proposal quality, not the autonomy. What I think is under-hyped is unglamorous extraction and matching — invoices, contracts, exceptions — where the technology has quietly got good enough and the payback is immediate.

Why it works: a specific, defensible contrarian position plus a paired positive. Have one follow-up ready in case they push, because this question is often a genuine opinion probe.

[Project, in one sentence of what it did for whom.] Before it, [the current-state cost, with the number]. After it, [the outcome number], and [the usage number] — I care about the second one more, because the first can be true while nobody's using it. The part I'd point at isn't the build, it's that [the definitional or adoption thing that made it stick]. If I were doing it again I'd [the one change], because [reason].

Watch for: resist describing what it does. Two numbers, one insight, one regret. This is also your best chance to land whichever of your three things hasn't landed yet.

Never "no". Have five ready, ask two or three, and pick the ones that reveal whether the role is real. The full set with reasoning is on the panel page — the two that matter most are "if this role didn't exist, who does the work today, and what do they stop doing when I start?" and "where has the hand-off between the two teams broken down before?"

Watch for: don't ask anything answerable from the job posting, and don't ask about compensation or process here — that's a recruiter conversation.