6 min read

The Meeting That Ate My Program

The average TPM spends 60-80% of their week in meetings. Here's why it's a structural problem, not a time management problem — and how to fix it without burning bridges.
The Meeting That Ate My Program
Photo by Louis Hansel / Unsplash
Most TPMs are drowning in meetings not because meetings are inherently wasteful, but because they've never been taught how to run them or negotiate their attendance. The real fix isn't fewer meetings it's structural boundaries that protect focus time.

A TPM I know tracked her time for a month. She wanted to understand why she never had time to do the actual work of program management; tracking dependencies, following up on blockers, keeping stakeholders aligned outside of meetings.

The answer: she was in meetings for roughly 78% of her week. Not the productive kind where decisions get made. The other kind.

She wasn't alone. The average TPM I talk to reports spending most of their week in meetings;leaving almost no time for the work that actually keeps programs moving. This isn't a scheduling problem. It's a structural one.

TPMs are invited to meetings by default and must fight to be uninvited. The result: highly capable program managers reduced to meeting note-takers and status presenters. And the meetings that actually matter; the ones where decisions get made are the ones they weren't invited to, because they're already triple-booked from the meetings they were auto-added to.

The fix isn't fewer meetings. It's structural boundaries that protect focus time and the permission to say no without social consequences.


The Default-Invite Problem

Here's how meeting invitations work for most TPMs: someone creates a meeting, sees "TPM" on the program roster, and adds you. Not because your specific contribution is required. Because "it would be good to have program perspective."

This is insurance scheduling. You're a hedge against something going wrong. And because it's insurance, no one ever questions whether you're actually needed. The meeting happens. You attend. You may not speak once.

The math is often 2-3x. A one-hour meeting doesn't cost you one hour. It costs you the prep, the meeting itself, the follow-up, and the focus time it displaced. A TPM with a full meeting day is not just unavailable for 8 hours they're cognitively unavailable for the entire day.

The meetings you're added to "for program perspective" are rarely the ones where program decisions are made. Those meetings tend to be small, high-trust, and invitation-only. The meetings where you're "just in case" are the ones where your presence adds no value and costs you everything.


The Paradox: The Meetings You Need Are the Ones You Miss

Here's the pattern you'll recognize: the meetings that most need your presence are the ones you weren't invited to, because you're already in three other meetings that don't need you.

An engineering lead is in a design review discussing a technical tradeoff that will affect your program's timeline. You're in a status sync about a different program, because you were auto-added three weeks ago and no one ever removed you. By the time you hear about the tradeoff, it's already been decided.

This is the meeting paradox. The TPM who attends everything attends the wrong things. The TPM who protects their time to attend the things that matter is labeled "hard to reach" or "not a team player."

The solution isn't to attend every meeting. It's to be in the meetings that require your specific presence, and build systems that keep you informed about everything else.


Why TPMs Can't Say No

Why can't TPMs just say no to meetings?

The fear is usually one of three things:

Fear of missing critical information. If I'm not in the room, how will I know what's happening? This fear ignores the fact that attending a meeting where decisions are already made isn't the same as being informed. And most of the meetings TPMs are auto-added to are not where critical decisions happen.

Fear of being labeled uncooperative. Saying no to a senior leader's meeting invite feels like a career risk. This is sometimes true, but most of the time it's a miscalibration. The leader who scheduled the meeting by auto-adding you didn't make a considered decision about your value they made a default decision.

Lack of social capital to push back. New TPMs especially don't have the relationship equity to say "I don't think I need to be in this meeting." They worry about burning bridges before they've built them.

The solution to all three fears is the same: build trust so you can say no. The TPM who has established credibility with their engineering leads and product managers can decline meetings without consequence. The TPM who is still building that credibility has to be more strategic but can still start building boundaries.

One important caveat: in highly matrixed organizations, the trust-based approach has limits. When you're working across multiple teams with low prior relationship equity, selective meeting attendance can create information gaps that lead to bigger problems missed dependencies, surprises at steering committees, or misalignment between engineering and product. The answer isn't to attend everything anyway. It's to build the asynchronous channels (shared docs, decision logs, weekly updates) that keep you informed without requiring your calendar presence, while simultaneously investing in the relationships that make selective attendance feel safe for everyone.


Attend With Purpose, Follow Up Without

Before you accept any meeting invitation, ask one question: does my specific presence change an outcome in this room?

Not "will I learn something?" you could learn something from most meetings. Not "is this relevant to my program?" most meetings are relevant to some program you own. The question is: will my being in this room change what happens?

Your presence changes outcomes when:

  • You have information no one else has that needs to be in the room
  • A decision needs to be made and you're the decision-maker or primary contributor
  • You're the one who will be accountable for executing whatever is decided

Your presence doesn't change outcomes when:

  • You're there to be "informed" — you could get the same information asynchronously
  • You're there to take notes — that's a job, not a contribution
  • You're there because someone thinks you should be, not because you've evaluated the value

The TPM who evaluates every meeting invitation against this standard and who communicates their reasoning is the TPM who eventually earns the reputation for being selective and high-signal when they do attend.


Focus Time Is a Resource You Have to Protect

Most TPMs treat their calendar as a public good. When someone asks for their time, they give it. The result is a calendar full of other people's priorities.

Focus time the time you need to do the actual work of program management — is a scarce resource. It doesn't protect itself. If you don't block it explicitly, someone else will fill it.

The TPMs who successfully protect their focus time do three things:

Block it explicitly. Not just "free time" actual blocks with titles that communicate what the time is for. "Program tracking do not schedule over." "Risk review availability varies week to week."

Communicate the boundaries. Let your engineering leads and product managers know when your focus blocks are. Tell them what to do if something urgent comes up during a focus block. Make it easy for them to respect the boundary.

Accept that you'll miss some things. Focus time means you'll sometimes miss the meeting that got scheduled during your block. That's the point. The alternative is a calendar that's always full and a mind that's always reactive.


How to Build Focus Time You Actually Keep

If your calendar is already destroyed, you can't fix it overnight. But you can start:

Start small. Block two hours a week for "program management." Protect them religiously. Don't accept meetings during that time unless something is genuinely on fire.

Build the reputation first. Before you start declining senior leader meetings, establish a track record of being highly responsive when you do attend. Give people confidence that your selective attendance doesn't mean they're missing you.

Offer alternatives. When you decline a meeting, offer to follow up asynchronously. "I can't make the design review, but can you send me the decision log and I'll flag any concerns within 24 hours?" This reduces the cost of your absence and demonstrates that you're still engaged.

Kill zombie meetings. That weekly sync that was created for a program that shipped 18 months ago? It's still running because no one has canceled it. Find the zombie meetings on your calendar and kill them first. They're the low-hanging fruit.


The Question to Ask Before You Accept

Before you accept any meeting invitation, ask yourself: if I don't go, what specifically will be worse? If the answer is vague "I might miss something" that's not a reason to attend. That's FOMO.

The meetings that actually need you are the ones where your absence creates a specific gap. The meetings that don't need you are the ones where you're attending out of habit, insurance, or politeness.

The TPM who learns to tell the difference and who builds the reputation and relationships that allow them to decline the rest is the TPM who has time to actually manage programs.

Not attend them. Manage them.