Product & Delivery · Chapter 13 of 13
Technical program management, and the loop for it
The role split, the one company that publishes its whole TPM loop, why the design round is different from a software one, and what is ceremony.
Technical program management is the least-documented senior track in this field, which is strange given how many of these roles exist. It is also the one where the best preparation material is published openly by an employer and almost nobody finds it — Amazon documents its TPM loop, competencies and sample questions on its own careers site, in more detail than any interview-prep vendor provides.
Three titles, three different questions
Amazon's own framing is the cleanest available and worth knowing close to verbatim, because “how do your responsibilities differ from a project manager's?” is one of its published TPM questions. The technical half of the title is identifying dependencies and technical risks. The programme-manager half is scheduling, sprints, milestones and status. And the interplay is that the TPM does not just coordinate schedules — they help teams execute against them.
Contrast that with how the same company defines a technical product manager: create products and features on behalf of customers, write requirement specifications, segment customers, build business models, analyse success metrics. Value and viability, not seams.
The loop, as published
| Stage | Detail |
|---|---|
| Technical phone screen | 60 minutes with a senior leader; behavioural and technical. A second screen is possible depending on team |
| Writing assessment | Sent by the recruiter, due two days before the loop |
| The loop | Five 55-minute interviews, different interviewers assigned different competencies |
| Outcome | Within five business days |
The structure is identical for product manager, technical product manager and program manager. The difference is entirely in the competencies, and one line separates TPM from all three: expect at least one software systems design question. The technical product manager gets a technical-depth round instead; the product and program managers get neither.
Why the TPM design round is not a software design round
The artefact on the whiteboard looks similar. What is being assessed is different, and the questions the employer tells you to ask give it away — they are programme questions, not implementation questions:
Who are you designing for, and why? What would your customer assume is in the system without having it in the forefront of their mind — that it will be fast, that it will be secure? What happens if we become hyper-popular; what does twice the growth look like, or ten times? Where are the bottlenecks, failure points and redundancy, and how do we get log access to debug it? If several designs are viable, compare the trade-offs, pick one, and justify it.
And the single most useful published sentence, which almost no candidate knows: they are looking for broad comprehension of system design and expertise in one area, and if you are asked about an unfamiliar topic you should say so and suggest exploring a familiar one instead.
That is explicit permission to redirect. Candidates bluff instead — and bluffing is precisely the failure mode a TPM depth round is built to detect, because a TPM who cannot say ‘I don't know that, here is what I do know’ is a TPM who will not surface a risk either.
The competency almost no one prepares for
Look at how the stakeholder competency is written. Four of its six elements are about influence without authority: negotiating with internal and external parties so that dependencies are well-timed; leading through actions rather than directives; bringing diverse stakeholder groups to agreement on objectives; and creating mutually beneficial outcomes so that every party advances their own goals.
That is the job. A TPM has no reporting line into the teams they depend on, so every dependency is a negotiated commitment rather than an instruction. Interview answers that describe escalating to get something done are describing the failure path.
On the writing assessment: it is not a filter you can forget after submitting. Interviewers may ask about it in the loop, and the published guidance is to write about something innovative and complex that you personally drove, showing your thought process and how you used data. And on behavioural answers, the instruction is unusually blunt: say what you did, not what the team did — use “I”, not “we”.
Dependencies, float, and what is ceremony
| Earns its keep | Usually ceremony |
|---|---|
| The dependency graph as a live artefact — this is the entire technical half of the role | Risk registers scored on a 1–5 by 1–5 grid. Same ordinal-multiplication defect as RICE, and the scores are almost never revisited after the kick-off |
| Float, not the critical path. Knowing which items have zero slack tells you where to put attention; the critical path is a by-product | RAG status decoupled from dates. If a programme can be Green while a zero-float dependency is late, the status is decorative |
| Dependencies as dated contracts with a fallback — not 'team B owes us X' but 'B delivers X by date D, and past D we take path Y' | Full network schedules for software. The duration estimates have error bars wider than the float, so the computed critical path is not stable enough to act on |
| Tracked assumptions. The most under-used item in a RAID log — assumptions are risks nobody has priced | Re-baselining to make slippage disappear. The most common way a programme lies to itself |
| Risks with a decision date — a date by which the mitigation must fire, or it is not tracked | A dependency spreadsheet nobody's incentives touch. A dependency is managed only if someone's date moves when it slips |
Worth saying plainly, in the same spirit as the prioritisation chapter: I could find no empirical evidence that risk registers improve project outcomes. Searches of the academic literature return nothing relevant. That is a null result honestly reported, and it sits alongside the same finding for prioritisation frameworks. Both of these disciplines are largely un-evidenced at the level of their signature artefacts, which is worth knowing before you defend one in a room.
Check yourself