Most engineering management content treats stakeholders as a hostile resource to be managed: deflect their requests, manage their expectations, protect the team from them. That framing is wrong, and it’s the reason a lot of EM-stakeholder relationships eventually go bad.
Stakeholders aren’t an obstacle. They’re the reason the team has work to do. The job isn’t to manage them — it’s to translate between two languages: engineering reality and business reality. Most EMs do this badly because nobody taught them how.
This is the playbook. The translator’s job, the five recurring stakeholder personalities and how each one breaks the team’s sprint, the weekly update template that handles 90% of one-on-one stakeholder communication, and the rule that protects the team without burning the relationship.
The translation problem
Engineers and stakeholders use the same words to mean different things.
- “This will take a week.” Engineer means “in a perfect world with no interruptions, this is one week of focused work.” Stakeholder hears “we’ll have it on my desk seven days from now.”
- “Done.” Engineer means “the code passes tests and is in main.” Stakeholder means “users can use it and we’ve measured the impact.”
- “Simple.” Engineer means “no novel concepts.” Stakeholder means “we should be able to do it this afternoon.”
- “We need to refactor X.” Engineer means “the code is causing real problems we’ll pay for if we don’t address.” Stakeholder hears “engineering wants to fiddle with code instead of shipping features.”
Translation isn’t optional. Either the EM does it deliberately or it happens accidentally and badly. The first habit:
Whenever a sentence might mean two different things to the team and the stakeholder, restate it explicitly in both languages before agreeing on anything.
Five stakeholder personalities and how each one breaks the sprint
Patterns repeat. Most EMs eventually run into all five. The behaviour and the fix:
1. The Eager PM
Behaviour: Surfaces new ideas constantly. Every Slack DM is “could we also…?” Treats the backlog as a brainstorming surface. Doesn’t realise each new ask costs sprint capacity.
What goes wrong: The team accumulates 30 partially-specified tickets. Sprint planning becomes triage instead of commitment. Engineers lose context every time priorities shift.
The fix: Two channels — one for ideas, one for commitments. Ideas go to a shared doc or a backlog with a “concept” status. Commitments go through sprint planning. This isn’t bureaucracy; it’s separating “could we” from “will we” so the team can focus.
Script: “Adding to the ideas doc — let’s discuss at next sprint planning whether we prioritise it. The current sprint is committed.”
2. The Anxious Founder/CEO
Behaviour: Pings about a single feature daily. Asks for status, sometimes multiple times in a day. Reads tea leaves. Worries that engineering moves “too slow.”
What goes wrong: Engineers get pulled into ad-hoc status updates that don’t add value. The team feels watched, not trusted. The founder picks up signals they shouldn’t (a single bug becomes “engineering can’t ship”).
The fix: A predictable update channel. Weekly written update (template below). For bigger initiatives, a single dashboard or doc the founder can self-serve. Most anxious-founder pings stop the moment they have a place to look.
Script: “I’ll send a written update every Friday. For [big initiative], here’s the dashboard — I keep it current. If you need something between Fridays, ping me directly and I’ll respond same-day.”
3. The Skeptical Finance Lead
Behaviour: Asks “what did engineering ship this quarter?” with the implicit framing “for the money we spent.” Wants to convert engineering output into countable units. Treats engineering as a cost centre.
What goes wrong: The team feels reduced to ticket-counts. Internal work (refactoring, infra, on-call) is invisible. Strategic projects are punished for being slow.
The fix: Lead with outcomes, not output. Don’t say “we shipped 47 tickets.” Say “we reduced checkout error rate from 4.2% to 0.8%, which recovers an estimated £X/month in lost orders.” Translate engineering work into business impact every quarterly review.
Script: “Quarterly summary — outcomes and the work behind each. Three big outcomes, two ongoing investments, one risk we’re managing.”
4. The Domain-Expert Stakeholder
Behaviour: Knows their corner of the business deeply. Has strong opinions about how features should work, often based on long experience. Frustrated when engineering implements something differently.
What goes wrong: Engineering ships, stakeholder hates it, rework happens. Or engineering pushes back, stakeholder feels ignored, relationship sours.
The fix: Pull them into requirements before engineering starts. A 30-minute review of the user story and the acceptance criteria with the stakeholder is worth a week of rework. Don’t make this a “demo at the end” — make it “review the spec at the start.”
Script: “Before we start, walking through the spec with you — 30 minutes. Better to catch missed nuance now than after we’ve built the wrong thing.”
5. The Disengaged Stakeholder
Behaviour: Says “you decide.” Doesn’t show up to demos. Doesn’t respond to clarifying questions. Then complains when the result isn’t what they wanted.
What goes wrong: Engineering makes assumptions, ships, gets blamed for the assumptions. Or engineering blocks waiting for input, sprint goal slips.
The fix: Force decisions on a timer. “We need a decision on X by Wednesday — if we don’t have it, we’ll go with [default]. The default is reasonable but not what you’d choose if you weighed in.”
Script: “Decision needed: A or B. We’ll default to A on Wednesday if you don’t weigh in. A is fine; if you prefer B for reasons we don’t see, tell us by then.”
The weekly stakeholder update template
90% of stakeholder communication can be handled with a written weekly update. Three paragraphs:
What shipped this week — User-visible outcomes, named with their business impact. Not “merged the auth refactor” — “logged-in users see 30% faster page loads.”
What’s in flight — Active sprint work, expressed as the outcome the sprint is targeting. If there are risks (someone’s out, dependency slipping), name them here without drama.
What’s next — One sentence about the next sprint’s focus, framed as the outcome.
Two more lines below:
- Where to look: link to the dashboard / sprint board / metric chart they can self-serve.
- What I need from you: explicit asks, if any. “I need a decision on pricing tiers by Tuesday so we can include it in next sprint.”
This format works because it answers the three questions stakeholders actually have: what changed, what’s happening now, what’s coming. Without an update, they invent answers.
The escalation rule: protect the team without burning the relationship
Engineers tend to either:
- Absorb stakeholder pressure silently, miss the goal, and resent the stakeholder. Or
- Push back on stakeholders directly, damage the relationship, and lose political support for engineering.
Neither works. The middle path is visible trade-off conversations:
“Yes, we can do X. To do it this sprint, we’d cut A or B. If A and B are higher priority, we’ll defer X. Your call.”
This works because:
- It doesn’t say no — it says “here are the trade-offs.”
- It puts the decision in the stakeholder’s seat.
- It documents the trade-off so retrospective conversations have data.
- It doesn’t pretend the team has infinite capacity.
The team ends up with the same outcome — protected sprint capacity, deferred new work — but the stakeholder feels heard, not deflected. Most stakeholders pick the default (“OK, defer to next sprint”) once they see the trade-off.
Three things to do less of
Common stakeholder-management mistakes that hurt relationships:
-
Don’t translate engineering complexity as effort heroism. “This was really hard” implies the engineer should be thanked. Stakeholders don’t care about how hard it was; they care about what they got. Talk about outcomes, not sweat.
-
Don’t be the team’s only stakeholder interface. If only the EM talks to stakeholders, engineers can’t develop those skills, the EM becomes a bottleneck, and stakeholders feel walled off from the team. Pick a couple of senior engineers to share the interface, even if just for specific projects.
-
Don’t keep stakeholders fed with vague reassurance. “We’re making progress” without specifics is less reassuring than “we’re 60% through and on track for Friday.” Vagueness reads as “they don’t know,” even when you do.
Three things to do more of
-
Show your reasoning, not just your conclusion. “We picked B because A would have meant 3 weeks of dependency on the platform team — here’s the math.” Stakeholders trust EMs whose reasoning they can follow even when they disagree.
-
Pre-empt their predictable concerns. Finance always asks about cost. Sales always asks about timeline. Founders always ask about competitive risk. Address those before they have to ask.
-
Loop the team in on stakeholder feedback. When a stakeholder is delighted with a ship, share it with the engineer who built it. When a stakeholder is unhappy, share it constructively. Engineers who never hear stakeholder reactions stop seeing themselves as connected to the business.
The summary
Stakeholders aren’t enemies. They’re the source of the work, and they need a competent translator between their language and the team’s. The translator’s job is the EM’s job. Do it deliberately:
- Restate ambiguous statements in both languages before agreeing.
- Recognise the five personalities and use the structural fix for each.
- Send a weekly written update so anxiety doesn’t turn into ad-hoc pings.
- Make trade-offs visible — protect the team’s capacity by exposing what would have to be cut, not by saying no.
Done well, stakeholder management isn’t a tax on the EM’s time. It’s the highest-leverage thing they do all week, because every other piece of engineering output flows through it.
Sprint goals, scope changes, and stakeholder updates all in one place? SprintFlint tracks the goal, captures every scope change against it, and produces a written sprint summary at the end automatically. Try it free — 300 tickets, no card.