Technical program manager leadership interview questions

As asked

You are running a launch that depends on 5 engineering teams shipping coordinated changes by a fixed date. Walk me through how you set this up.

Sample answer outline

Start with the dependency map: who depends on what, in what order. Convert it into a critical path with explicit handoff dates and owners. Stand up the right rituals: weekly programme review for cross-team status, daily standup only when the launch is hot. Build a single source of truth (a status doc, not slides) that every team updates. Identify the top three risks early and the mitigation for each. Pre-mortem: assume the launch slipped, what was the cause, mitigate it now. The TPM's job is to make the bad news travel fast and the decisions get made before the slip is irreversible.

Expect these follow-ups

• What if one team is consistently late on their commitments?
• How do you balance reporting overhead against actual progress?
• How do you handle a director who only wants to hear green status?

As asked

Walk me through how you track and manage risks on a programme. What does your risk register look like and how is it actually used?

Sample answer outline

Risks are not the same as issues; a risk is what could happen, an issue is what has happened. The register has columns: description, owner, likelihood, impact, mitigation, target close date. Top risks get reviewed weekly in the programme review with the owner accountable for progress on the mitigation. Stale risks get re-evaluated or closed. The trap is a 50-row risk register no one reads: keep it short and have a real conversation about the top five. The strong TPM uses the risk register to drive decisions, not as a CYA artifact.

Expect these follow-ups

• How do you score impact in a way that does not collapse to 'high'?
• What is the difference between a risk and a dependency?
• How do you raise a risk to an executive who keeps saying it is fine?

As asked

Your org has 80 engineers across 8 teams and no real planning process. Design the quarterly planning cycle.

Sample answer outline

Pre-planning (2 weeks before): each team drafts proposed projects with rough sizing and impact estimates. Cross-team dependency mapping happens here. Planning week: leadership reviews the proposed slate against company priorities, makes tradeoff decisions, and assigns goals. Post-planning: teams commit to a small set of goals (3 to 5 per team) with clear owners. Cadence during the quarter: monthly progress reviews and a mid-quarter checkpoint to rebaseline. Closeout: did we ship what we said, what did we cut, what did we learn. Keep the process light enough that engineers spend less than 10 percent of their time on it.

Expect these follow-ups

• How do you handle a CEO who keeps adding priorities mid-quarter?
• What is the right number of goals per team?
• When does OKRs help and when does it just add overhead?

As asked

How do you write status reports that executives actually read and act on? What is your template?

Sample answer outline

Short, scannable, honest. Top: a one-line summary plus a colour (green, yellow, red) that reflects reality, not optimism. Then: what shipped this period, what is on track, what is at risk and why, what decisions you need from the reader. Avoid 'we had a meeting' as content. Avoid the temptation to bury bad news. Length: one screen. Cadence: weekly for active programmes, biweekly for steady-state. The test of a good status report is whether an executive who reads only the top line could correctly answer 'is this programme on track'.

Expect these follow-ups

• How do you handle pressure to report green when the programme is yellow?
• What is the difference between a status report and a dashboard?
• When does written status replace meetings?

As asked

Your VP of product wants feature A, your VP of engineering wants infrastructure work B, and both report to the same SVP. They both ask you to prioritise their thing. How do you handle it?

Sample answer outline

Do not pick a side as a TPM. Bring the data to the conversation: what each path costs in time and people, what each delivers in business value, what the risks are. Get the two VPs and ideally the SVP in one meeting and force the prioritisation call. Document the decision and the rationale. The TPM owns the decision-forcing function, not the decision itself. The bad version of this story is the TPM quietly favouring whichever VP is more pleasant to work with.

Expect these follow-ups

• What if the SVP refuses to make the call?
• How do you handle the losing VP after the decision?
• When does this kind of conflict signal an org problem, not a programme problem?