TPM Is a Leadership Discipline, Not a Support Function
People think program management is overhead: status decks, trackers, calendar Tetris. Twenty years of shipping have taught me it's closer to the opposite.
Ask people what a TPM does and you'll often hear a list of artifacts: schedules, trackers, status reports, launch checklists. Those things exist, and they matter. But defining TPMs by their artifacts is like defining engineers by their keyboards. The artifacts make the work visible. They are not the work.
The work is judgment. A strong TPM is often the only person in the room who holds the entire system in their head: the technical dependencies, the org dynamics, the customer commitments, the risks nobody has said out loud yet. That vantage point is a leadership position, whether or not the org chart says so.
The three levels of TPM maturity
In building and leading TPM teams — a 25-person organization for Wear OS and Pixel Watch at Google, and now the AI research programs at the Chan Zuckerberg Biohub — I've watched program managers grow through three distinct levels.
Level one is tracking. You know where the work stands, and you can tell people accurately. This is table stakes, and it's where the "support function" stereotype comes from — because if you stop here, the stereotype is true.
Level two is unblocking. You don't just report that a dependency slipped; you saw it coming three weeks ago, escalated with a proposed trade-off, and had a mitigation already socialized. At this level, you're changing outcomes, not describing them.
Level three is shaping. You influence what the organization chooses to build and in what order. You bring execution reality into planning conversations early enough that strategy is actually executable. Leadership stops inviting you to meetings out of politeness and starts refusing to make decisions without you.
A tracker can tell you where the work is. It can't tell you whether it's the right work.
What this means if you lead TPMs
If you manage a TPM organization, your job is to build the conditions for level three. Staff your TPMs onto problems, not meetings. Get them a seat in planning, not just execution. Evaluate them on decisions influenced, risks retired, and weeks saved rather than on the tidiness of their trackers.
You will also have to defend the discipline. When budgets tighten, coordination-shaped roles get questioned first. Don't protect headcount reflexively. Make sure every TPM on your team is operating at a level where the question answers itself.
What this means if you are one
Own the outcome, not the process. Learn the technology deeply enough to challenge an estimate credibly. Say the uncomfortable thing early, with data and a proposal attached. And remember that influence compounds: every risk you call correctly buys you trust you can spend on the next hard conversation.
Program management done well is easy to miss while it's happening. You see it in retrospect: teams that shipped calmly, decisions that aged well, ambiguity that kept turning into momentum. If that's a support function, so is steering.