Redefining TPM Practice for the AI Era

Most TPM organizations are still optimized for a world that no longer exists. Rebuilding the practice for the AI era means three deliberate shifts: from manual tracking to automation, from reporting to decision enablement, and from coordination to execution leverage.

I have spent two decades building and leading TPM organizations at Google, Nest, and now at the Chan Zuckerberg Biohub. Every one of those organizations was designed around a set of assumptions: that status has to be assembled by hand, that a program manager's value is measured by the freshness of a report, and that the job is to keep people synchronized. AI breaks all three assumptions at once. The practice has to be redesigned, not patched.

Shift one: from manual tracking to automation

For most of TPM history, tracking was the job: pulling status from a dozen owners, reconciling conflicting inputs, updating the spreadsheet or tracker by hand, chasing the update nobody sent. That work consumed enormous capacity and produced almost no leverage, because a tracker that is accurate on Tuesday is stale by Thursday.

AI now does this better than any human could: ingesting commits, tickets, eval runs, and calendar signals directly, and surfacing status without anyone narrating it. The TPM's job shifts from producer of the tracker to architect of the system that keeps it honest: deciding what signals matter, where automated status can be trusted, and where it cannot. A model eval score is a fact a system can report. Whether that score means the launch should slip is a judgment call, and judgment is where the TPM's time now belongs.

Organizations that keep their best people hand-assembling status decks in 2026 are burning their most valuable capacity on the one function that was always fully automatable.

Real-time visibility, engineered not narrated

The automation shift has a concrete architecture behind it: dashboards powered by agentic workflows that pull status, risk, and dependency signals directly from the systems where the work happens, rather than from a person's memory of the last standup. At the Biohub, that means agents that watch training runs, evaluation pipelines, and GPU cluster utilization continuously, and surface deviations the moment they occur instead of at the next scheduled sync.

The design goal is not a prettier dashboard. It is closing the gap between when something changes and when the people who need to know find out, without adding a reporting tax on the teams doing the work. Three things have to be true for that gap to close: status has to update itself from source systems, risks have to surface before anyone asks about them, and dependencies have to be visible across team boundaries, not just within them.

Status. Agentic workflows read commits, tickets, eval results, and pipeline logs directly and turn them into plain-language state, not a percentage complete. A dashboard that reads "eval regression on the checkpoint, unresolved for 36 hours" is worth more than one that reads "72% complete."

Risks. The same systems that report status can be tuned to flag anomalies against expected patterns: a GPU allocation that silently shrank, a dependency feed that stopped updating, a milestone whose owner has gone quiet. Surfacing the anomaly early is the whole point; a risk caught in week two is a design input, and the same risk caught in week ten is a crisis.

Dependencies. Cross-team dependencies are where programs quietly fail, because no single owner is incentivized to track a handoff that lives between two teams. An automated dependency graph that updates itself removes the need for anyone to hold that map in their head, and makes the handoff visible to both sides at once.

None of this replaces judgment. It removes the excuse for not having the facts before judgment is needed, which is exactly the point: a TPM spending time compiling status they could have gotten from a dashboard is a TPM not spending time on the decision that status was supposed to inform.

Shift two: from reporting to decision enablement

Reporting answers "what happened." Decision enablement answers "what should we do next," and it requires a fundamentally different posture: showing up before the decision, not after the fact, with the tradeoffs already framed.

In hardware launches, this meant naming the ship-date owner for every irreversible risk before the risk materialized, not documenting it once it had. In AI research, it means the same discipline applied to a new class of irreversible decisions: which training run to fund, which safety threshold to hold, which eval result to trust when the benchmark and the qualitative read disagree. A status report describes the past. A decision brief changes the future, and building the habit of producing the second instead of the first is the single highest-leverage change a TPM organization can make.

A tracker tells you where the work stands. A decision brief tells you what to do about it. Only one of those is the job.

This also changes what "on time" looks like for a TPM. Being on time now means having the decision framed and the options costed before the meeting where the decision gets made, not summarizing what was decided after the fact.

Shift three: from coordination to execution leverage

Coordination scales linearly: more teams means more syncs, more handoffs, more meetings to keep everyone aligned. Execution leverage scales differently, because it comes from redesigning the system so fewer syncs are needed in the first place: clearer decision rights, cleaner interfaces between teams, feedback loops that catch problems before they need a meeting to surface.

The test I use is simple: when the TPM is out for a week, does the program slow down? If it does, the TPM has been a coordination bottleneck, however well-intentioned. If it does not, the TPM has built execution leverage: a decision-rights architecture that determines what requires a person and what can run without one, and feedback loops that improve team performance without their constant presence. That is the systems-architect version of the role, and it is the only version that scales past a handful of programs.

Execution leverage also means extending AI into that architecture rather than treating it as a threat to route around. The organizations pulling ahead are the ones where the TPM decides how human judgment, AI output, onshore capacity, and offshore execution combine into measurable results, and then builds the system that makes that combination repeatable.

What this requires

None of these shifts happen by asking TPMs to work harder at the old job. They require redesigning what the job is: retiring manual status rituals deliberately rather than letting them survive out of habit, measuring TPMs on decisions influenced and risks retired rather than on tracker hygiene, and rewarding the people who make themselves structurally unnecessary to daily coordination because they built something that runs without them.

The organizations that make this shift first will not just move faster. They will free their most capable people to do the one part of the job AI still cannot: hold the judgment at the seams, know which clock each discipline runs on, and decide what the organization does next.