What a TPM does when the chasing stops
Most of a technical program manager's week is spent reconstructing a status that already exists somewhere. Take that away and what is left is the part that was always the job.
A technical program manager I know keeps a spreadsheet that does not appear in any org chart. It has one row per workstream, one column per team, and a colour on each cell. Every Tuesday afternoon she rebuilds it. Not updates. Rebuilds. She opens fourteen direct message threads, asks a version of the same question in each, waits for the replies to trickle in over three hours, cross-references what she is told against the board, notices that four tickets say “in progress” and have said so for eleven days, chases those separately, then paints the cells.
Wednesday morning she presents the spreadsheet. By Wednesday afternoon it is already wrong.
She is very good at this. That is the part worth sitting with. She is not slow, she is not disorganised, she has better judgement about which teams are quietly in trouble than anyone else in the building. And roughly sixty percent of her working week is spent manually reconstructing a state of the world that already exists, in full, in systems she has read access to.
This piece is about what happens to that role when the reconstruction stops being necessary. My short answer is that the job gets harder and considerably more valuable, and that a meaningful number of people currently doing it will not enjoy the transition, because the parts they were best at are the parts that go away first.
The chasing was never the point, but it was doing real work
It is tempting to say status collection is pure overhead and good riddance. That is wrong, and getting it wrong is how organisations remove the chasing and then discover they have broken something they could not name.
Chasing status did four things at once.
It produced a status report. That is the visible output and the one everyone talks about.
It also produced a weekly forcing function. When someone knows they will be asked on Tuesday, they think about their workstream on Monday. The question itself created a small, regular moment of reflection across dozens of people who would otherwise not have had one.
It produced a relationship map. A TPM who has asked the same engineer for status forty times knows how that engineer talks when things are fine and how they talk when things are not. The words are nearly identical. The difference is in hesitation, in hedging, in how long the reply takes. That signal is enormously valuable and it is a by-product of repeated low-stakes contact.
And it produced political cover. A number that a human collected and stands behind is treated differently in a steering meeting than a number a system emitted. This is not rational but it is real, and pretending otherwise gets you ignored in the room.
Automate the first thing and you get the report instantly. You also silently delete the other three unless you replace them deliberately. Most teams do not replace them deliberately, then conclude a few months later that automated status “did not work for our culture.” It worked fine. They removed three load-bearing walls and kept the paint.
What changes mechanically
Under an agentic life cycle the raw material of status is not scarce. Branches, pull requests, reviews, merges and deploys are all machine-readable and all definitionally true, because they are the work rather than a description of the work. If a change is merged, it is merged. Nobody’s memory is involved.
So the question “what is the state of workstream four” stops being a research project and becomes a query. The report that took three hours on Tuesday takes no time at all and is current at the moment it is read rather than at the moment it was assembled.
Two things follow, and the second one is the interesting one.
First, the latency of truth collapses. A TPM used to operate on a weekly cadence because that was the fastest they could refresh their model of the world. That cadence then became the planning cadence, the escalation cadence, and eventually the cultural cadence. It was never chosen. It was the sampling rate of a manual process, and the whole organisation calcified around it.
Second, and more disruptively, the scarce resource flips. It used to be information. Now it is interpretation. When you had to fight for every data point, the person who had the data points was valuable by definition. When everyone can see everything, having the data confers nothing. Knowing which three things out of four hundred matter this week is the entire job.
That is a genuinely different skill. Some people who are excellent at the first are excellent at the second. Plenty are not, and the honest thing is to say so out loud rather than to imply that the transition is automatic.
The four things that are left, and they are the hard four
Strip out collection and what remains is not a diminished role. It is a role that consists entirely of the parts people used to say they never had time for.
Deciding what is actually true. Ground truth tells you a pull request merged against a ticket. It does not tell you whether the thing that merged is the thing anyone wanted. Someone has to hold the difference between “the criteria passed” and “the customer problem is solved,” and that gap is where programs die. It is a judgement, it will always be a judgement, and it is now most of the job rather than a thing you get to on Friday if the chasing finished early.
Owning the dependencies nobody declared. Teams do not tell you about the coupling until it hurts. A system can see that two teams touched the same module in the same week. It cannot see that team A is quietly assuming team B will keep an interface stable through Q3 because someone said so in a corridor in March. Surfacing undeclared assumptions before they become incidents is the single highest-leverage thing a program manager does, and it does not automate, because the assumptions are not written anywhere to be read.
Being the person who says the uncomfortable number. A dashboard that says a program will land six weeks late is a dashboard. A person who walks into a room and says “this will land six weeks late and here is the decision I need from you today” is an intervention. Organisations do not act on data. They act on someone credible putting their name next to an interpretation of the data.
Designing the flow, not administering it. If work is generated ten times faster, the constraints move. Review capacity becomes the bottleneck. Environment contention becomes the bottleneck. The one staff engineer who has to approve anything touching auth becomes the bottleneck. Finding the constraint, then changing the system so the constraint moves somewhere less painful, is operations research done on humans, and it is the part of the role with the highest ceiling.
The Tuesday that goes away
- Fourteen DMs asking for status
- Three hours waiting for replies
- Reconciling replies against a stale board
- Painting a spreadsheet
- Presenting a snapshot that is already wrong
The Tuesday that replaces it
- Read the current state in five minutes
- Pick the three anomalies that matter
- Two deep conversations, not fourteen shallow ones
- Name one decision the program needs this week
- Change one thing about how work flows
The anomaly habit
The practical skill that separates TPMs who thrive from TPMs who flounder in this world is what I would call the anomaly habit, and it is learnable.
When everything is visible, the failure mode is not ignorance. It is noise. You can now see every pull request, every merge, every criteria evaluation, every deploy, across nine teams, in real time. That is not insight. That is a firehose, and a person who tries to read all of it becomes slower than they were when they had to ask.
The habit is to stop reading state and start reading deltas against expectation. Not “what is the status of team four” but “what is happening that I would not have predicted.” A workstream that was moving and stopped. A workstream that suddenly accelerated, which is usually worse news than stopping, because it often means scope was quietly cut. A pull request that has been open through three review cycles, which is almost never about the code. A ticket that closed without anything merging against it, which means either the tracker is lying or the work moved somewhere you cannot see.
None of those are status. All of them are questions, and each one leads to a conversation that could not have been had in a round of DMs, because you would not have known to ask.
Stopped moving
Usually a blocked dependency or a person quietly stuck. The most reported and least dangerous signal.
Suddenly accelerated
Often scope was cut without anyone saying so. Faster is not always better news.
Long-lived open review
Rarely about the code. Usually disagreement about approach, or an unowned decision.
Closed with nothing merged
Either the record is wrong or the work is happening somewhere the record cannot see. Both matter.
Rebuilding the walls you knocked out
Back to the three by-products. If you take away the weekly chase, you have to put something in the place of each one, on purpose.
The forcing function is the easiest and the most often forgotten. Something has to make people reflect on their own workstream at a regular interval. A short written note from each team lead, unprompted, is usually enough, and the point is not the note, it is the ten minutes of thinking that producing it requires. Do not let this become a status report by another name. If it can be derived from the system, delete the question.
The relationship map has to be bought deliberately with time you have now freed up. Fewer, longer, less transactional conversations. A TPM who spends two focused hours a week talking to engineers about what worries them will build a better model of program risk than one who spends six hours collecting numbers. The catch is that this looks like idleness on a calendar and requires a manager who understands what they are looking at.
Political cover is the one people underestimate. The instinct is to put the dashboard on the screen and let it speak. It will not speak. Someone has to say “I have looked at this, here is what I think it means, here is what I recommend, and I am the one who is wrong if it is wrong.” The dashboard makes that person faster and better informed. It does not replace them, and a TPM who hides behind the dashboard has traded away the most durable part of their value.
Where this breaks down
I have described a clean transition. The reality is messier in at least four ways, and I would rather name them than let you discover them.
Ground truth is only as good as the coverage. Everything above assumes the work is visible in source control. If a meaningful part of your program happens in a low-code platform, a data warehouse configured through a console, a vendor’s admin panel, or a hardware lab, then the automated picture is not merely incomplete, it is confidently incomplete, which is worse than obviously incomplete. A TPM in that environment still has to chase, and now has the additional burden of remembering which parts of the picture are trustworthy.
Cross-team programs are mostly not technical. The hardest thing in a large program is usually that two directors disagree about priority and neither will say so in writing. No amount of visibility into merges touches that. If your TPM’s actual job is diplomacy, automating status frees up time but changes nothing about the difficulty of the work.
Interpretation is a rarer skill than collection, and the market has not priced it yet. There are people doing this job today who were hired, evaluated and promoted on reliability, thoroughness and follow-through. Those are real virtues and they are exactly the virtues that automate. Telling those people that the job is now pattern recognition, systems thinking and uncomfortable truth-telling in front of executives is a genuine change to the deal, and some of them will reasonably conclude it is not the job they wanted. Pretending this is a costless upgrade for everyone is dishonest.
Speed can make the role worse before it makes it better. When the sampling rate goes from weekly to continuous, the temptation is to intervene continuously. A TPM who reacts to every anomaly in real time will destroy more value than one who reported stale numbers once a week, because they will thrash teams that were fine. The discipline of watching something for two days before acting is much harder when you can see it change hour by hour, and I have seen this failure more often than the ones people worry about in advance.
The takeaway
The chasing was never the job. It was the tax you paid to be allowed to do the job, and everyone knew it, including the people paying it.
What survives is harder: deciding what is true rather than what is reported, surfacing the dependencies nobody wrote down, being the named human who interprets the number in the room, and redesigning the flow when the constraint moves. That is a better role than the one it replaces. It is also a narrower one, in the sense that it rewards a different set of strengths, and organisations that make this shift without saying so plainly will lose good people who never got told the rules had changed.
If you take one thing into next week: stop reading status and start reading deltas against your own expectation. The status is free now. Your expectation is the scarce asset.
The next piece in this series looks at the role sitting immediately upstream of all of this, and at what happens to product management when the specification, not the code, becomes the slowest part of the pipeline.