Questions to Ask a Program Manager
Questions for a program manager, whether you are interviewing one, joining a program they run, or weighing up the job yourself. They cover what the role is accountable for, how scope and dependencies get decided, and how trouble surfaces before a date slips.
The questions
Open any question for the note
What are you accountable for on this program, and what can you only influence?
Why ask it
Program managers usually own dates and dependencies without owning the engineers, the budget, or the roadmap. The size of that gap between accountability and authority predicts the daily experience of the job better than the title or the org chart does.
What is in the program right now, and how many separate teams does it touch?
Why ask it
Team count tells you more about difficulty than budget does. Past four or five, most of the work becomes coordination, and the candid answer usually includes at least one team that is only partly committed to you.
Who decides when something gets cut?
Why ask it
Scope calls are made by an executive, by a product owner, or by nobody until a date slips and the decision makes itself. The third case is both the most common and the most expensive, and the answer here tells you which one you are in.
Where does the program stand against its plan, and how do you know that?
Why ask it
Push on the evidence: a tracker only they maintain, status the teams self-report, or something observable like working software in an environment. Self-reported status tends to stay green right up to the point where it cannot.
What is the biggest dependency you are carrying that you do not control?
Why ask it
Every program has one, commonly a shared platform team, a vendor, or a compliance sign-off. A program manager who cannot name it instantly is tracking tasks rather than managing risk.
How do you find out something is off track before it shows up in a report?
Why ask it
The real answers are informal: sitting in a team's standup, reading the pull requests, one engineer who tells them the truth early. Answers that are purely about process usually mean bad news arrives late and in a meeting.
How often does the plan change, and what happens to the dates it used to have?
Why ask it
Programs that quietly restate dates lose the ability to learn from them. Keeping the original baseline visible next to the current one is uncomfortable, and it is what makes the next set of estimates less wrong.
What does your status reporting look like, and who reads it?
Why ask it
Ask how long it takes to produce each week. More than half a day, or a report nobody can name a decision from, means reporting has become a tax rather than a tool.
What happens when two teams need the same person in the same week?
Why ask it
Contention is where the role is either real or nominal. Listen for whether they escalate with two costed options or simply hand the conflict upward and wait, which leaves both teams blocked while it sits.
What are the top three risks right now, and what would you do if each one landed?
Why ask it
A working risk list is short, has an owner and a trigger for each item, and changes month to month. A long register nobody has opened since kickoff means risks are being recorded instead of managed.
Which of the program's recurring meetings would you cancel if it were up to you?
Why ask it
The answer separates the rituals that hold the program together from the ones that survive because nobody has questioned them. It also shows whether they treat other people's calendars as a real cost.
What does done look like here, and who signs it off?
Why ask it
Programs stall at the end because completion was never defined. Shipped, adopted, and handed over to a support team are three different finish lines, months apart, and stakeholders often each assume a different one.
How will you know the program delivered what it was funded to do?
Why ask it
Counting features shipped is easy and often tells you nothing. An outcome measure requires someone to have taken a baseline before the work started, so ask directly whether that number exists and who owns it.
Tell me about a program that went badly. What did you do, and what changed afterwards?
Why ask it
The change is the part that matters. A story that ends in the failure being someone else's fault, or in a lesson too general to act on, suggests the same thing will happen again in the same way.
When did you last tell a senior stakeholder something they did not want to hear?
Why ask it
The job requires this every few weeks. If the example is vague or comes from years ago, bad news is probably being softened at each level until it reaches the top as a surprise.
What do the teams on the program think of the process you run?
Why ask it
The answer worth hearing includes a step they removed because a team said it was pointless. Program managers who only describe compliance with their process rarely notice when the process has started slowing the work down.
Which tools do you use, and which ones do the teams actually keep current?
Why ask it
Adoption matters more than the choice of tool. One tracker teams update because it helps them beats a portfolio suite that only the program manager touches, which quietly turns into a fiction everyone reports against.
How do you bring someone up to speed who joins mid-program?
Why ask it
Look for a short written brief, the current risks, and a list of who to ask about what. Where onboarding is a week of meetings and inherited memory, expect stakeholders to be operating on equally patchy information.
What part of this job did you not expect before you did it?
Why ask it
Useful if you are considering the path yourself, because it surfaces the unglamorous majority of the work: chasing, writing things down twice, absorbing other people's frustration. An answer with no downside in it suggests little reflection.
If you left next month, what would fall over?
Why ask it
Programs held together by one person's memory are fragile, and most program managers know exactly where their own single points of failure are. A specific answer doubles as a list of what needs writing down.
Getting straight answers from a program manager
Practical guidance for the conversation itself
If you are interviewing them
- Ask about one real program end to end rather than about their methodology. Methodology answers are rehearsed; a specific program forces detail about who decided what and when.
- Follow every process answer with "what happened the last time that failed?" The gap between the described process and the recovery story is where the actual skill shows.
- Give them a scenario from your own organization, such as a platform team missing a date that three programs depend on, and listen for whether they ask about the money, the customers, or the org chart first.
- Check whether they distinguish program management from project management in their own words. Someone who has only run single projects will describe a bigger schedule rather than competing priorities.
If you are joining a program they run
- Find out what you personally will be asked to report, how often, and who reads it. This is the recurring cost of being on the program.
- Ask which decisions you can make without checking, and which ones need to go through them. Getting this wrong in the first month is the usual source of friction.
- Ask what the program has already tried and dropped, so you do not reopen a settled argument.
- Get the current dates and the original dates. The difference tells you how much of the plan is still real.
Answers worth probing further
Certain answers sound complete but are not. "We are on track" needs "against which version of the plan?" "We have good stakeholder alignment" needs "who most recently disagreed, and how did that end?" "We use two-week sprints" needs "what did you decide to drop last sprint?" In each case the follow-up asks for an event with a date on it. If none is forthcoming after two attempts, treat the topic as unknown rather than as fine.
Warning signs
- The plan has never moved. Either nothing has been learned or nothing is being reported honestly.
- Risk and status live in documents that only the program manager updates.
- They cannot say what the program is for in a sentence that mentions a customer or a cost.
- Every problem is described as a communication issue, which usually means unresolved priority conflicts nobody wants to escalate.
- Escalation happens as a complaint rather than as a decision request with options and consequences attached.