The discipline of delivering an outcome that spans several engineering teams you do not manage. Its content is dependencies, sequencing and risk made visible early enough to act on, and its difficulty is that every commitment you rely on was given voluntarily.
High demand18 min readTechnical program manager, Senior technical program manager, Program manager, Delivery manager, Engineering programme lead, Chief of staff to engineeringUpdated 2026-08-10
Assumes you know: Enough technical background to read a design document and find what is unresolved, Experience working inside a software delivery team, in any role, Comfort with a spreadsheet and simple arithmetic done in front of people, Willingness to write clearly and briefly under time pressure
Overview
What this area actually covers
Technical program management is the work of getting an outcome delivered when it depends on several engineering teams, none of which report to you. That sentence contains the entire discipline, including the part that makes it hard.
Concretely, a TPM owns the space between teams. Where a schema has to be agreed by two groups who will each build against it. Where an API a mobile team needs is being built by a platform team with three other customers. Where a migration has to be rehearsed, timed, and fitted into a maintenance window that a fourth team controls. Where a security review nobody scheduled has to happen before a launch gate that nobody has defined. None of that work sits inside any one team's backlog, which is why it arrives unowned and late, and why the role exists.
The three things a TPM produces are a plan whose sequencing is defensible, a risk picture that surfaces problems while there is still room to respond, and a flow of decisions — resolved dependencies, agreed interfaces, made trade-offs. That last one is the real output. A program does not fail because nobody wrote a plan; it fails because forty small decisions were each deferred by a week.
It helps to define the area by its two neighbours, because it sits between them and is frequently mistaken for either. Below it is engineering management, which owns people, technical quality, and how the work inside a team gets done. Above it is product management, which owns what should be built and why. Technical program management is the middle: given that the what is chosen and the teams are staffed, make this collection of teams deliver one thing on a date, and make the risks in doing so visible before they become facts.
What gets wrongly bundled in is worth naming, because a lot of job descriptions bundle it. Project administration — maintaining a plan, chasing task updates, producing a deck — is a part of the job that has been shrinking for a decade and is the part that gets automated or eliminated first. People management is not in the role at all in most organisations; a TPM has no direct reports and no authority over the engineers whose work they sequence. And product decisions belong to product: a TPM who starts deciding what ships has taken a job they were not given and lost the neutrality that let them broker between teams.
The word "technical" carries real weight. A program manager who cannot read a design document is dependent on being told the truth about progress, which means they find out about a problem when it has become a slip. A TPM who can read one notices that two teams have agreed on an interface in words but not in behaviour, that a milestone described as complete has never been exercised against a real consumer, or that an estimate rests on an assumption nobody has tested. That is a different job, and it is the one being interviewed for.
Now practise it
6 interview questions in Technical Program Management, each with the rubric the interviewer is scoring against.
This section has two subsections, and they divide the discipline along a real seam: one is about the schedule and the people who care about it, the other is about the system and what will break in it.
Program Delivery
Program delivery covers slippage, critical paths, and the communication that surrounds both. It is the operational half of the role and the half that runs every week: recalculating the path when a dependency moves, working out whether downstream float absorbs any of it, finding the shared constraint two teams are actually competing over, and telling a VP that a date has changed in a way that leaves you more trusted rather than less.
The questions in this subsection are mostly scenarios, because that is how the skill is examined. A dependency slips three weeks and you have to establish and communicate a new date. Two team leads have each dug in on going first and neither reports to you. Every workstream reports green and you are fairly sure the program will miss anyway — the status-aggregation trap, which is the single most characteristic failure mode in the discipline, because the work between teams belongs to nobody's status report and the date lives in exactly that gap.
What ties these together is that none of them has a procedural answer. Each is graded on whether you gather evidence before diagnosing, whether you arrive with a recommendation rather than a problem, and whether you fix the mechanism that let the surprise arrive rather than only the surprise.
Technical Risk Management
Technical risk management covers identifying architectural bottlenecks and resource constraints, and then converting them into something an organisation can make a decision about. It is the half of the role that pays for itself over quarters rather than weeks, and the half that most clearly requires the technical part of the title.
The characteristic problem here is not finding risks — engineers usually know them — but that a risk everyone knows and nobody owns has no trigger, no measure and no date, so it cannot be escalated and never is. Converting "it will not scale" into "peak writes are at 62 percent of the measured ceiling, growing 9 percent a quarter, review at 80 percent, owner named" is the work, and it does not require you to be the deepest engineer in the room. It requires you to keep asking for the dimension, the measure and the date until the answer stops being an adjective.
The second recurring problem is pricing. Technical risk loses to feature value at steering committees not because executives are short-termist but because it usually arrives without a cost attached, and an unpriced cost loses to a priced benefit every time. The questions here cover putting both in one currency with the arithmetic exposed. The third is concentration: a single expert or a single environment that four workstreams queue behind, which behaves like a queueing problem long before it behaves like a knowledge problem.
Subsection
What it is for
The question it answers
Program Delivery
Keeping a multi-team commitment on a date, and communicating when it moves
Given that something slipped, what is the real new date and who needs to decide what
Technical Risk Management
Finding what will break the program before it does, and getting it decided
Given a technical constraint engineers can see, how does it become a funded decision
Where it sits in a real organisation
A program starts with a commitment made above the level of any single team: a launch date given to customers, a regulatory obligation with a fixed deadline, a platform migration that has to complete before a contract renews. Someone senior owns that commitment. The teams that will deliver it report through two, three or four different managers, each with their own roadmap, and each of those roadmaps had a plan before your program existed.
The TPM's position in that structure is lateral. You sit across the teams rather than above them, which means the flow you manage is information and decisions rather than instructions.
Loading diagram…
The node worth staring at is the one labelled work between teams. It has three arrows into it and no team name in front of it, and that is the whole geometry of the role: the riskiest part of a program is structurally unowned, and a TPM is the person whose job description makes it theirs.
Follow a single slip through the organisation and the mechanics become concrete. A platform team tells you on a Tuesday that their API will be three weeks late. Nothing has visibly changed for anyone else yet. Over the next two days you re-derive the critical path with the slip inserted and discover that downstream float in the mobile workstream absorbs six days, so the program moves fifteen working days rather than the full three weeks — but the same slip has consumed the entire float on the data-migration path, which is now critical too and has not been watched closely by anyone. You now have a smaller date change and a materially riskier program, which are two separate findings that have to be reported together.
Loading diagram…
The interesting gap in that sequence is between the third and fourth messages. The recalculation is the work, it happens alone, and it is the reason the conversation with the VP is a decision rather than an escalation. A TPM who forwards the platform team's message upward has done none of it.
Where a program sits also determines what the TPM can and cannot move. Scope belongs to product. Resource belongs to engineering leadership. The date is derived from both rather than chosen. What the role genuinely owns is the visibility of the trade between the three — that changing one is never allowed to happen silently, and that the arithmetic is on the table at the moment of the decision rather than discovered a quarter later.
Who does this work
The title is most consistently used in large technology companies and in any organisation running multi-team engineering programs, though the naming varies. Technical program manager is the common form; program manager, delivery manager, engineering programme lead and occasionally chief of staff to engineering describe overlapping work with different emphases. The pattern worth knowing is that "delivery manager" and "programme manager" in enterprise and consulting settings often carry more process administration and less technical content, while "TPM" in a product engineering organisation carries more of the technical half.
A week looks less like planning than newcomers expect. Perhaps a fifth of it is genuine plan maintenance and reporting. The rest is conversations: a dependency review where two leads state a date and its cost, a design discussion you attend to hear what is unresolved rather than to contribute, a standup where you notice something said in passing that nobody has written down, a fifteen-minute call to unstick a decision that has been sitting for a week, and the writing — an escalation, a status update, a decision record.
Role
What they own
How they differ from a TPM
Engineering manager
People, technical quality, how work gets done inside one team
Has authority over engineers; owns one team's output, not the cross-team outcome
Product manager
What gets built and why, scope, customer value
Owns the what; a TPM owns the how-and-when across teams
Project manager
A defined scope delivered to a plan
The plan is largely the deliverable; a TPM's deliverable is a decision rate
Scrum master
One team's process and its impediments
Bounded inside a team and its ceremonies rather than between teams
Chief of staff
An executive's priorities, operating cadence, communications
Serves a person and their org; a TPM serves an outcome and its teams
People arrive in the role from several directions. Engineers who found they were better at unblocking six people than at writing code themselves, and who kept the technical judgement. Project and delivery managers who deliberately built technical depth. Product managers who preferred the delivery half of their job. Consultants and QA leads, occasionally. The two backgrounds that struggle in interviews are almost mirror images: engineers who cannot yet resist solving the technical problem in front of a lead who owns it, and delivery managers whose technical vocabulary is fluent but does not survive two follow-up questions.
Seniority in the discipline scales with the blast radius of what you coordinate rather than with headcount, since there is rarely any headcount. A mid-level TPM runs one program across two or three teams. A senior one runs a program spanning organisational boundaries where the teams have genuinely competing incentives. At staff and principal level the work becomes designing how programs are run at all — the reporting mechanisms, the escalation paths, the readiness criteria — which is the part that changes outcomes across many programs rather than one.
Demand, adoption and how that is changing
Demand is high and structurally durable, but it is not uniform across the things the title has historically covered, and the honest picture is that the role is bifurcating.
The reason demand exists at all is that the coordination problem gets worse as an engineering organisation grows, and it gets worse faster than linearly. Two teams have one interface between them; six teams have fifteen possible pairs. Microservice architectures, platform teams with many internal customers, and the general move to smaller independently deployed units all multiply the number of joins, and each join is a place where two groups can agree in words and diverge in behaviour. Nothing on the horizon reduces that count.
The part of the role that is under pressure is the administrative half. Maintaining a plan, chasing task-level status, and assembling a deck out of six teams' updates are all activities that tooling has been eating steadily and that automation continues to eat. An organisation that hires a TPM to produce a weekly roll-up is buying something it will eventually stop buying, and roles defined that way are the ones that disappear in a reorganisation.
The part that is growing is the judgement half: deciding what evidence makes a milestone real, noticing that a green roll-up is silent about the integration nobody owns, converting an architectural worry into a priced decision, and telling a VP something they do not want to hear in a way that leaves you more credible. None of that compresses into a template, which is exactly why it holds its value. The practical consequence for anyone entering the field is that depth in the technical and risk half of the discipline is where the durable career is, and fluency in reporting tooling is table stakes rather than a differentiator.
Regulation adds a floor in some sectors. Financial services, healthcare and anything touching data-protection obligations generate programs with externally fixed dates and mandatory evidence trails, and those programs cannot be run informally. That is a source of demand that does not depend on a hiring cycle.
What makes it hard
The difficulty is not volume, and candidates who describe the job as "a lot to keep track of" have identified the easiest part of it. There are four genuine difficulties.
The first is that you have no authority and every commitment you depend on was given voluntarily. This inverts how influence works. You cannot instruct, so you operate through information, sequencing and reciprocity: making it obvious to a team what their slip costs someone else, giving them something in return for what you need, and making a trade visible to the one person who owns both sides. All of that runs on credibility, and credibility here is a measurable thing — whether your dependency dates have been right, whether your escalations were necessary, whether your status was honest. It accumulates slowly and one unnecessary escalation spends a lot of it.
The second is that the signal you receive is systematically optimistic, and not because anyone is lying. Status colours carry consequences: in most organisations an amber triggers a review meeting, a recovery plan and a director's questions, all of which cost a lead a day they would rather spend delivering. Rounding a marginal amber to green is individually rational, especially if the lead thinks they can recover quietly. Meanwhile each lead reports against their own scope, which excludes the work between teams. Both effects push the same way, which is why a program can be green for months and go red in one week. You cannot fix this by asking people to be more honest. It is fixed by making amber cheap and by measuring status against evidence rather than assertion.
The third is that the technical judgement required is real but cannot be exercised directly. You have to know enough to tell a resolved design decision from an unresolved one, and to challenge an estimate on its assumptions rather than its size — and then you have to not use that knowledge to redesign the system, because doing so once in front of a tech lead permanently changes what they tell you. Holding technical opinions while deferring technical decisions is genuinely difficult and it is the thing experience is least substitutable for.
The fourth is that success is invisible and failure is not. A program that ran well looks, from outside, like a program that was never in trouble, and the absence of a crisis is not an artefact anyone can point at. Failure, conversely, is highly legible. This asymmetry is the honest reason some very good practitioners leave the discipline, and it is worth knowing about before you choose it.
Why study it
Study it if you find the coordination problem interesting in itself — if you would rather be the person who noticed in week three that two teams had different mental models of the same schema than the person who wrote either implementation. That is a genuine preference, it is not a lesser one, and people who have it tend to be unusually good at this work.
It is also worth studying for its transferability. The skills are portable across domains in a way that framework expertise is not: dependency management, risk quantification, and communicating a date change upward work the same way in payments as in medical devices. And the vantage point is unusual. A TPM sees how decisions actually get made in an organisation, which is one of the better preparations for engineering leadership, product leadership, or a chief-of-staff track.
Do not study it if what you want is technical depth. The role trades depth for breadth, and after three years you will know how eight systems fit together and be unable to write production code in any of them. That trade is irreversible enough that it is worth making deliberately. Do not study it because it looks like a route into management, either, because in most organisations it is a route into a different individual-contributor track with no direct reports at any level. And if you dislike ambiguity or need frequent unambiguous confirmation that you did well, this is a poor fit: the feedback loop is weeks long, second-hand, and biased against you by the invisibility problem above.
There is one more honest reason to study it even if you never take the title, which is that engineers who understand dependency and risk mechanics are disproportionately effective. Knowing that adding people to work off the critical path changes nothing, or that a milestone without exit criteria will be declared complete by whoever is under most pressure, makes you better at your own job.
Your first hour
Take a real piece of work you already know — something that involved at least two teams, finished or not — and produce two artefacts on one page. No tooling beyond a text file.
First, list six to ten tasks with a duration and what each depends on, then enumerate the paths through them and add up each one. The longest path is the shortest possible duration, and it is almost never the sum of anything. Then compute the float on the tasks that are not on it: how many days each could slip before it delays something downstream. If you do nothing else in this hour, do this, because the difference between people who use the words critical path and float loosely and people who can produce the arithmetic is the difference the interview is looking for.
Second, take one technical risk you know exists in that work and write it as a register row with five fields: the statement, the trigger, the current reading of whatever the trigger measures, the impact in cost or a missed commitment, and a named human owner. You will find that the trigger and the current reading are the hard ones, and that finding them requires a conversation rather than a document. That difficulty is the actual work of technical risk management, compressed into ten minutes.
The artefact at the end is a page with a number on it — the program duration you derived — and a risk that has a threshold instead of an adjective. Both are things you can put in front of an interviewer, and both are things most candidates have never done on paper.
What this is not
It is not project administration. Keeping a plan updated and producing a status pack is the part of the job with the least leverage and the shortest remaining shelf life, and a candidate who describes the role in those terms is describing the part being automated.
It is not engineering management. There are no direct reports, no performance conversations, and no authority over who works on what. A TPM raises a symptom and its delivery consequence; the engineering manager chooses the remedy inside their team. Blurring that line loses you the neutrality the role depends on.
It is not product management. Deciding what ships, and for whom, and why, is a different accountability with different evidence. A TPM who starts making scope calls has quietly taken product's job and will be resented for it by exactly the people they need.
It is not Scrum at a larger size. Agile-at-scale frameworks describe a cadence and a set of ceremonies; a program is a set of interfaces and constraints, and a program plan that looks like one very large sprint plan is usually a sign nobody has identified the joins. The ceremonies are a delivery mechanism for the work, not the work.
And it is not a role where the answer is a template. The most common preparation mistake is memorising a framework and applying it to whatever scenario appears. Interviewers present deliberately underspecified situations precisely to see whether you ask what makes this one different before you propose anything, and a candidate who reaches for a process without asking about the nature of the date, the ownership of the dependency, or what evidence exists has already told them what they wanted to know.
The riskiest work in any program is the work between teams, which no team's status report contains and no team's backlog holds, and making that work visible and owned is the whole of the job.