Herding Cats Is Not a Job Description. It's a Missing Layer.

Ask a Technical Program Manager what they do, and you will get a job description. Ask them what it actually feels like, and you will get "herding cats."

The phrase comes up constantly. In a recent Reddit thread where someone asked what TPM work looks like day to day, one reply captured it perfectly: "It is a lot of herding cats and making sure other people are accountable."

That line gets laughs because it is true. But it also reveals something about the work that the official job descriptions miss entirely.

What the job descriptions say

The formal version of TPM work sounds structured. Drive alignment across cross-functional teams. Manage timelines and dependencies. Own delivery of complex programs. Facilitate collaboration between Product, Engineering, Analytics, and Legal. Manage SDLC, change management, incident management.

Another TPM in the same thread described it this way: "Our job is to drive clarity through alignment. Sometimes that's very technical, but usually it's getting the right people in the room to agree on a problem, solution, or next step — and then holding folks accountable."

That second description is more honest. It acknowledges that the core work is not managing timelines. The core work is getting groups of people to converge on decisions and then making sure those decisions hold.

What "herding cats" actually means

When a TPM says they are herding cats, they are describing a specific set of coordination failures that repeat across every project, every quarter, every reorg.

The meeting ends and everyone nods, but two people leave with different interpretations of what was decided. The TPM spends the next three days chasing Slack threads to reconcile versions that should have been aligned in the room.

A technical design review surfaces a disagreement between two architects. Nobody resolves it explicitly. The TPM notices two weeks later when both teams are building in different directions.

A stakeholder who was not in the room raises an objection after implementation has started. The TPM now has to re-run a decision that everyone thought was closed.

A senior leader makes an offhand comment in a review meeting. Half the room interprets it as a directive. The other half interprets it as a suggestion. The TPM spends a week untangling what actually changed.

None of these are timeline problems. They are not resource problems or technical problems. They are coordination failures — gaps between what the group discussed and what the group actually decided.

The manual infrastructure problem

Here is the thing about the herding cats metaphor that nobody says out loud: it means the coordination layer is being held together by one person's effort.

The TPM is the one who sends the recap email. The TPM maintains the decision log. The TPM follows up on action items. The TPM notices when a decision is drifting and pulls people back together. The TPM remembers who had the concern that nobody addressed.

This is skilled, difficult work. And it is almost entirely manual.

One TPM described their role as being an "enabler — drive efficiency by thinking about and doing all the things that will make the jobs of those way smarter than us easier." There is something admirable in that framing. There is also something unsustainable about it. When the TPM goes on vacation, changes programs, or gets pulled into a fire, the coordination practices go with them.

The same Reddit thread hinted at this fragility. One commenter noted that TPMs can become bottlenecks: "Since each team has its own TPM, anything that involves other teams is always being redirected to TPM, which will become a bottleneck at a certain point in time."

The bottleneck is not the person. The bottleneck is that the entire coordination layer depends on that person.

Why Chiefs of Staff say the same thing

This pattern is not unique to TPMs. Talk to a Chief of Staff and you will hear nearly identical language. Different context, same structural problem: one person manually tracking whether the executive team's decisions are actually translating into aligned action across the organization.

The CoS chases the follow-ups. The CoS notices when two VPs left a meeting with different understandings of the same commitment. The CoS is the one who knows which decisions from last quarter quietly unraveled because nobody ever made them explicit.

Both roles exist because organizations need coordination infrastructure and do not have it. So they hire a person to be the infrastructure.

What the "herding cats" work actually is

When you strip away the metaphor, what TPMs and Chiefs of Staff are doing is closure quality work.

They are checking whether decisions were stated explicitly. They are tracking whether owners and next steps were named. They are noticing when dissent was not surfaced. They are preserving the rationale, not just the outcome, so the decision does not get re-litigated when context shifts.

These are the four signals of closure quality. Most TPMs could not name them, but they are doing this work every day. The recap email is an attempt to capture explicit decisions. The action item tracker is an attempt to name owners. The "parking lot" list is an attempt to surface dissent. The decision log is an attempt to preserve rationale.

Each of these is a manual workaround for the same underlying problem: the conversation itself did not produce a durable, visible record of how the group reasoned its way to a conclusion.

The structural gap

The tools TPMs have — Jira, Confluence, Google Docs, Slack, spreadsheets — are designed for tracking work, not tracking coordination. They can tell you what tasks exist, who is assigned, and what the status is. They cannot tell you whether the decision that created those tasks actually closed, whether the people executing it understood the reasoning, or whether the scope is drifting because an assumption was never made explicit.

So the TPM fills that gap manually. And when the program gets big enough, or complex enough, or cross-functional enough, the manual approach breaks. That is when herding cats stops being funny and starts being the reason programs stall.

The TPM who described themselves as "keeping a watchful eye out for fires, literally or figuratively" is describing surveillance as a coordination strategy. It works, but only as long as that person can watch everything. And nobody can watch everything.

What would actually help

The answer is not more process. TPMs already have more process than they know what to do with. The answer is not better note-taking tools or smarter AI meeting summaries, either. Those capture what was said. They do not capture whether the group converged.

What TPMs need is instrumentation that does what they are already doing manually: tracking whether decisions reopen with clear owners, surfaced dissent, and captured rationale. Making the coordination layer visible so it is not dependent on one person's memory and discipline.

That is what we are building at Growth Wise. Not a replacement for the TPM. The opposite. Infrastructure that makes the coordination work visible and persistent, so the TPM can focus on the judgment calls that actually require a human — the political navigation, the stakeholder relationships, the technical trade-offs — instead of spending their time reconstructing what the room decided after the room empties.

The job should not be herding cats. The job should be the work that remains after the coordination layer stops losing information.

This article was inspired by discussions on r/technicalprojectmanager and r/projectmanagement.