Questions to Ask a Program Manager
Questions to ask a program manager, whether you are hiring one, joining a program they run or sounding one out about the job. The 62 questions open with track record, the group an interviewer needs first. The next four are mostly worded for someone running a program today: what the role covers, how the plan and its status are kept honest, risk and dependencies, and the people side. In an interview, point those at the candidate's last program. The last group turns the table, for candidates who want good questions to ask in an interview for a program manager job.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Track record
Walk me through the largest program you have run: how many teams, what budget, over how long?
Why ask it
Three numbers early set the scale of everything that follows. Candidates often describe programs they coordinated a part of, so ask specifically what they owned and who else was doing the same job alongside them.
What was the gap between your original plan and what actually shipped, and what caused most of it?
Why ask it
A candidate who quotes a real number, even a bad one, has run a program to the end and looked back at it. Vagueness here usually means they left before the reckoning or never compared the two.
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.
How would you explain the difference between a program and a large project?
Why ask it
The usual line is that a project delivers a defined output while a program holds several related projects to a shared outcome, though employers use the titles loosely. What you are listening for is competing priorities between workstreams, not just a longer schedule.
You inherit a program already in trouble. What do you do in the first month?
Why ask it
The first weeks belong to finding out what is true: talking to the people doing the work and checking the plan against what exists. A candidate who opens with new rituals will spend the month producing paperwork.
What were you doing before program management, and what from that job do you still lean on?
Why ask it
Most program managers arrive from somewhere else: engineering, project management, operations, consulting. The previous job tends to show in what they check first when a program wobbles, whether that is the architecture, the schedule or the contract.
What did you have to stop doing yourself as your programs got bigger?
Why ask it
People who have made the jump can list what went: attending every meeting, knowing every detail, chasing individuals when they should have been working through leads. A candidate who says nothing changed has probably not run the larger program yet.
Which problem did you find out about too late, and what kept it hidden?
Why ask it
The useful part is whether they can name a structural cause, such as a team that reported up a different chain or a metric nobody owned. A story that settles on one person to blame leaves the same blind spot in place for the next program.
When did you raise a risk that nobody acted on, and what did you do next?
Why ask it
You find out how they escalate when the first attempt fails, and whether they kept a record. Also watch whether the story ends in vindication and nothing else, which suggests they treat being right as the deliverable.
Which program you worked on should have been stopped sooner, and what kept it going?
Why ask it
Stopping is the decision programs are worst at, because the money already spent argues for spending more. Their account shows whether they see the job as delivering the plan or as telling the sponsor when the plan no longer makes sense.
The role
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.
Why does this program exist, and what would be lost if it stopped tomorrow?
Why ask it
A clear answer names a customer, a cost or a deadline set by something outside the company. If the reply is a list of the projects inside it, the program may be a reporting bundle with no shared goal, which makes every tradeoff between teams harder to argue.
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, because each added team brings its own priorities to reconcile. A candid answer usually includes at least one team that is only partly committed to the program.
Who is the sponsor, and how much of their week does this program get?
Why ask it
A sponsor is the person who can settle a fight between two directors, so their attention is a resource like any other. An hour a month from someone running six other things means decisions will queue, and the program manager will be asked to make calls they have no standing to make.
Where does your job stop and the product managers' or project managers' jobs start?
Why ask it
The three titles overlap differently in every company, and the boundary is often set by habit. A common split leaves what and why with product, a single workstream's plan with its project manager, and the joins between workstreams with the program manager, but ask how it works here.
Who holds the program's budget, and what can you move between workstreams without asking?
Why ask it
Some program managers control the money, many report on a budget that sits with finance or a sponsor, and a few never see the figures. The practical test is whether they could shift a contractor from one team to another this month on their own say.
How does your week split between meetings, writing things down and chasing people?
Why ask it
The proportions describe the job more accurately than a job description does. A week that is nearly all meetings leaves no time to compare what was said in them with what the teams are doing, and that comparison is the part nobody else on the program is placed to make.
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, often 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.
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.
Plan and status
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.
Who produced the estimates in the current plan, and were the dates set before or after them?
Why ask it
A plan built from the teams' own estimates and a plan worked backwards from an announced date look identical on a chart. Only the first has people behind it who believe it, so the order in which the two things happened is worth knowing.
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.
Which milestone in the next three months are you least confident about?
Why ask it
It is a gentler way of asking where the plan is weakest, and easier to answer than a question about failure. Notice whether they volunteer what would have to go right, or only say that the teams are aware of it.
What does your status reporting look like, and who reads it?
Why ask it
Ask how long it takes to produce and which decision the last one led to. A report that eats a day of every week and that nobody can tie to a decision has become a tax on the program.
What turns a workstream red in your reports, and who is allowed to change the color?
Why ask it
Colors are only useful if the rule behind them was agreed before anyone needed it. Where a team lead can argue a red back to amber in the meeting, the report measures negotiating skill, and the sponsor reads it as fact.
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.
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.
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.
Risk
What is the biggest dependency you are carrying that you do not control?
Why ask it
It is commonly a shared platform team, a vendor or a compliance sign-off. A program manager who has to stop and work out which one it is may be tracking tasks more than managing risk.
Where are the dependencies between teams written down, and when did that record last turn out to be wrong?
Why ask it
A dependency map goes stale the week after it is drawn, because teams renegotiate with each other directly. The second half of the question shows whether anyone checks it against what the teams are building, or whether it is a diagram from the kickoff deck.
How do you keep a dependency honest when the other team does not report to you?
Why ask it
Much of the job comes down to this. What works is making the commitment visible to someone the other team answers to, plus an early test that the thing promised exists. Goodwill alone tends to last until that team's own deadline arrives.
Which outside vendor or partner sits on the critical path, and what happens if they are late?
Why ask it
Outside parties are the dependencies a program manager has least hold over, since the lever is a contract someone else signed. Ask who owns that relationship day to day, and whether the plan has anything in it for a delivery that slips a month.
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.
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.
Where is the slack in the schedule, and who is allowed to spend it?
Why ask it
Slack hidden inside each team's estimates is spent quietly by whichever teams run late first. Held in one visible place with a named owner, it becomes a decision each time some goes, and the program learns early how fast it is burning through it.
What got cut the last time a date could not move, and who made that call?
Why ask it
Fixed dates force a choice between scope, quality and people's evenings, and the choice made under pressure is the real policy. The other half of the answer is who made it: an executive, a product owner, or nobody until the slip made it for them, which is the expensive way.
When someone senior adds work halfway through, what do you ask before saying yes?
Why ask it
The request is rarely refused, so the skill lies in pricing it. A practiced program manager comes back with what moves or drops to make room and asks the requester to choose, which turns an instruction into a tradeoff with an owner.
How do you decide what not to escalate?
Why ask it
This separates program managers from message relays. A good one can state the threshold: cost, reversibility, whether the owning team already has it in hand. Escalating everything burns credibility as fast as escalating nothing.
When you do escalate, who do you take it to, and what do you put in front of them?
Why ask it
The route matters as much as the content: a problem raised to the wrong person sits in an inbox. Look for a habit of arriving with two or three options, what each costs, and the date by which a choice is needed.
People
What happens when two teams need the same person in the same week?
Why ask it
Contention over one specialist is where the role is either real or nominal. Listen for whether they worked out what each team loses by waiting a week and settled it with the two leads, or passed the clash upward and left both teams blocked.
When two teams disagree about what should be built first, how does it get settled?
Why ask it
Sequencing arguments are usually each team protecting its own date, and both are right from where they stand. You want to hear how the program's priorities were used to break the tie, and whether the losing team was given the reason or only the result.
When did you last tell a senior stakeholder something they did not want to hear?
Why ask it
On a program of any size there is usually news of that kind to deliver. If the example is vague or years old, bad news is probably being softened at each level until it reaches the top as a surprise.
Which stakeholder is hardest to keep informed, and what have you tried with them?
Why ask it
The usual candidate is too senior to read the report, too far from the work to attend the reviews, and certain to be surprised. What they have tried, such as a five-minute call before each steering meeting, says more than a general statement about communication plans.
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.
How do you handle a team lead who agrees in the meeting and then does nothing?
Why ask it
The cause is often a competing priority from the lead's own manager, not obstruction, so the first step is finding out why. A reply that is all accountability and follow-up suggests they have never asked.
How do you work with an engineering or product lead who thinks the role is overhead?
Why ask it
It is a common view, and worth hearing them handle without getting defensive. The program managers who win such leads over tend to start by taking a concrete chore off them, such as chasing another team for a date, before making any case for the discipline.
What would the last three team leads you worked with say is frustrating about working with you?
Why ask it
Naming three people makes a rehearsed weakness harder to offer, because the answer has to sound like something a colleague would say. Program managers tend to know their own version of the complaint: too many check-ins, too many documents, or decisions reopened after they were closed.
How do you bring someone up to speed who joins mid-program?
Why ask it
A good sign is 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 do you ask of each team every week, and what do you wish they would tell you unprompted?
Why ask it
If you are joining the program, the first half is your recurring workload and the second half is how to be easy to work with. The wish tends to be the same in spirit: early word that a date is in doubt, before it is certain.
If my part of the work looks like it will be late, how and when do you want to hear about it?
Why ask it
Asking this in your first week sets up the conversation you will need later. Some want a message the same day, others want it held for the weekly review with a revised date attached, and guessing wrong makes an ordinary slip look like concealment.
For candidates
Which program would I be running, and what state is it in today?
Why ask it
Program manager postings are sometimes written before anyone has decided which program the hire will take. A named program with a frank status, late or not, is a better sign than a tour of the portfolio, because it means someone has thought about what you would do in your first month.
Who has been running this program until now, and where are they going?
Why ask it
Whoever held it before knows where the plan is soft, so it matters whether they will still be down the corridor. When a director has been running the program part time, expect half-made decisions and stakeholders used to going straight to the top.
Where does program management sit here: under a PMO, engineering, product or operations?
Why ask it
The reporting line shapes whose side you are assumed to be on. Inside engineering you are closer to the work and further from the budget, and inside a central office you carry its templates and its reputation with you. Neither is wrong, but they are different jobs under one title.
How many teams would I be coordinating, and does anyone on them report to me?
Why ask it
In many program manager roles nobody does, and the job runs on influence. That is normal, so the useful follow-up is what earlier program managers here did when a team's own manager set a different priority, and who backed them.
Is this a technical program manager role, and how deep into the engineering do you expect me to go?
Why ask it
Some employers keep the technical title for people who review designs and question architecture, others give it to anyone whose teams write software. Asking for a technical decision the last person in the seat influenced tells you which, and whether the interview loop will test it.
Which decision on this program is stuck right now, and whose is it to make?
Why ask it
A stuck decision is likely to be the first thing a new program manager is handed, so it is worth hearing about before you accept. If the interviewer cannot say whose call it is, getting an owner named would be your first piece of work, and the reply shows how much standing the role has.
What happened on the last program here that missed its date?
Why ask it
How the story is told shows what lateness costs the person in the role. An account of what was replanned and learned points one way. An account that ends with the program manager being moved on points the other.
How many other programs draw on the same teams, and who ranks them when they clash?
Why ask it
A program's dates depend on how much of each team it really gets. Where several programs share engineers and nobody ranks them, the program managers end up bargaining with each other every week, so ask who sets the order and when it last changed.
What does the executive sponsor expect to see from this role, and how often?
Why ask it
It tells you whether you would be a partner in decisions or the author of a monthly deck. Ask to see a recent status report if they will share one, since its length and tone show how much candor the audience is used to.
A year from now, what would make you say this hire had worked?
Why ask it
Program outcomes often land after the first year, so the measure in between is usually softer: fewer surprises, faster decisions, teams that stop routing around the process. Whichever one the hiring manager picks is what they feel is broken today.
Is there anything in my program experience that makes you hesitate?
Why ask it
It lets you answer a doubt while you are still in the room, such as never having run a program this size or in this industry. Ask it only if you can take the answer calmly, and keep your reply to one concrete example.
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.
- Choose the groups by what the vacancy needs. A program already in trouble calls for the Risk and the Plan and status questions, put to their last program. A program still being set up calls for The role, where the sponsor, the budget and the finish line get settled.
If you are the one being interviewed
- Prepare more of your own questions than you expect to get through, since the time left at the end varies by interviewer. Pick from the For candidates group the ones whose answers could change your mind about the job, and open with the state of the program you would inherit.
- Match the question to the person. A recruiter knows the reporting line and the timetable, the hiring manager knows the sponsor and the last missed date, and a team lead on the panel knows what the previous program manager was like to work with.
- Have your own figures ready before you ask about theirs: the most teams you have coordinated, the largest budget you reported on, the longest program you saw through to its end.
- After each round, write down what you were told about authority and reporting lines. Different interviewers often describe the same program manager role differently, and the gaps are worth raising before you accept.
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 a common 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.