Stakeholder Management: A Top TPM Skill

Every few months, someone asks me what separates good TPMs from great ones. I've given a few different answers over the years: technical fluency, communication clarity, structured thinking. But if I'm being honest about the single skill that creates the most leverage, it's stakeholder management.

Not meeting facilitation. Not status reporting. Not even risk management, though all of those matter. Stakeholder management is the foundation under all of them because none of those other things work if you don't have the right relationships with the right people.

Let's build that foundation.

What a Stakeholder Actually Is

In program management, a stakeholder is anyone who has an interest in your program or is affected by its outcomes. That definition is intentionally broad, and that's the point. Most early-career TPMs think too narrowly about who their stakeholders are and that gap creates blind spots.

Your stakeholder list will typically include:

· Engineering leads and engineers: The teams doing the technical work. They're accountable for delivery, and their concerns (technical debt, timeline realism, dependencies) are your concerns.

· Product managers: Usually the owners of the product roadmap. They have strong opinions about what gets built and when. Misalignment with PMs is one of the most common sources of program friction.

· Engineering managers and directors: Your direct counterparts in engineering leadership. They care about team health, capacity, and whether your program is creating extra load on their teams.

· Design and UX: Sometimes omitted in program conversations. When design is left out, you get integration surprises late in the cycle.

· Data and analytics teams: Increasingly important as data pipelines underpin most modern features. If your program involves tracking, measurement, or data migration, they're stakeholders.

· Legal and compliance: Easy to forget until they block your launch. Regulatory requirements, privacy law, and terms of service all run through them. They're not trying to slow you down; they're trying to keep the company out of trouble.

· Security: Same dynamic as legal. Invite them early or suffer later.

· Senior leadership (VPs, Directors, C-suite): Your executive sponsors. They need just enough information to make decisions and stay comfortable. Too little and they'll be surprised at a bad time. Too much and you'll lose them.

· External partners and vendors: If your program has third-party dependencies, those parties are stakeholders. Their timelines, their reliability, their escalation paths—you own understanding all of it.

· Customers or customer-facing teams: Support, sales, and customer success teams feel the impact of your program directly. If you're rolling out a change that affects customer experience, they need to be in the loop.

The exercise you should do at the start of every program: Write out every function that touches your program, even if it's tangentially. Then ask yourself, who in that function cares what happens? That's your stakeholder map.

Stakeholder Mapping: Interest vs. Influence

Once you have your list, the next step is to understand how much each stakeholder matters and in what way. A common framework is the interest vs. influence matrix.

Plot your stakeholders on two axes:

· Influence: How much power do they have to affect your program's outcome? Can they approve budget, redirect engineering resources, block a launch?

· Interest: How much do they care about what you're doing? Is this program central to their work, or is it a peripheral concern?

This creates four quadrants:

	High Influence	Low Influence
High Interest	Manage Closely	Keep Informed
Low Interest	Keep Satisfied	Monitor

Manage Closely: These are your key stakeholders. Your VP Engineering sponsor. The product lead who owns the roadmap your program depends on. The compliance officer whose sign-off you need for launch. These people get your dedicated attention, regular touchpoints, and early warning on anything that could surprise them.

Keep Informed: These are stakeholders who care deeply but aren't in a position to re-direct the program. Your engineering team leads. The product designers working on the feature. Keep them in the loop, respond to their concerns quickly, but you're not spending as much time managing the relationship.

Keep Satisfied: These are power brokers who don't currently care much but could become obstacles if they feel overlooked. A senior director in a related function. A VP who funds an adjacent team. Keep them updated at a cadence that prevents surprises without overwhelming them.

Monitor: Low influence, low interest. They need a communication channel but not active relationship management. Put them on the distribution list for status updates and move on.

Managing Different Stakeholder Types

The matrix tells you how much effort to put where. The harder question is how. Different stakeholders need to be engaged differently.

Engineering Teams

Engineers respect competence and directness. They don't want meetings that could have been emails, and they don't want to explain the same thing twice because you weren't paying attention.

How to earn trust with engineering:

· Do your homework before design reviews and status syncs. Read the docs, the spec, the relevant tickets.

· Ask questions that show you've thought about the problem, not questions that reveal you haven't.

· Protect their time. If you can resolve a dependency async in Slack without pulling someone into a meeting, do that.

· When they raise a technical risk, take it seriously and act on it. Nothing erodes trust faster than a TPM who nods and does nothing.

· Give them credit when the program succeeds. Publicly, in writing, upward.

Executive Sponsors

Executives are optimizing for something you might not see from your seat: the health of their portfolio, the alignment of their team's work with company strategy, their own credibility with their peers and the board.

How to communicate with executives:

· Bottom-line up front. Tell them the headline first, then the supporting detail. "We are on track for the July launch. One dependency is at risk—here's what we're doing about it." Not the reverse.

· Make the ask explicit. If you need a decision, say so. "I need your help to unblock X. Here are the two options and my recommendation."

· Use their language. Executives think in terms of revenue, risk, customer impact, and competitive position. Translate your program's status into those terms.

· Never surprise them. If something significant is going wrong, tell them before it becomes a crisis. A bad surprise is twice as damaging as the bad news itself.

Product Managers

PM-TPM relationships are often the most complex. You're both coordinating the same teams, often with partially overlapping mandates. Friction is common.

The most effective PM-TPM partnerships I've seen are built on explicit role clarity early. Who owns the roadmap? Who owns the delivery timeline? When there's conflict between the two, who makes the call?

How to build a strong PM relationship:

· Have the "how do we work together" conversation early. Don't assume alignment.

· Keep them informed on timeline risk before it becomes a problem. They're usually managing expectations with their own stakeholders, and late surprises create cascading issues.

· When you disagree, have that conversation bilaterally before escalating. Escalating a PM-TPM disagreement without trying to resolve it first is bad form.

Legal and Compliance

Legal and compliance stakeholders are often underinvited to programs—and then they become blockers. The irony is that they're much easier to work with early when the options are open than late when you're trying to ship.

How to work effectively with legal and compliance:

· Identify them at program kickoff and ask them what they need to see and when.

· Give them more lead time than you think they need. Their review cycles are slower than engineering cycles.

· When they raise a concern, don't argue it away—understand it fully first. There's usually a real constraint behind it.

· Learn enough about the relevant regulatory landscape (GDPR, HIPAA, SOX, PCI—whatever applies to your domain) to have an informed conversation.

Personal Note: Share a specific example of legal or compliance involvement in one of your programs—how you approached it and what you learned

The Art of Managing Up

"Managing up" is one of those phrases that sounds political and feels uncomfortable when you first encounter it. In practice, it just means keeping your leadership chain informed and aligned so they can do their jobs—and so they don't make decisions based on incomplete information.

Here's the practical version of managing up:

Give your manager what they need to go to bat for you. If your program needs resources, executive attention, or a decision, your manager is often the one making that ask upward. Make it easy for them by giving them a clear, accurate picture of where things stand and what you need.

Surface problems before they escalate on their own. Your manager should never be blindsided by something you knew about. If something is going wrong, tell them early, with your plan to address it. "Here's the problem, here's what I'm doing about it, here's what I need from you if my plan doesn't work" is almost always the right framing.

Give credit generously. When your team achieves something, make sure leadership knows who did the work. This builds goodwill with your team and signals to leadership that you're not credit-hungry.

Don't escalate too often. Escalation is a tool, not a habit. If you escalate every blockers, the signal gets diluted and leadership starts to wonder whether you can manage things yourself. Escalate when you genuinely can't resolve something at your level.

The Art of Managing Sideways

The majority of your stakeholder management happens sideways—across peer relationships with PMs, engineering managers, legal, data, and design teams. No one reports to you. You have to earn cooperation.

The most effective lever you have is reciprocity. Be helpful. When a peer's program has a problem that you can assist with, assist. When an engineering manager is trying to unblock their team, help them do it. Relationships built on mutual benefit survive the frictions of program work. Relationships built only on what you need from others don't.

Be someone who follows through. In most organizations, there are people who say they'll do things and people who actually do them. Be the second type. If you say you'll send a summary by end of day, send it. This sounds obvious, and most people think they're doing it. Most people are not.

Treat information as shared. TPMs often know things other stakeholders don't—because they're in more rooms. When information would help a peer do their job better, share it. Information hoarding feels like power but destroys trust.

Communication Cadence: When and How Often

A question I get regularly: how often should you communicate with stakeholders?

The honest answer is: it depends on the phase of the program and the risk level.

A rough framework:

Stakeholder Type	Standard Cadence	High-Risk / Pre-Launch
Executive sponsors	Bi-weekly written update, monthly live review	Weekly live review
Engineering leads	Weekly program sync	2-3x per week, or daily if critical
Product managers	Weekly program sync + ad hoc	Daily touchpoints
Legal / Compliance	Monthly review, more during milestones	Bi-weekly or more
External partners / vendors	Bi-weekly	Weekly with escalation contacts active

The one rule that overrides all cadences: Bad news travels by exception. If something significant changes between your regular cadence, communicate it immediately. Don't wait for the next scheduled update.

Personal Note: Share your personal approach to status communication—what format you use, how you decide what gets escalated versus what goes in the written update, and what's changed in your approach over time

When Stakeholders Become Difficult

This is the conversation people always want to have, and the one that's hardest to give generic advice for—because "difficult" looks very different depending on the situation.

That said, there are patterns:

The stakeholder who doesn't engage. They skip meetings, don't respond to async requests, and then have strong opinions when they do show up. Solution: understand why they're not engaging. Are they genuinely too busy? Do they not understand why their input matters? Are they checked out on this program specifically? The answer determines the fix. Sometimes you need to make the ask simpler and more specific. Sometimes you need their manager to signal that this is a priority.

The stakeholder who escalates around you. They go straight to your manager or their manager without coming to you first. This usually signals either that they don't trust you to resolve the issue or that they're trying to use the political hierarchy as a weapon. The response is to have the direct conversation: "I'd prefer you come to me first when you have concerns. Can we agree on that?" Some people will. Some won't, and you'll need to manage the relationship knowing that escalation is a tactic they use.

The stakeholder who constantly changes the scope. New requirements, new priorities, new "I just talked to the CEO" redirections. This is often a PM or senior leader who isn't constrained by delivery reality. The solution is to make the cost of scope changes visible. Every change gets documented: "This change adds X weeks to the timeline and requires Y from engineering. Are we aligned on that trade-off?" When consequences are explicit, scope requests often moderate themselves.

The stakeholder who is openly hostile. This is rare, but it happens—usually when there's a history you inherited, a disagreement about whose program should own what, or a personality dynamic that predates you. Don't respond to hostility with hostility. Identify what they actually need, try to meet it, and keep your manager informed. If it escalates to the point where it's affecting delivery, it becomes a people problem, not just a stakeholder problem.

Personal Note: Share an example of a difficult stakeholder situation you navigated—what you tried, what worked, and what you'd do differently

The Long Game

Stakeholder management isn't a project. It's a practice that compounds over time. The relationships you invest in now pay dividends when you need something later—when you need a fast decision, when you need someone to go to bat for your program, when you need information that isn't in anyone's dashboard.

The TPMs I've seen struggle with stakeholder management are usually the ones who treat it as overhead—something they do because they have to, not something they do because they understand its value. The ones who excel treat every stakeholder interaction as an investment.

Build the relationships before you need them. You'll need them.

Personal Note: Add your own principle or philosophy about stakeholder management that you've developed over your career

Key Takeaways

1. Stakeholder management is the foundation under every other TPM skill. Status reports, risk management, and meeting facilitation all depend on having the right relationships with the right people.

2. Map your stakeholders early, using the interest vs. influence matrix. Know who needs to be managed closely, who needs to be kept informed, and who needs to be kept satisfied without overloading them.

3. Different stakeholders need different approaches. Engineers need competence and directness. Executives need bottom-line-up-front and no surprises. PMs need explicit role clarity. Legal needs early involvement and lead time.

4. Managing up is about enabling your leadership chain, not office politics. Surface problems early, make your asks explicit, and never let your manager be blindsided.

5. Communication cadence should match program risk. In low-risk phases, regular scheduled updates are enough. In high-risk or pre-launch phases, increase the frequency. Bad news always travels by exception—communicate it immediately.

6. Relationships compound. Invest in them before you need them. The trust you build in the first third of a program is what carries you through the difficult last third.

______________________________________________________

Next week: How to break into TPM without an engineering background—a practical, step-by-step roadmap for career switchers.

Related Reading:

· What is a Technical Program Manager?

· [How to Break Into TPM Without an Engineering Background](#) (Next Week)

· [How to Run Meetings That Engineers Don't Hate](#) (Coming in Week 10)