What Do TPMs Do, and Are They Going Away?

Ask someone what an Engineering Manager does. Clear answer. Ask what a Product Manager does. Clear answer. Ask what a Technical Program Manager does, or an EPM, PrgM, Program Leader, or whichever title the company uses, and you will get something vague about coordination and keeping things on schedule.

That makes the AI question sound straightforward. If AI can coordinate, track, synthesize, and increasingly execute the work, what is left for the TPM?

The coordination-heavy version of the role is going away. The program function is not.

TPMs do not exist to coordinate work. They exist to drive programs: the important cross-functional outcomes an organization must pursue across multiple teams, deliverables, and iterations. Coordination is simply the overhead that accumulated around that responsibility.

AI removes more of that overhead. What remains is the actual job: setting direction, sensing when reality has diverged from the plan, resolving the tradeoffs no function owns, and remaining accountable for the result.

The P stands for Program. Or Project. Or Product, depending on who is hiring. Whatever the title, the underlying structure is the same: responsibility for an outcome without direct ownership of every team required to produce it.

That function was historically visible only at scale. Google, Amazon, Microsoft, Meta, and Apple built dedicated program organizations because they had to. Most companies never reached enough cross-functional complexity to name the work clearly.

Agentic execution changes that.

Where TPM Came From

Technical Program Management did not start as a job title. It started as a function: the function of keeping large, complex, multi-team technical efforts coherent. For most of software's history, that function was invisible because it had no name.

At 10 people, a founder held the picture. At 80, a senior engineer did it alongside everything else. The work was real: sequencing, dependencies, alignment, the call about when to push and when to cut. But it lived inside other roles, absorbed into whoever had enough context to see the whole. It was unglamorous and largely unacknowledged, which is why when it finally got a title, people assumed the title was new and therefore optional.

It isn't. Program management at scale is as old as complex human coordination. NASA ran it on Apollo before there was a software industry. The semiconductor fabs that built the chips your AI runs on have been running it for decades. Intel's Copy Exactly! methodology, first formalized in the 1980s, is a direct example: a long-running, multi-site program for replicating manufacturing processes with zero deviation. The function predates the title by a long time. The title just made it visible.

What a Program Actually Is

A lot of people, even inside highly technical organizations that run programs at scale, have never had to define exactly what a program is. That is the source of most of the dysfunction.

A program is not a project. A project is time-bounded: it has a start, a deliverable, and an end. When it ships, it's done. A program is different. A program is a sustained commitment to an outcome that spans multiple deliverables, teams, functions, and iterations. It ends only when the outcome has been achieved or no longer matters.

Enterprise readiness is a program. Discoverability is a program. Platform reliability is a program.

The same structure runs across industries, functions, and eras:

None of them end when any single thing ships. They are ongoing organizational commitments to a category of outcome that the company, agency, or community decided it can't afford to let drift.

The distinction matters because it changes what ownership means. Owning a project means getting something shipped. Owning a program means keeping an outcome healthy over time, which is a fundamentally different kind of responsibility.

Programs are goals made operational. And goals, by definition, don't go away when AI gets faster at executing against them.

Not Coordinating. Driving.

The confusion around TPM comes from what the work looks like at scale. When programs span multiple teams and functions, the coordination overhead becomes heavy and visible: the meetings, the dependencies, the status synthesis. People see the coordination and assume that is the job. Every managerial role carries coordination overhead. It is heaviest in TPM because programs are inherently cross-functional. The coordination comes with the territory.

As AI absorbs more of the coordination, what remains is driving. It has three parts.

Setting and holding direction. Every program starts with an intended outcome. The job is to turn that outcome into a plan the organization can execute, build real commitment around it, and keep adapting as constraints shift, priorities change, and new information arrives. Scope expands. Dependencies slip. What success looks like at the start of a quarter is often not what it looks like at the end. Holding direction through all of it: knowing when to absorb the change, when to renegotiate scope, when to escalate, and when to reset expectations entirely. That is not coordination. It is judgment applied continuously to a moving target.

Sensing reality. Every program has two versions: what the system of record shows and what is actually happening.

The dependency is marked green because the API contract was delivered. In the working session, the consuming team is still asking the same questions it asked last week. The owner keeps saying, "We should be able to," but nobody will commit to a test date.

The handoff is complete on paper. In practice, no one trusts it enough to build against.

The status report says scope is unchanged. But the Product Manager has started calling one committed requirement "phase two," the Engineering Manager goes quiet whenever the launch date comes up, and the same decision has been deferred across three meetings.

None of those signals is an incident yet. That is the point. Catching the gap before the system does is the difference between steering and reacting.

Keeping things moving. Programs stall on decisions nobody is forcing. The right information exists somewhere in the organization, but the people who need to act on it are not in the same room. The job is to bring the real decision to the right stakeholders, surface the tradeoffs they are actually choosing between, and turn the outcome into a commitment the organization can execute. When a platform dependency slips two weeks, the question is not whether it slipped. It is whether to absorb the delay, cut scope, or reset with the customer. That answer depends on context outside the dependency graph: the sales relationship, the release window, the political dynamics between two teams that the tracker has no column for. That call has to belong to a person.

Programs Become First-Class Citizens

As agents take over the working plane, the human job moves up a layer. People spend less time producing each unit of work themselves and more time directing an important outcome end to end, including the performance of the agentic execution underneath it.

That changes the natural unit of work. Engineering, product, design, marketing, and legal are vertical functions. Programs are horizontal goals that require several of those functions to work together.

Each row is a goal. The organization succeeds or fails based on the result of the row, but most companies divide accountability across the columns.

The organizations that win will make those horizontal goals first-class citizens. One person will own the goal from definition through execution, adaptation, and result, even when the work crosses several functions.

That reorients how individuals define their work. A developer whose goal is "ship feature X this quarter" is optimizing for a functional deliverable. A developer whose goal is "make us competitive in enterprise readiness" is optimizing for an organizational outcome that compounds across every function it touches.

As execution capacity becomes cheaper, this distinction becomes more important. An organization can complete more tasks than ever while still failing to advance its most important goals.

This is what a program engineering org looks like at scale. TPMs, Engineering Managers, Product Managers, and engineers each own specific programs and run them. Not as a support layer. As the primary unit of accountability. The org chart still exists, but the real structure is the program map.

Apple Silicon is the clearest example. The transition was not merely a chip project, an operating-system project, or a Mac project. It was one named program with a clear outcome and a multiyear horizon, spanning chip design, hardware, macOS, developer tools, and the entire Mac lineup.

The success of the transition depended on the result as a whole, not on whether each function completed its work independently. Programs become first-class citizens when accountability follows the goal, not the org chart.

The Human Layer of Program Steering

Every organizational function gets augmented, including this one. Engineers get coding agents. Product Managers get research and synthesis agents. Technical Program Managers get status synthesis, dependency analysis, decision reconstruction, and AI-generated risk surfaces.

The coordination mechanics that once consumed the role increasingly disappear into the infrastructure.

What remains is accountability.

An agent can detect that two teams disagree about scope. It can retrieve the history of that disagreement, model the options, estimate the consequences, and recommend a path. What it cannot do is assume organizational accountability for choosing the goal, making the tradeoff, or accepting the consequences if the choice is wrong.

Accountability is not a limit of machine intelligence. It is a property of how human organizations assign authority and responsibility.

Someone must decide that reliability matters more than the date. Someone must reset the customer commitment. Someone must move one team's priority behind another. Someone must own whether the collective decisions still add up to the intended result.

AI can participate in judgment. Accountability still has to belong to someone.

Programs Compound Your Edge

A project produces a deliverable. A program produces deliverables while accumulating the knowledge required to produce better ones.

Because a program persists across multiple executions, every run can leave something behind: a better process, a clearer standard, a decision precedent, stronger cross-functional relationships, a more accurate model of what success requires. In an AI-native organization, that accumulation includes reusable workflows, evaluation systems, agents, prompts, and program-specific infrastructure.

Each execution deposits into the next.

Apple's privacy work illustrates what this looks like in practice. Privacy at Apple is not a feature or a release. It is a sustained commitment expressed across a series of technologies and product decisions: the Secure Enclave, differential privacy, App Tracking Transparency, Private Relay, on-device machine learning.

Each technology involved recurring decisions that became standards. What counts as a privacy violation? Where is the line between useful telemetry and surveillance? What information can leave the device? What review must a new feature pass before launch? Each time those questions were resolved, the answers propagated into the next specification, the next engineering checklist, the next vendor evaluation, the next launch review.

Over time, the program encodes what the organization actually believes into how the organization actually works.

Historically that knowledge stayed trapped in the memories of the people who drove the decisions. When those people moved on, teams reconstructed context and reopened old debates from scratch.

Making that knowledge explicit and reusable for both humans and agents is what separates organizations that compound from organizations that restart.

So the question is not whether the TPM role survives AI.

The question is how companies will scale the program function across humans and agents, so decisions can keep pace with execution.

In an AI-native organization, program management does not disappear. It becomes how the company scales.