What she owns
Strategy, design, process mapping and stakeholder management, upstream of every build the other team delivers. Her team decides what problem is being solved, for whom, and what the redesigned process looks like. Then it hands over.
Two structural facts follow from that, and they explain most of her behaviour in the room.
First, she is measured on outcomes she does not build. Everything her team produces has to survive a hand-off to engineers she does not manage. Anything that reduces loss at that hand-off is worth real money to her; anything that adds a step to it is a tax.
Second, she has stakeholders. Finance stakeholders, who escalate. Her team's credibility with them is an asset she has spent years accumulating, and a new person demoing something to an exec without warning can spend a chunk of it in one meeting.
What she is screening for
Whether you extend what her team does, or repeat it. Her team already produces process maps and manages the relationship, so the useful version of you starts where her artefacts stop — at the point a developer would still have to guess.
| What she quietly fears | What she wants to hear | |
|---|---|---|
| Scope | You duplicate someone already on her team, and she has to justify the headcount overlap upward. | You start where her artefacts stop, and you can name the gap precisely. |
| Process | You bypass her discovery, decide the design yourself, and treat her process work as a formality. | Her artefacts are your input. You prototype to de-risk her design, not to replace it. |
| Stakeholders | You demo something to an exec, create an expectation, and she cleans it up. | Conflict and scope conversations route through her. You are in the room, not in front of it. |
| Seniority | A manager-level hire who wants to be seen doing strategy and will relitigate her decisions to get there. | You would rather own a deliverable end to end than be a voice in someone else's design. |
The sentence she is listening for
Solution definition — the layer between an agreed process design and an engineer's estimate. If she hears that clearly once, most of the rest of the hour is confirmation. If she never hears it, no amount of good behavioural answers will fix the debrief.
Her likely questions
Ten, grouped by what each is really testing. All ten have model answers on the drill page.
| Question | What it is really asking |
|---|---|
| Our team already does strategy and process mapping — what do you add? | The crux. Can you name the gap without claiming her ground? |
| Who owns the stakeholder relationship day to day? | Will you take her most valuable asset? |
| What if you disagree with our process design? | Will you relitigate in front of the business? |
| Where do you think this role should sit? | Are you presumptuous, and do you have a view worth having? |
| A controller says they want a dashboard. What do you do? | Do you have discovery instincts, or do you take orders? |
| A stakeholder insists you replicate their spreadsheet. | Can you say no without spending her credibility? |
| Automate, redesign or eliminate — how do you decide? | Do you reach for tooling before you reach for the process? |
| How do you drive adoption of something people did not ask for? | Do you treat adoption as a design constraint or as a phase at the end? |
| Walk me through a redesign you did. | Is the UI/UX claim real, and do you have finance instincts? |
| How do you present to a CFO-level audience? | Can she put you in front of her stakeholders without watching? |
The boundary answer
Placement is confirmed unsettled, so this closes with an offer rather than a question. Under forty-five seconds, same wording twice.
“Since it's still open — the version I'd argue for is that your team keeps the business problem, the process design and the stakeholder relationship, and I take the layer underneath: the spec, the data definitions, the prototype, the interface. Not because that's the better job, but because it's the layer your team has to produce on top of everything else, and it's the one where a developer still has to guess. If that gap already gets closed here, that's genuinely worth knowing today — it would change what I'd be most useful doing.”
- Concede first. The relationship is named as hers before she has to ask for it.
- Claim an artefact, not territory. Spec, data definitions, prototype, interface — four things, all objects, none of them a function she staffs.
- Frame as load removed. “On top of everything else” says you are absorbing work, not annexing it.
- Leave the exit open. The last clause lets her say the gap does not exist, which costs you nothing and makes the whole thing a conversation.
Then stop. The temptation is to add a sentence of justification. Do not — the silence is what makes it read as a settled view rather than a pitch.
When she pushes back
Three likely forms, with the reply that keeps the position without escalating.
“We already do that — my team writes the requirements.”
Take it at face value and get specific, because the answer decides whether the seat is real: “Then the useful question is what's in them today. The thing I'd look for is whether a developer can start without a follow-up conversation — field-level definitions, acceptance criteria, what the screen does when the source is stale. If that's already there, the gap I described isn't the one to hire against, and I'd want to know what the real one is.”
“How is that different from a business analyst?”
Do not fight the comparison — it is fair, and defensiveness confirms it: “Structurally it isn't far off, and I'd rather own that than dress it up. The difference I'd claim is the prototype and the interface. A BA hands over a document; I'd hand over something clickable that the stakeholder has already reacted to, which is what stops the requirement changing after the estimate.”
“Who would you report to?”
Do not choose, and do not pretend to be indifferent: “Honestly, either works, and the thing that matters more to me is that the boundary is written down. If I'm on your side, the risk is I drift away from delivery; if I'm on theirs, the risk is I'm redoing discovery you've already done. Both are manageable if we've agreed which artefacts are mine before I start.”
Four traps
Do not say
“I'd own the stakeholder relationship through the design phase.”
Reads as a claim on the asset she most needs to keep — and it is the one line that gets repeated back to her team verbatim.
Say instead
“You own the relationship. My preference is that you're the one talking to them about scope, and I'm in the room.”
Gives away the thing that costs you nothing and buys the thing you need: presence in the conversation.
Do not say
“The role moved away from the technical side, which suits me better.”
Sounds like relief at being further from delivery. It also travels — the build lead will hear it eventually.
Say instead
“The re-scope points at the part I'm strongest at, and it's also the part the hand-off actually needs.”
Forward-looking, and makes the re-scope about the org's problem rather than your preference.
Do not say
“I'd want to review the process design and see if there's a better approach.”
Announces that you intend to reopen her team's work before you have earned the standing to.
Say instead
“Your process map is my input. If I disagree I'd raise it once, to you, with a specific reason — and then build it properly either way.”
Names the boundary of your own dissent, which is what she needs to hear to trust you in front of her stakeholders.
Do not say
“I've run strategy for a function this size before.”
Every minute spent proving you can do strategy is a minute spent proving you duplicate her.
Say instead
Nothing. Let the strategy competence show in how you dissect a problem, not in a claim about your track record.
Demonstrated capability is unthreatening. Claimed capability, in her exact area, is a turf signal.
Questions to ask her
Have five ready, ask two or three. These are chosen to reveal whether the seat is real, not whether the work is interesting. The full set is on its own page, sequenced by when to ask and with a decoding note on what each answer tells you — start there rather than here.
- “Where has the hand-off from your team to the build team broken down before, and what would you want this role to have fixed six months in?” The best question available. It gets her describing the actual job, and her answer tells you what to emphasise for the rest of the hour.
- “What would make you feel like this role was a net add rather than another hand-off?” Invites her to state her fear directly, which lets you answer it directly.
- “If this role didn't exist, who does the work today — and what do they stop doing when I start?” The single best test of whether the seat is real or aspirational. Keep it in reserve; ask it if the conversation has gone well.
- “How much of your team's time goes on the same three stakeholder conversations, repeatedly?” Sizes the load you are offering to take, in her terms.
- “How do you decide what gets built? Is there a formal intake, and who breaks a tie between two VPs?” Tells you whether prioritisation is a process or a personality.
One question worth asking early, not at the end
“Before I answer that — how much of the work today is greenfield versus fixing things that already exist?” It changes the register from interrogation to conversation, and every answer afterwards can be aimed better.
What to listen for
You are assessing her too, and this role shape has known ways of going wrong.
Nobody can name what the role owns. If she describes it as “helping” or “connecting” without naming a deliverable, the seat may not exist yet. Survivable if you shape it yourself, but you should know that is the job you are taking.
She describes the boundary differently from the build lead. Note it, do not point it out. It means the first three months are negotiation.
Adoption never comes up. If a transformation team talks entirely about what it builds and never about what gets used, the measurement culture is not there, and the team will struggle to prove its value regardless of how good the work is.
Every example is a tool, not a process change. If the answer to each problem is a new dashboard, the redesign half of “automate, redesign or eliminate” is not happening — and that is the half your seat is supposedly for.
Reading the placement signal
Placement is open, so her questions are also data. If she spends the hour on process mapping, stakeholder handling and discovery instincts, the role is likely being considered for her org. If she keeps circling the hand-off and who owns which artefact, it genuinely is not settled and your proposal has room to land.
Either way, the answer to “where should this sit?” is the same shape: a view, offered once, framed around the work rather than the reporting line.
The thing to get in writing later
If both interviewers confirm the boundary is unsettled, that belongs in the scope paragraph of the offer, not in a handshake. Not adversarial — the request is simply that what you own is written down. Anyone reasonable agrees, and the ones who resist have told you something useful.