What a Technical Program Manager actually does

There is a particular moment when I meet someone new and they ask what I do for a living.

“I’m a Technical Program Manager.”

You can usually see the follow-up question forming before I’ve finished the sentence.

“Cool. What is a Technical Program Manager?”

If I explain it using words like alignment, execution, stakeholders and cross-functional delivery, their eyes just glaze over. If I say I work with engineers but I’m not an engineer - and that I work on delivery but I’m not quite a producer or project manager - I haven’t exactly cleared things up. Sometimes, I might just say "it's like a technical project manager" and leave it there - but that doesn't feel quite right either.

The difficulty is that Technical Program Manager (TPM) work often sits in the gaps between well-understood jobs. Those gaps are also where some of the most expensive problems begin.

First, what a TPM is not

A TPM is not simply a scrum master, a project tracker with a fancier title, or the person responsible for making sure meetings happen.

Those activities might appear in the job. There may be plans to maintain, meetings to run and actions to chase. However, treating those things as the role is a bit like describing software engineering as typing.

The useful part of the job is not recording that a problem exists. It is understanding the technical and organisational system well enough to spot why the problem exists, who can change it and what needs to happen next.

A TPM finds the gaps between teams

Imagine two engineering teams working toward the same release.

One team owns the build. The other owns the platform integration. Both teams might believe the other is responsible for a certification step. However, when you look at it on separate project plans, everything might look green and on track because neither plan contains a task that appears late.

That's until the project reaches a point where it stops due to no one owning the certification step. The problem isn't that somebody forgot to update a project plan. It's that ownership was never made explicit across the boundary between the teams.

This is where a TPM comes in. They should find that gap before it becomes a release-blocking surprise. That means asking questions that can feel almost annoyingly specific:

• Who owns this step?
• What input do they need?
• When will they receive it?
• What happens if it is late?
• Has the receiving team agreed to the date?
• Is this dependency visible in both teams’ plans, or only assumed in conversation?

None of those questions is technically sophisticated on its own. The skill is knowing where to ask them, understanding the answers and noticing when two reasonable answers do not fit together.

A TPM translates risk into a decision

Technical teams are great at describing technical problems. They might explain that code isn't performant, or a build pipeline has become unreliable, or even that an integration that depends on an API that is still changing.

That does not automatically produce action.

“This code isn't hitting performance targets” may be accurate, but it leaves a senior leader with several unanswered questions. What could it delay? When do we need to decide? What are the options? What does each option cost? Is this something the team can absorb, or does it threaten a committed milestone?

A TPM turns the technical risk into a decision that someone can make:

If the code isn't hitting performance targets by Friday, the integration team will lose its final test window. We can reduce the launch scope now, add engineering support to the team, or accept a likely delay. We need a decision by Wednesday because each option changes next week’s plan.

The TPM has not replaced the engineer’s judgment. They have preserved it, added the missing programme context and made the consequence difficult to ignore.

This works in both directions. Leadership needs a clear account of the risk, while engineers need decisions that are precise enough to act on. “Please prioritise this” is not a useful decision if nobody has said what should move out of the way.

My job has two parts: reactive and proactive

I tend to think of my job as having two parts. One is reactive - responding to problems as they happen. The other is proactive - helping teams prepare for what is coming before it becomes a problem.

An example of the reactive work might be a critical bug passed my way because it crosses team boundaries, needs more investigation, or requires the right people to be pulled in quickly. I might dig into the issue myself, help establish who owns it, or escalate it when the impact or urgency is not yet visible to the people who can act.

The proactive side is quieter but just as important. I spend time educating developers and teams about upcoming features, useful new tools, and changes that could affect how they work. This could take the form of building developer communities, hosting monthly meetings or even larger multi-day Summits.

This could be anything from introducing people to something new that saves them time, to helping them prepare for an upcoming deprecation, or simply making sure they're aware that a tool or service is nearing the end of its supported lifecycle.

If this is done early, it gives teams time to understand the change and plan around it. If it's done late, the same change arrives as another urgent problem.

The two parts reinforce each other. Reactive work shows me where teams are missing context or where ownership is unclear. Proactive work lets me use that knowledge to prevent the same kind of surprise from happening again.

The technical part matters

The word “technical” is not decorative.

A Technical Program Manager does not need to be the strongest engineer in the room, but they do need enough technical depth to ask useful questions and understand why a proposed shortcut may create problems elsewhere.

Without that technical grounding, it is easy to reduce the work to progress reviews. The TPM becomes a messenger carrying updates between people who already understand the problem better.

With that context, I try to help connect the dots across teams. They can see how a technical decision in one area might create a schedule risk somewhere else, or recognise that what looks like a delivery issue is actually an ownership, architecture, or decision-making challenge.

The value is not knowing everything. It is being able to find the right detail and keep the programme-level consequence in view.

So, what does a TPM actually do?

A TPM helps teams deliver complex technical work with fewer surprises. They connect the dots across teams, expose hidden dependencies, and help keep work moving.

Project plans and meetings are all tools for doing that but that is not the job itself. The exact shape of a Technical Program Managers' role varies enormously between companies - and sometimes between teams in the same company. If you are a TPM, Program Manager, Producer or Engineering Leader, I’d be interested to hear your thoughts!