One interviewer, one decision: will you save this team capacity or consume it?

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.

The whole answer is the tone. Said flatly, it reads as self-knowledge. Said apologetically, it reads as a gap. Calibrate the middle sentence to what's actually true for you and then deliver it like you're stating your height.

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 your team 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.

This is your own deliverable. Hesitating here is worse than being wrong about anything else tomorrow. Be able to list all six cold, in order, without counting on your fingers.

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 this one is on the must list: inheriting someone else's prototype is a specific, memorable pain that build teams carry for years. Naming it as your mistake rather than a principle is what makes it land.

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?" — escalate once, jointly, to whoever owns both sides, and early rather than after a missed date. Say "jointly"; going alone is what she's checking for.

[Project, one sentence — what it did for whom.] Before it, [current-state cost with the number]. After it, [outcome number], and [usage number] — I care about the second more, because the first can be true while nobody's using it. The part I'd point at isn't the build, it's [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, ninety seconds. This is your best chance to land all three of your messages at once — plan which.

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.

The rule underneath: never bring the problem without two alternatives. Say the rule if she pushes.

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, I want it in, and the cost is a normal cost of 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 you which kind it is when I bring it, because what damages this relationship isn't change, it's change arriving without a category.

Why it works on her specifically: it hands her a vocabulary for something she deals with constantly and probably hasn't named.

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.

The strongest thing you can say tomorrow. Declining to use AI where it isn't warranted, in an AI-titled role, tells a build lead you'll bring her problems rather than technology shopping lists.

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 usually determines whether it can be deployed at all, and it's what people leave until the end.

Watch for: if you start talking about prompt engineering, you've answered the wrong question. The answer is architectural.

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", the audit trail is in scope even for the MVP, because without it we learn nothing. The common mistake is trimming the risky part because it's hard, which leaves you with a demo that proves nothing.

Have a real example ready — she may well ask "give me one". Cut breadth, never the hypothesis.

Two numbers, agreed 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.

Being sceptical of "hours saved" — the metric transformation teams reach for by default — is a strong signal to someone who has had to defend a business case.

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.

Do not get defensive. Conceding the premise in the first clause is what makes the rest land. If you argue that building is still hard, you've lost the exchange.

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 your 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.

Say it the same way to everyone. If she and the strategy lead compare notes and hear different boundaries, that's the fail. Under forty-five seconds.

[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.

"The build was fine, the requirements were wrong" is the sentence a build lead most wants to hear someone say about themselves. Don't soften it.

First thirty, almost entirely listening — sit through a close, sit with the people submitting accruals, read what's already been tried, because the fastest way to lose credibility here is to propose something that failed two years ago for reasons I didn't ask about. 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 your team needs evidence that work handed to me comes back. 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.

"Your team needs evidence that work handed to me comes back" — say it in those words. It's the entire interview in one sentence.

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.

The last sentence is aimed at her. "Build-adjacent, and that's what I want" tells a delivery lead you're not going to spend a year trying to escape upward.

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.

Lead with rules, not models. Reaching for AI on the part that's deterministic is exactly the tell a build lead listens for. If she pushes on the modelling, the backtest-against-last-year's-true-ups line is your proof you'd measure rather than assert. Background on the domain page.