Mehmet Erturk | Stakeholder Management for Technical Leaders

Stakeholder Management

You can write perfect code. You can design elegant systems. You can lead your team brilliantly.

And still fail because you can't get buy-in from stakeholders.

I learned this the hard way. Built the right thing technically, couldn't convince anyone to use it. Watched inferior solutions win because someone sold them better.

Technical skill gets you in the door. Stakeholder skill determines what you can accomplish.

Who Are Your Stakeholders?

Anyone who can affect or is affected by your work:

Up: Your boss, their boss, executives (see Managing Up Without Selling Out) Across: Other teams, product, design, sales, support Down: Your team (yes, they're stakeholders too) Outside: Customers, vendors, partners

Each has different needs. Each requires different communication.

Understanding What They Care About

People support things that address their concerns. Find out what those are.

Executives: Business impact, risk, timelines Product: User value, roadmap fit, competitive position Sales: Customer requests, deal blockers, revenue Support: Operational burden, customer complaints Finance: Costs, ROI, budget predictability Legal: Compliance, risk mitigation Engineers: Technical excellence, learning, autonomy

When proposing something, frame it in terms of what they care about.

"We should refactor the auth system" → ignored. "Refactoring auth will reduce security incidents by 60% and cut onboarding time for new engineers in half" → heard.

Same project. Different framing. Different outcome.

The Four Types of Stakeholders

Not all stakeholders need the same attention.

High power, high interest: Manage closely. Regular engagement. Keep informed. Example: Your VP on a strategic project

High power, low interest: Keep satisfied. Update when relevant. Don't waste their time. Example: CFO on a feature project

Low power, high interest: Keep informed. Leverage their enthusiasm. Example: Power users who love your product

Low power, low interest: Monitor. Don't over-invest. Example: Tangentially affected teams

Prioritize your engagement accordingly.

Building Relationships Before You Need Them

The worst time to build a relationship is when you need something.

Invest early:

Coffee chats with people from other teams
Offering help before asking for help
Sharing credit generously
Being reliable on small things

When you do need support, you're not a stranger asking a favor. You're someone they already trust.

Running Effective Stakeholder Meetings

Before:

Clear agenda sent in advance
Right people in the room (no more, no less)
Pre-socialized controversial points
Materials shared for review

During:

Start with context and goal
Listen more than you talk
Address concerns directly
Capture decisions and action items

After:

Send summary within 24 hours
Follow up on action items
Track commitments

Most meeting dysfunction is preparation failure.

Handling Disagreement

Disagreement is normal. Handle it well:

Separate people from positions. They're not attacking you. They have different constraints or information.

Seek to understand first. "Help me understand your concern" > "Here's why you're wrong"

Find common ground. What do you both agree on? Build from there.

Propose experiments. "Let's try it for 30 days and measure" often breaks deadlocks.

Know when to escalate. If you can't align, go to whoever can make the call. Don't let it fester.

Communicating Technical Decisions

Most technical leaders communicate poorly to non-technical stakeholders.

What doesn't work:

Technical jargon
Implementation details
"Trust me" without explanation
Dismissing concerns as uninformed

What works:

Business impact front and center
Trade-offs explained simply
Analogies that connect to things they know
Addressing their actual concerns

"We need to migrate to Kubernetes" → confusion. "Our current setup can't handle 10x traffic without major cost. This migration gives us flexibility to scale up or down, which will save us $200K next year and handle holiday traffic without panic." → understanding.

Difficult Stakeholders

Some people are just hard to work with. Strategies:

The always-busy executive: Respect their time. Brief updates. Clear asks. No rambling.

The anxious stakeholder: Over-communicate. Frequent updates. No surprises. Build confidence through reliability.

The skeptic: Bring data. Acknowledge trade-offs. Show you've considered alternatives.

The blocker: Understand why they're blocking. Address underlying concerns. Escalate if necessary.

The scope creeper: Clear documentation of agreed scope. Explicit change process. "We can add that, but it means X gets pushed."

The RACI Framework

For complex projects, clarity helps:

Responsible: Does the work
Accountable: Makes decisions, owns outcome
Consulted: Provides input before decisions
Informed: Told after decisions

Map stakeholders to roles. Prevents confusion about who decides what.

When Things Go Wrong

Bad news doesn't age well. When things go wrong:

Tell them early. Don't hide hoping it gets better.
Own it. No excuses. "Here's what happened."
Have a plan. "Here's what we're doing about it."
Follow through. Do what you said.

Handling failures well builds more trust than never failing.

The Long Game

Stakeholder management isn't transactional. It's building relationships over time.

Every interaction is a deposit or withdrawal. Be reliable. Be honest. Be helpful. Deposits compound.

When you need something big — a budget increase, a risky project, benefit of the doubt — you'll have the capital.

Technical skills are table stakes. The leaders who have outsized impact are the ones who can navigate the human side: building alignment, communicating effectively, handling disagreement.

You don't have to be political. You just have to be good at working with people.