Stakeholder Management

Managing stakeholders—understanding their needs, setting expectations, and navigating conflicting priorities—is crucial for project success. This guide covers practical techniques for working effectively with product managers, executives, customers, and other engineers.

Understanding Your Stakeholders

Types of Stakeholders

Internal Stakeholders:

• Product Managers: Define what to build, prioritize features
• Engineering Managers: Manage team, allocate resources, handle escalations
• Other Engineers: Depend on your work, provide dependencies you need
• Design Team: Create user interfaces and experiences
• QA/Test Engineers: Validate your work
• DevOps/SRE: Maintain infrastructure, handle deployments
• Data/Analytics: Provide insights, need tracking implemented

External Stakeholders:

• Customers: Use your product, provide feedback and revenue
• Customer Support: Interface with customers, escalate issues
• Sales Team: Sell the product, make promises about features
• Executive Leadership: Set company direction, allocate budget
• Legal/Compliance: Ensure regulatory requirements are met

Understanding Stakeholder Motivations

Different stakeholders care about different things:

Stakeholder	Primary Concern	Success Metric
Product Manager	Feature delivery, user satisfaction	Features shipped, user engagement
Engineering Manager	Team health, technical excellence	Velocity, retention, code quality
Executive	Business outcomes, revenue	Revenue growth, customer acquisition
Customer	Their problem gets solved	Product works reliably
Sales	Closing deals	Features customers are asking for
DevOps	System stability	Uptime, incident reduction

Key Insight: When stakeholders seem unreasonable, they're usually optimizing for their success metric, which may conflict with yours.

Setting Expectations

The First Meeting

When starting a new project, establish alignment immediately.

Real-World Scenario: New Feature Request

Bad First Meeting:

PM: "We need to add two-factor authentication"
Engineer: "OK, I'll start working on it"
[3 weeks later]
PM: "Why isn't this done yet? I told the customer it would be ready this week!"
Engineer: "You never said this week! And I didn't know you needed SMS support!"

Good First Meeting:

PM: "We need to add two-factor authentication"

Engineer: "Let me make sure I understand the requirements:

1. Scope Questions:
   - SMS, email, or authenticator app (or all three)?
   - Required for all users or optional?
   - Admin controls to enforce 2FA?
   - What about account recovery if user loses 2FA device?

2. Context Questions:
   - What's driving this? (Compliance requirement? Customer request? Security incident?)
   - Who are the key users? (Internal? Specific enterprise customer?)
   - What's the deadline and how flexible is it?

3. Success Criteria:
   - How will we know this is successful?
   - What's the rollout plan? (All users at once? Gradual?)

4. Constraints:
   - Do we have budget for SMS provider?
   - Any regulatory requirements (GDPR, SOC2)?

Let me take these answers and come back with a proposal tomorrow that includes:
- Detailed scope
- Timeline estimate with confidence level
- Risks and dependencies
- Phased rollout plan if the full scope is too large

Does that work?"

Why this works:

• Asks clarifying questions immediately
• Uncovers hidden requirements
• Sets expectation for structured response
• Buys time to think instead of committing immediately
• Demonstrates thoroughness

Managing Scope Creep

Scenario: The Expanding Project

Week 1:

PM: "We need a user dashboard with basic analytics"
Engineer estimates: 3 weeks

Week 2:

PM: "Oh, we also need export to Excel"
Engineer: "OK..." (now 4 weeks)

Week 3:

PM: "Can we add real-time updates?"
Engineer: "That's a big change..." (now 6 weeks)

Week 4:

PM: "Sales asked for custom date ranges too"
Engineer: (now 7 weeks, original deadline was week 4)

How to Prevent This:

When first addition comes in (Week 2):

Engineer: "Happy to add Excel export. Let me clarify how this affects our plan:

Original scope (3 weeks):
- Dashboard with 5 charts
- Launches March 15

With Excel export (4 weeks):
- Dashboard with 5 charts
- Excel export
- Launches March 22 (one week later)

OR we can keep the March 15 date by reducing scope:
- Dashboard with 3 charts (remove 2 lowest-priority charts)
- Excel export
- Launches March 15

Which would you prefer?

Also, let's establish a change process going forward: any new requirements need
to go through this same trade-off discussion (timeline or scope). Does that work?"

Key Principles:

1. Make trade-offs visible: New scope = more time OR less features
2. Always offer options: Don't just say "this will take longer"
3. Establish a change process: Prevent ad-hoc additions
4. Document agreements: Follow up with email confirming decisions

Saying No (Diplomatically)

You'll often need to push back on requests. Here's how to do it without damaging relationships.

Scenario 1: Unrealistic Timeline

Bad Response:

Sales: "Can we have this feature in 2 weeks? I have a deal closing."
Engineer: "No, that's impossible."

Good Response:

Sales: "Can we have this feature in 2 weeks? I have a deal closing."

Engineer: "I want to help you close this deal. Let me understand the constraint:

1. What specifically does the customer need?
2. What's the deal size? (Helps me understand business impact)
3. Is there a workaround or interim solution that would work?
4. Could they start with a pilot/beta version?

The full feature is 6 weeks. But here's what I can do in 2 weeks:
- Basic version with core functionality (80% of value)
- Manual workarounds for edge cases
- Beta quality (documented limitations)

Would that be sufficient to close the deal, with the full version following in a month?

Alternatively, if this is a major deal, we could pull in another engineer and
potentially hit 3-4 weeks for the full version. How big is the opportunity?"

Why this works:

• Shows you want to help
• Asks about underlying need (maybe there's a simpler solution)
• Provides alternatives
• Quantifies business impact
• Offers creative solutions
• Still protects realistic timelines

Scenario 2: Out of Scope Request

Bad Response:

Customer Success: "Customer wants dark mode. Can you add it this sprint?"
Engineer: "That's not on the roadmap. Talk to the PM."

Good Response:

Customer Success: "Customer wants dark mode. Can you add it this sprint?"

Engineer: "Thanks for passing along the feedback. Dark mode is a substantial
project (3-4 weeks), not something we can add mid-sprint.

Here's what I can do:
1. Document this request in our feature tracking system
2. Loop in PM to prioritize against other requests
3. If it's critical for this specific customer, let's discuss with PM about
   next quarter's roadmap

Context that will help prioritization:
- Is this one customer or multiple?
- Is this blocking a deal or renewal?
- Is there a revenue impact?

Can you provide that context so we can make an informed prioritization decision?"

Why this works:

• Explains why it can't happen immediately (not just "no")
• Offers to properly track the request
• Involves the right people (PM for prioritization)
• Asks for business context to help prioritization
• Shows you're taking it seriously

Managing Conflicting Priorities

Scenario: Three Urgent Requests, One Engineer

Monday Morning:

PM: "Critical bug in checkout—customers can't purchase!"
Your Manager: "Please review Sarah's PR—she's blocked."
Sales: "Demo in 3 hours, need data export feature working!"

Bad Response:

Try to do all three at once, context switching constantly, nothing gets done well.

Good Response:

Step 1: Triage (5 minutes)

Assess impact and urgency:

1. Critical bug in checkout:
   - Impact: HIGH (directly affecting revenue)
   - Urgency: HIGH (happening now)
   - Time: Unknown (could be 1 hour or 8 hours)

2. Code review:
   - Impact: MEDIUM (blocks one person)
   - Urgency: MEDIUM (she can work on something else temporarily)
   - Time: 20-30 minutes

3. Data export for demo:
   - Impact: MEDIUM (potential deal, not existing customers)
   - Urgency: HIGH (3 hours until demo)
   - Time: 2-3 hours if it works, could be longer if broken

Step 2: Communicate Immediately

[To all three stakeholders in one message, CC your manager]

"I just received three urgent requests simultaneously. Here's my proposed prioritization:

1. FIRST: Critical checkout bug (revenue impact on existing customers)
   - Starting immediately
   - Will update in 1 hour with assessment

2. SECOND: Sarah's code review
   - Will complete by 11am
   - Sarah: Can you work on [X] in the meantime?

3. THIRD: Data export for demo
   - Sales team: This won't be ready for 3pm demo
   - Option A: Can we demo with sample/mock data?
   - Option B: Reschedule demo to tomorrow? (I can have this ready by 2pm today)
   - Option C: Can someone from data team export manually for today's demo?

Does this prioritization make sense given business impact? If you believe the
priorities should be different, please let me know in the next 15 minutes."

Why this works:

• Transparent about the conflict
• Shows clear reasoning (revenue impact)
• Offers alternatives for lower-priority items
• Gives stakeholders a chance to weigh in
• Sets clear expectations (data export won't make the demo)
• Protects your focus (you'll work on one thing at a time)

Step 3: Execute and Update

[1 hour later]

"Update: Checkout bug identified. Fix will take 2 more hours. Still on schedule
to complete Sarah's review by 11am and data export by 2pm. No blockers."

Managing Up

"Managing up" means proactively managing your relationship with your manager.

Weekly 1-on-1s

Bad 1-on-1:

Manager: "How's it going?"
You: "Good, working on the API"
Manager: "Any blockers?"
You: "Nope"
Manager: "OK, see you next week"

This is a wasted opportunity.

Good 1-on-1 Structure:

Come with an agenda (share in advance):

1-on-1 Agenda for [Date]

**Project Updates** (5 min)
- API v2 migration: 60% complete, on track for Friday
- Performance optimization: blocked by DevOps (see below)

**Blockers** (10 min)
- Need production database access for optimization work
- Been waiting 1 week for DevOps ticket
- Can you help escalate?

**Career Discussion** (10 min)
- Working on system design skills
- Would like to lead the Q3 payments redesign
- What else should I focus on for promotion to Senior?

**Feedback Exchange** (5 min)
- Really appreciated your help navigating the PM conflict last week
- Can we get clearer requirements before sprint planning?

**Questions** (5 min)
- What are the top priorities for the team this quarter?
- How am I tracking vs expectations?

Key Principles:

• You own the agenda: Don't wait for your manager to run the meeting
• Bring problems with proposed solutions: "I'm blocked on X, could you escalate?" not just "I'm blocked"
• Discuss career regularly: Don't wait for annual reviews
• Ask for feedback: "What should I do differently?"
• Give feedback up: Help your manager help you

Proactive Communication

Don't wait for problems to escalate:

Bad:

[3 weeks into a 4-week project]
You to Manager: "Hey, this isn't going to be done on time."
Manager: "What?! The exec team is expecting a demo Friday!"

Good:

[1 week into 4-week project]
You to Manager: "Weekly update on API project:

Progress: 25% complete (on schedule)
This week: Completed authentication layer
Next week: Database integration

Risk I'm tracking: The payment gateway API documentation is incomplete.
If we can't figure it out from docs, we may need to contact their support,
which could add 3-5 days.

I'll have more clarity by end of next week. If we're trending toward delay,
you'll know immediately."

[2 weeks into project - risk is materializing]
You to Manager: "Update: The payment gateway issue is bigger than expected.

Options:
1. Continue with Gateway A: Will add 5 days (new finish: Feb 20 instead of Feb 15)
2. Switch to Gateway B: Documentation is better, but need to redo 2 days of work
   (new finish: Feb 17)
3. Launch without payment integration: Hit Feb 15, add payments in next release

My recommendation: Option 2 (Gateway B). Only 2 days late vs 5, and Gateway B has
better long-term support.

Need your input by EOD today to stay on track."

Why this works:

• Identifies risks early
• Provides updates proactively
• Offers solutions, not just problems
• Gives manager time to adjust plans
• No surprises

Working with Product Managers

Product Managers (PMs) are your primary partners. Here's how to work with them effectively.

Understanding the PM Perspective

What PMs worry about:

• Shipping features customers need
• Meeting roadmap commitments
• User engagement and satisfaction
• Revenue impact
• Balancing requests from sales, customers, executives

What PMs need from you:

• Realistic estimates
• Early warning on delays
• Technical feasibility guidance
• Creative solutions to problems

The Engineer-PM Partnership

Scenario: Feature Request

Bad Interaction:

PM: "We need to add custom reports"
Engineer: "That's going to take forever. Why do we need this?"
PM: "Because customers are asking for it"
Engineer: "OK, I guess I'll start working on it"
[Month later: Feature ships, no one uses it]

Good Interaction:

PM: "We need to add custom reports"

Engineer: "Let me understand the need:
- Which customers are asking?
- What reports do they need?
- What problem does this solve for them?
- What do they do today without this feature?

[PM explains: 5 enterprise customers need sales reports, currently exporting to Excel manually]

Engineer: "OK, so the core need is sales reporting. Let me propose options:

Option A: Full custom report builder
- Pros: Maximum flexibility, any report they want
- Cons: 8 weeks to build, complex UX, hard to maintain
- Cost: High

Option B: Pre-built sales reports with filters
- Pros: 3 weeks to build, simple UX, covers 80% of needs
- Cons: Can't create completely custom reports
- Cost: Medium

Option C: Improved Excel export
- Pros: 1 week to build, customers already familiar with Excel
- Cons: Not "in-app," but solves the actual problem
- Cost: Low

My recommendation: Start with Option C (1 week), validate it solves the problem.
If customers still need more, invest in Option B. We can always build A if there's
demand.

What do you think?"

Why this works:

• Asks about underlying need, not stated solution
• Proposes multiple options with trade-offs
• Recommends starting small
• Validates before big investment
• Collaborative tone

Handling Disagreements with PMs

Scenario: You think the PM's priority is wrong

Bad Approach:

"That feature is stupid. We should work on performance instead."

Good Approach:

"I want to understand the priority here. Can you help me understand the trade-off?

We have two options:
1. New feature (what you're proposing): Targets new customers, potential revenue impact
2. Performance improvements: Affects existing customers, reducing churn

Context I'm seeing:
- Current performance is causing 3-5 support tickets per day
- Page load time is 5 seconds (industry standard is 2 seconds)
- Users complain about speed in every survey

I'm concerned that if we don't fix performance, we'll lose existing customers
even as we gain new ones.

What am I missing? Is there a business reason to prioritize new features over
retention right now?"

Why this works:

• Assumes PM has good reasons you don't know about
• Presents data, not opinions
• Frames as a question, not a demand
• Shows you're thinking about business impact
• Opens dialogue

Working with Executives

Executives have limited time and care about business outcomes, not technical details.

The Elevator Pitch

You have 30 seconds to explain something in an elevator. Make it count.

Bad Elevator Pitch:

"We're refactoring the authentication service to use OAuth 2.1 with PKCE flow
instead of the legacy session-based system, which will improve security posture
by eliminating CSRF vulnerabilities..."

Good Elevator Pitch:

"We're upgrading our login system. This prevents a type of security vulnerability
that could compromise user accounts. It takes 3 weeks and has zero customer impact.
We'll do it during normal maintenance windows."

For a business initiative:

"We're reducing page load time from 5 seconds to 2 seconds. This should decrease
bounce rate and increase conversions. Based on similar companies' data, we expect
a 10-15% improvement in signup rates. Takes 4 weeks, launches in stages."

Presenting to Executives

Structure:

1. Bottom line first (30 seconds): What are you proposing and why?
2. Business impact (1 minute): How does this affect revenue, users, risk?
3. Ask/Decision needed (30 seconds): What do you need from them?
4. Details (only if they ask): Technical details, timeline, resources

Example:

[Bottom Line]
"We need to invest 2 months in database scaling. Without this, the site will become
unusable when we hit 100K users, which we're on track to reach in Q3.

[Business Impact]
Current capacity: 50K users
Growth rate: 5K users per month
Without scaling: Site crashes in Q3, costing $500K+ in lost revenue and brand damage
With scaling: Supports 500K users, buying us 2 years of growth runway

[Ask]
I need approval to dedicate 2 engineers for 8 weeks. This delays Feature X by one month.

[Ready for questions]"

Summary

Effective stakeholder management is about building trust and aligning on goals:

• Understand motivations: Different stakeholders care about different metrics
• Set expectations early: Clarify scope, timeline, and success criteria upfront
• Make trade-offs visible: New scope = more time OR reduced features
• Say no diplomatically: Offer alternatives instead of just refusing
• Communicate proactively: Share risks and blockers early
• Manage up: Own your 1-on-1 agenda, ask for feedback, discuss career
• Partner with PMs: Understand needs, propose options, validate solutions
• Talk business with executives: Focus on outcomes, not technical details

Remember: Stakeholder management isn't manipulation—it's about ensuring everyone has the information they need to make good decisions together.