How do you answer stakeholder and leadership communication questions?

In this article

1. Before you start
2. Why interviewers ask this
3. Stakeholder and leadership communication from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

For the wider topic, see the program manager interview questions guide. This page uses the Scrum framework for some examples, but the method works in any delivery style.

Why interviewers ask this

A project can fail with a good plan if the people who fund it, depend on it or approve it learn the truth too late. Interviewers use communication questions to see whether you tell people the truth in a form they can act on. The prompts are often "tell me about a time you had to deliver bad news to leadership" or "how do you keep stakeholders informed"; the program manager scenario questions show the same skill under a longer case.

A weak answer lists channels: weekly email, a dashboard, a status meeting. A strong answer picks the message for the audience, leads with the conclusion and says what it needs from them. A Staff-level answer also shows what you did when the news was bad, how you offered options, and how you confirmed the decision was understood. Project managers, program managers, Scrum masters and business analysts all meet these questions; see the project manager question list and the business analyst question list.

Stakeholder and leadership communication from first principles

Leadership update

A leadership update is a short message that tells the people who fund or approve a project where it stands, what changed, what risk remains and what decision is needed, written so that the reader can act without a meeting.

The ask

The ask is the single request a message makes of its audience, such as a decision, a resource or an acknowledgement, stated in one sentence and placed near the top so the reader knows why they are reading.

In plain words

Think of a pilot's announcement. The pilot does not describe every dial. The pilot says where the plane is, that it will land late, why, and what passengers should do about connections. The analogy breaks in one place: passengers cannot change the flight, but your stakeholders often can, so your message must ask them for something.

The same holds on a project. A leader with two minutes needs the new date, the reason and the choice in front of them, not a log of what the team did this week. What you leave out is as deliberate as what you put in.

In one precise sentence, stakeholder communication is choosing, for each audience, the facts that bear on a decision they own, and giving those facts in an order that lets them decide.

Step 1: Name the audience and what they decide

Start by asking who is reading and what they decide. An executive may decide funding or priority. A peer team may decide whether to hold a dependency date. Your own team needs to know what changed for them.

Scrum shows how much this matters. The Scrum Guide (2020) says "The Product Owner is one person, not a committee." The Product Owner is the person accountable for the product backlog, the ordered list of work. The Guide adds that people who want to change the backlog do so "by trying to convince the Product Owner." So the right audience for a priority request is that one person, not the whole room.

You now know your first task: write down the decider and the decision before you write a word of the message. Many stakeholders want only to be informed, and they need less detail than the person who must approve.

Step 2: Lead with the answer and state the ask

The first two sentences of a leadership update give the conclusion and the ask. The conclusion says whether the project is on track and what changed. The ask says what you need. Details come after, for readers who want them.

An ask has three common forms: a decision ("approve a two-week move"), a resource ("release one more tester") or an acknowledgement ("confirm you have seen the new risk"). Pick one. A message with three asks gets none answered.

A red-amber-green (RAG) status is a three-colour label that signals whether a project is on track, at risk or off track; it is called RAG status in project reports. Use it only as a heading, never as the message. "Amber" tells the reader nothing about what to do; "amber, and I need a decision by Friday" does. The ask is the part that is easiest to leave out of a spoken answer. After the colour, add the reason in a clause and then the request.

Step 3: Give the evidence and the risk, plainly

After the answer comes the evidence: what happened, what you measured, and what could still go wrong. Keep it factual and specific. State bad news in the sentence where it belongs, not at the end of a long paragraph.

The Scrum Guide gives the principle: "Transparency enables inspection. Inspection without transparency is misleading and wasteful." Leaders decide on what they believe the state of the work to be. If the picture you give is rosier than the facts, their decisions rest on a false picture, and the cost lands on the project later.

Name one risk and its trigger, meaning the event that would tell you the risk has arrived. Offer options where you have them, with the cost of each. You now have the body of the message: evidence, one risk, and two choices. The next step is making sure the message did its job.

Step 4: Close the loop with a next step and a date

A message ends with what happens next, who does it and by when. Then you check that the audience understood. If you asked for a decision and none came, say so at the date you gave and ask again, shorter.

Scrum builds this loop into its events. The Sprint Review is the event where the Scrum Team presents results to key stakeholders and progress toward the product goal is discussed. The Guide says "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation", and that it "should never be considered a gate to releasing value." The Sprint Goal is a short statement of why the Sprint is valuable to stakeholders. When scope shifts mid-Sprint, the team renegotiates scope with the Product Owner and the goal stays the message. Outside Scrum, the principles behind the Agile Manifesto make the same point: "Business people and developers must work together daily throughout the project."

In short: Step 1 names who decides and what each audience needs; Step 2 leads with the answer and states the ask; Step 3 gives evidence and risk, plainly; Step 4 closes the loop with a next step and a date.

1 · Audience2 · Answer and ask3 · Evidence4 · Next stepReplay

Step-by-step description

1. Name who decides and what they need.
2. Lead with the answer and state the ask.
3. Give evidence and risk plainly.
4. Close the loop with a date.

• Step 1 names who decides and what each audience needs.
• Step 2 leads with the answer and states the ask.
• Step 3 gives evidence and risk, plainly.
• Step 4 closes the loop with a next step and a date.

Worked example

The scenario is invented and labelled illustrative. A project is planned for 12 weeks, and at the end of week 9 the forecast shows it needs 2 more weeks than planned.¹ Planned remaining time is 3 weeks and forecast remaining time is 5 weeks, so the remaining work is 66.7% longer than planned, while the whole project is only 16.7% longer.¹ Both numbers are true, and a leader should hear the one that bears on the decision.

The update, built from the four steps: "Amber. We forecast 14 weeks against a plan of 12, because an integration partner changed its interface. I need a decision by Friday between two options. Option A moves the release date by two weeks and keeps all scope. Option B drops one low-priority feature and moves the date by one week. The risk is a second partner change; I will know by next Wednesday and will tell you the same day."

Text description of the diagram

• The plan was 12 weeks and the forecast is 14 weeks.
• Cutting a low-priority item gives a 13-week forecast.

The plan was 12 weeks and the forecast is 14 weeks. Cutting a low-priority item gives a 13-week forecast.

A weak and a strong answer to "tell me about a time you had to deliver bad news to leadership"

Both answers below are an illustrative example, a composite of a candidate answering with the same invented schedule problem, described in the third person. The strong one follows situation, action, result.

The weak answer: the candidate says a partner changed an interface, the team worked hard, and leadership was eventually told the project would be late. There is no decision, no option and no date, and the result is "it worked out".

The strong answer: the situation is one sentence, a partner changed its interface and the forecast moved from 12 weeks to 14 (illustrative). The action is the part that matters: the candidate told the director the same day and said "I need a decision by Friday between moving the date and cutting one low-priority feature." The result is what leadership chose, plus the follow-up the candidate then sent with an owner and a date.

The words that make it stronger are "the same day", "I need a decision by Friday", the two named options and the dated follow-up. The same structure answers "tell me about a time you managed a difficult stakeholder": name what they needed, what you brought them and what was decided.

The rubric for this question

Trade-offs and edge cases

Detail and brevity pull against each other. A short update risks hiding the reasoning; a long one buries the ask. The usual fix is layers: the first two sentences carry the answer and the ask, and the evidence below is for readers who want it.

Text description of the diagram

• A status dump opens with activity; a decision-led update opens with the answer.
• The decision-led update ends with a dated next step.

A status dump opens with activity; a decision-led update opens with the answer. A status dump buries bad news late, while the decision-led update states it plainly. The decision-led update ends with a dated next step, and the status dump ends without asking anything.

Edge cases need judgement. Different audiences need different depth, and the Guide does not say how much detail senior leaders want, so ask them. When you do not yet know the cause of a problem, say what you know, what you do not and when you will know. Do not guess to fill the gap.

Two Scrum points apply. Disagreements between stakeholders over priority go to the Product Owner, because the Guide gives that role the backlog. The Guide also lists, among the Scrum Master's duties, "Facilitating stakeholder collaboration as requested or needed", so a Scrum Master clears the way rather than relaying every message. The timeboxes are fixed ceilings: the Sprint Review is at most four hours for a one-month Sprint, and usually shorter for shorter Sprints, per the Scrum Guide, which Scrum.org also hosts.

How to answer it in an interview

The spoken structure: audience, then answer and ask, then evidence and options, then the dated next step. If you have a real example, keep it to your own work and say what the decision was.

Common mistakes

• "I send everyone the same weekly update." (wrong) Audiences decide different things. (right) "I tailor the message to what each audience owns and keep the full detail one click deeper."
• "I wait until I have the full picture before I tell leadership." (wrong) Late news removes their options. (right) "I say what I know, what I do not, and when I will know."
• "I just report the colour." (wrong) A colour with no reason is not a message. (right) "Amber, because of a named risk, and I need this decision by Friday."
• "The Sprint Review is where stakeholders approve the release." (wrong) The Guide says it should never be considered a gate to releasing value. (right) "It is a working session where we inspect the Increment and adapt what comes next."
• "Stakeholders can reorder the backlog themselves." (wrong) They persuade the Product Owner. (right) "I route priority requests through the Product Owner."

Follow-up questions

How do you tell senior leadership about a delay?

Give the new forecast, the cause and the ask in the first two sentences, then offer two options with their cost and say when you will update them again. Do it as soon as you know, not at the deadline.

How do you communicate with stakeholders in Scrum?

Use the Sprint Review as a working session with key stakeholders, keep the Sprint Goal as the message of why the Sprint matters, and route requests to change the backlog through the Product Owner. The Scrum master question list covers the facilitation side.

What do you do when two stakeholders want opposite things?

Put the trade-off in front of both, with its cost, and ask the accountable decider to choose; in Scrum that is the Product Owner for backlog priority. Then tell both people the decision and its reason. The prioritisation frameworks answered as a technical program manager (TPM) page shows ways to frame that trade.

How do you report status to executives?

Open with the RAG colour and its reason, state the ask, give three or fewer facts and end with the next date. Keep a longer version available for anyone who wants it.

How do you handle a difficult stakeholder?

Find out what they own and what they fear, then bring facts and options rather than arguments. When they keep changing priorities, show what each change displaces and route the request to the person who decides; in Scrum the Guide says scope may be clarified and renegotiated with the Product Owner as more is learned. Influencing leaders without authority works the same way: evidence, options and a clear ask.

How do you manage stakeholder expectations?

Agree early what will be delivered, by when and what would change that, then report against that agreement at each checkpoint instead of at the deadline. Tell people as soon as a forecast moves, with the cost of each option.

Sources

1. The 2020 Scrum Guide — Ken Schwaber and Jeff Sutherland (scrumguides.org), 1 Nov 2020
2. The 2020 Scrum Guide (PDF edition) — Ken Schwaber and Jeff Sutherland (scrumguides.org), 1 Nov 2020
3. Principles behind the Agile Manifesto — Agile Manifesto authors (agilemanifesto.org), 13 Feb 2001