What a Technical Program Manager Really Does
What a Technical Program Manager Really Does
I’ve been a Technical Program Manager for nearly two decades, across Amazon, Microsoft, Salesforce, and SentinelOne. And I still get asked whether I “manage projects” or “write code.”
The role is widely misunderstood, so it’s worth being precise about what a TPM actually does.
A Technical Program Manager owns the how and the when of complex technical work. At senior levels, TPMs also influence the what by surfacing constraints, sequencing trade-offs, and execution risk that materially shape product decisions. Product managers decide what should be built. Engineers decide how to build it. A TPM is responsible for everything that has to exist between those decisions for work to actually ship. This includes the operating rhythm, dependency clarity, decision paths, and escalation mechanisms when things inevitably go sideways.
At its core, the job is simple to describe and hard to do. A TPM takes ambiguity, pressure, and competing priorities and turns them into a system people can execute against.
When a critical integration keeps slipping and no one owns the dependency.
When six teams need to land a coordinated release.
When an acquisition forces two engineering cultures to operate as one.
When a nine-figure R&D portfolio needs guardrails, visibility, and real accountability.
That’s TPM territory.
What the Best TPMs Have in Common
They build systems, not just plans
Anyone can keep a project tracker up to date. Strong TPMs design the mechanisms that outlive any single program. These include planning cadences, governance forums, dependency models, and decision frameworks.
In some organizations, this work extends beyond individual programs into designing or stabilizing operating frameworks such as NPI, EOL, or portfolio governance when those systems do not yet exist or no longer scale. This is not always the TPM’s formal responsibility, but execution breaks without it.
The impact of this work compounds over time because it shapes how the organization operates, not just how one initiative lands.
They translate without losing meaning
Engineering speaks in constraints and trade-offs. Sales speaks in commitments and timelines. Finance speaks in headcount, burn, and ROI. A great TPM moves fluently between these worlds, not by simplifying the truth, but by preserving what matters and stripping away what does not.
Friction does not disappear, but it becomes productive instead of paralyzing.
They make decisions possible
Not by making the decision themselves, but by creating the conditions for good decisions to happen. Clear options. Real trade-offs. The right data, at the right altitude, at the right moment.
When leadership says “yes” or “no,” it is because the path has been made clear. That is deliberate. The irony is that when this works well, it looks effortless. The credit flows to the teams who shipped. The friction that was absorbed upstream stays invisible.
What a TPM Is Not
A TPM is not a project manager with a shinier title. Project management focuses on tracking work. TPM work focuses on designing how work flows through an organization.
A TPM is not an engineer who got tired of coding. The role requires technical fluency, not technical ownership. You need enough depth to challenge assumptions, spot risk, and call out unrealistic plans, without needing to write the code yourself.
And a TPM is not a meeting scheduler. If your calendar is full but nothing is shipping, something is broken. Meetings are a tool, not the output.
I wrote this because the TPM role still gets reduced to “the person who schedules meetings” or “the engineer who stopped coding.” It’s neither.
And as AI reshapes how products get built, the need for TPMs who can operate at this level continues to grow. This includes designing execution systems, governing ambiguity, and translating across increasingly complex domains.
In upcoming articles, I’ll explore what that looks like in practice. That includes building AI fluency as a TPM, designing operating systems that let R&D organizations ship complex products repeatedly, and navigating the boundary between research and production.
More soon.