TPM Is a Leadership Discipline, Not a Support Function
The most persistent misconception about technical program management is that it's overhead — coordination, status decks, calendar Tetris. Two decades of shipping have convinced me of 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 are how the work becomes 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.
The best TPMs are not the people who keep the trains running on time. They're the people who ask whether we're laying track in the right direction.
What this means if you lead TPMs
If you manage a TPM organization, your job is to build the conditions for level three. That means staffing TPMs onto problems, not meetings. It means insisting they have a seat in planning, not just execution. It means evaluating them on outcomes and judgment — decisions influenced, risks retired, weeks saved — rather than on the tidiness of their trackers.
And it means defending the discipline. When budgets tighten, coordination-shaped roles get questioned first. The answer isn't to protect headcount reflexively; it's to 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 invisible in the moment and unmistakable in retrospect — teams that ship calmly, decisions that age well, organizations that turn ambiguity into momentum. That's not support. That's leadership.