All jobs / Engineering manager / tech lead
Stakeholder Management interview questions
Stakeholder Management questions a Engineering manager / tech lead can be asked, from first job to senior. Open one to see the strongest answer and why it works.
How should your engineers work with the QA people on the team?
The strongest answer: Together from the start: QA in refinement asking what could go wrong, developers writing tests as well, and testing happening during the work rather than as a hand-over at the end
Why it works: Exactly — testing is part of building, and QA’s most valuable contribution comes before the code exists.
- Test during, not after.
- QA in refinement.
- Developers write tests too.
- Quality is not one stage.
A VP asks when the project will ship. What do you give them?
The strongest answer: A range, the assumptions behind it, the things that would move it, and the date by which I will narrow it
Why it works: Exactly. Ranges with named movers are honest and still useful to plan around.
- Range plus assumptions.
- Name what would move it.
- Say when you will narrow it.
- Do not quote the happy end.
How do you keep your own manager informed?
The strongest answer: A short regular written update — progress, risks, and what I need from them — so nothing they hear elsewhere is a surprise
Why it works: Exactly. Regular, short, and risks included, so your manager is never ambushed.
- Short and regular.
- Progress, risks, asks.
- No surprises.
- Share risks before they land.
A sales director asks your team to build a custom integration for one client this month.
What do you say?
The strongest answer: Here is what we are committed to; if this comes in, here is what moves — and I put that trade in front of the person who can choose
Why it works: Exactly. A no is a visible trade-off offered to the right decider.
- Show the commitments.
- Name what would move.
- Let the right person choose.
- Never quietly absorb it.
Every environment, secret and pipeline change your team needs goes through the platform team, and takes three to five days.
What do you do?
The strongest answer: Measure the wait, show the platform lead the pattern, and agree self-service for the two most common requests or a standing slot — then escalate with that data if nothing changes
Why it works: Exactly — a measured pattern turns “you are slow” into a fixable queue, and self-service removes the queue altogether.
- Fix the queue, not your place in it.
- Measure the wait.
- Ask for self-service.
- Escalate with data, not adjectives.
How do you make the case for two more engineers?
The strongest answer: Tie them to outcomes: what the team is asked to deliver, what will not happen without them, and the alternatives I considered such as descoping
Why it works: Exactly. Headcount is bought with outcomes and honest alternatives.
- Outcomes, not busyness.
- Say what will not happen otherwise.
- Show the alternatives.
- Do not pad the ask.
A large customer emails one of your engineers directly, demanding a fix by Friday and copying your VP.
What do you do?
The strongest answer: Take it off the engineer: one owner replies to the customer with what we know and when we will update them, I get the facts from the team, and we commit only to what is real
Why it works: Right — the engineer keeps working, one person owns the communication, and you promise only what you have checked.
- One owner communicates.
- Shield the engineer, not the problem.
- Get the facts first.
- Promise only what you checked.
You and your product partner disagree about the roadmap. How do you handle it?
The strongest answer: Go back to the shared outcomes we both own, argue it out privately with evidence, and once decided, commit and present one plan to the team
Why it works: Exactly. Shared outcomes, private disagreement, public commitment.
- Return to shared outcomes.
- Disagree privately, with evidence.
- Commit and present one plan.
- Never split the team.
How do you communicate with the executive team during a long outage?
The strongest answer: A fixed cadence with what we know, what we do not, what is happening next, and when the next update is — no speculation about cause
Why it works: Exactly. Cadence, honesty about the unknowns, next step, next update.
- Fixed cadence.
- Known, unknown, next.
- No speculation on cause.
- Say when the next update is.
You discover that two teams in your organisation are each building a notification service, both half-finished.
How do you resolve it?
The strongest answer: Both teams in one room with the requirements written down, pick one owner on fit rather than on who started first, and fund the other team’s migration instead of simply cancelling them
Why it works: Exactly — one owner chosen on fit, with the other team’s migration funded, is what makes the decision stick.
- One owner, chosen on fit.
- Put the requirements side by side.
- Fund the migration.
- Duplication is a visibility failure.
The CEO wants a launch date you believe the teams cannot meet without serious risk.
What do you do?
The strongest answer: Bring options with their trade-offs, state the risk plainly, and if the date stands, commit to it and keep the risk visible all the way through
Why it works: Exactly. Options, candour, then commitment with the risk in view.
- Bring options and trade-offs.
- State the risk plainly.
- Commit if overruled.
- Keep the risk visible.