10. Stakeholder management¶

The technical work is on track. The modernisation succeeds or fails on the strength of its stakeholder communication. The PM, the customer, the on-call, the executive — each has different needs from the same work. This chapter is the discipline of telling four versions of the same story to four audiences without losing coherence.

A tech lead at a Chennai SaaS company is six weeks into a modernisation of the customer-support agent. The eval is up; prompts are in the registry; observability is live. The PM is anxious because no new feature has shipped in six weeks. The customer-success lead has had two customers ask "is the agent getting worse?" — the customers were not seeing a regression, but the asking is itself a problem. The on-call has been quiet; she has not had a model-related page in two weeks but is not sure if that means things are better or if the dashboard is missing something. The executive sponsor asked yesterday "when can I tell the board the AI roadmap is solid?" Four people, four messages, all about the same work. The lead spends an hour the next morning writing four different one-paragraph updates and posting them in four channels. By the end of the week, the anxiety has eased on all four fronts. Nothing technical has changed in the system; the communication changed.

This chapter is the discipline behind that hour. Knowing what each audience needs to hear and saying it consistently is half the work of a modernisation. Skipping it produces technical wins that nobody believes in.

The four audiences¶

The chapter-opening list — PM, customer, on-call, executive — covers the four roles you communicate with regularly. Each has different priorities and a different time-horizon.

Audience	Cares about	Time-horizon
PM	New features, predictable delivery, user impact	Sprint to quarter
Customer	Reliability, what is changing, what to expect	Right now
On-call	Incident readiness, what to expect, how to escalate	Right now to next week
Executive	Strategic posture, risk, defensible commitments	Quarter to year

A single message that tries to address all four ends up addressing none. Tailor.

Talking to the PM¶

The PM's question is "when do we ship the next feature?" The honest answer during modernisation is sometimes "we are doing structural work to make feature shipping faster and safer." That answer is more credible when paired with:

A clear date for when feature work resumes
An honest account of what features are blocked and which are not
A list of capabilities the modernisation unlocks — the PM can plan around these

A reasonable weekly update to a PM during modernisation:

This week's modernisation progress:
- Prompts now live in the registry (migration complete)
- Eval coverage up from 0% to 60% of known failure modes
- Model migration to claude-sonnet-4-6 underway, canary at 25%

Features we can resume in the next two weeks:
- Improved tone in support responses (waiting on prompt registry — now unblocked)
- Multi-language support exploration (waiting on eval — now unblocked)

Features still gated:
- New decision-tree feature (waiting on context-builder modernisation, ETA 4 weeks)

Risks to flag:
- claude-3-opus deprecation in 60 days; migration in flight; on track

Five short sections; readable in two minutes; honest about both progress and remaining gates. The PM can plan; the lead does not have to repeat themselves.

Talking to the customer¶

The customer wants stability and clarity. The wrong messages: "we are rewriting everything," "the AI is getting smarter," "do not worry." The right messages: specific, conservative, falsifiable.

Three patterns.

Quiet stability. For most modernisation work, the right customer-facing message is no message. The system has not changed visibly; do not advertise structural work that will not affect them.

Limited improvement signalling. When a change does affect them positively — a previously frequent failure mode now resolved — a small note that names what changed and why is appropriate. "We addressed an issue where the agent occasionally surfaced internal codes in its responses. You should see cleaner messages now." Specific, conservative, easy to verify.

Honest disruption notice. When a model migration may cause a perceptible behavioural change (different word choices, slightly different formatting), tell the customer in advance with examples. "Between dates X and Y we are migrating to a newer model. You may notice slightly different phrasing in agent responses; the underlying decisions are unchanged. Contact your account rep with questions."

Two anti-patterns to avoid:

"It's all new and improved." This raises expectations without specificity; if the customer notices a regression next week, the trust deficit is large.
Silent migration of perceptible changes. If the customer will notice, tell them. The customer who notices an unannounced change feels less safe than the customer who sees a planned change land on schedule.

Talking to the on-call¶

The on-call's questions are practical: what is changing, how will it page, what are my next steps if something breaks?

A useful update to the on-call channel before a significant modernisation step:

Heads-up: tomorrow we promote claude-sonnet-4-6 to 50% of smart-reasoner traffic.

What to expect:
- Latency may shift slightly (baseline 712ms p95 → expected ~700-740ms)
- Fallback chain remains: cross-region anthropic, then openai gpt-4o
- Eval score is at 0.86 on the new model (current: 0.85)

If you get paged:
- Check the per-model dashboard: <link>
- The flag to roll back is in <runbook link>
- Page <name> for AI-specific incidents this week

Four sections; the on-call knows what is happening, what changes, where the controls are, and who to escalate to. The change is not a surprise.

A weekly update to the on-call should also include:

Which dashboards are most useful right now
Any recent alarms and what was learned
The next change scheduled and its date

The on-call's confidence in the modernisation comes from being informed, not from being protected from change.

Talking to the executive¶

The executive's question is "is the AI roadmap defensible?" The honest answer is rarely "we are done"; it is more often "here is what we have done, what we are doing, and the risks we are managing." The executive can absorb risk; what they cannot absorb is surprise.

A reasonable monthly update to an executive:

AI platform modernisation — month 2 of 3 update

Where we are:
- The system is operationally stable; no model-related incidents this month (last month: 4)
- Eval coverage now spans 80% of historical failure modes; CI-gated on regression
- Prompts and model versions are managed artefacts; changes go through review

Risks under management:
- claude-3-opus retiring in 60 days; migration in flight (50% canary, on track)
- Cross-tenant audit log gap identified; remediation planned for month 3
- Some upstream data sources do not have freshness SLAs; conversations with their owners scheduled

What this enables:
- Feature work resumes in week 9
- AI-related budget projections are now reliable (per-tenant cost attribution live)
- We can answer regulatory questions about data flow in minutes, not weeks

What we are still missing:
- Production-traffic eval (in-progress; ETA month 3)
- Full strangler migration of the context builder (large; multi-quarter)

Five sections; clear; honest about what is missing. The executive can defend the work and the timeline.

Two patterns that work for executive communication:

Lead with operational state, not technical state. "No incidents this month" is more useful than "the eval has 80% coverage." The executive cares about outcomes; the technical metrics are evidence.
Acknowledge what is not done. A list of "still missing" items is reassuring, not alarming. It signals that the lead knows the surface and has triaged. Pretending modernisation is complete when it is not is the trust-killer.

Saying what you do not know¶

Some questions during modernisation have no clean answer. The right response is to say so, then say what you are doing about it.

"Do customers notice the migration?" — "We are sampling production traffic into a comparison eval; preliminary signals say no perceptible change. We will know with confidence in two weeks."
"Is the new system better?" — "On the eval set, it scores 0.86 vs the old at 0.85. On production traffic, we are still gathering data."
"When will modernisation be complete?" — "The stabilisation work is on track for end of month 3. Structural work — context builder, data pipeline — extends to month 6. After that, we are in continuous-improvement mode, which is the steady state."

The stakeholder hears: lead knows the question, has a plan, will update with data. Better than "yes" or "no" when neither is honest.

The weekly cadence¶

A useful rhythm during modernisation:

Monday morning — short PM-facing update on last week's progress and this week's plan.
Tuesday or Wednesday — on-call channel update on any changes that week.
Thursday or Friday — customer-success-facing notes if any user-visible change is imminent.
First Monday of the month — executive update on overall progress.

Set the rhythm; keep to it. The cost is twenty minutes per audience; the value is sustained confidence in the work.

When stakeholder management gets harder¶

Three cases.

An incident during modernisation. The first model-related incident after a migration is a stakeholder event regardless of whether the incident was related to the modernisation. The honest response: "the incident was caused by X (not the modernisation, or yes the modernisation), here is the fix, here is what we changed to make this less likely next time." Transparent; specific; doesn't blame the modernisation if it is not at fault.

Slippage on a date you committed to. Sometimes a date moves. The right response is to communicate as soon as the slippage is known, with a new date and the reason. The stakeholder absorbs slippage better than they absorb silent slippage.

Pressure to ship features before modernisation is ready. This is the hardest case. The PM or executive wants the feature; you do not yet trust the system to ship it safely. The conversation is about risk, not modernisation: "the feature can ship now with these specific risks; or it can ship in three weeks with those risks substantially reduced. Here is what each path looks like."

Common mistakes¶

One message for all audiences. Each audience gets the wrong half of the message; nobody feels addressed.

Over-promising. "We will be done by X" without honest assessment of remaining work produces broken commitments.

Under-communicating. Silence during modernisation is read as either no progress or hiding something. Even short updates are better than silence.

Talking to one audience only. The PM is comfortable; the on-call is anxious; the executive is asking around. Cover all four.

Treating stakeholder communication as a chore. It is half the work of leading a modernisation. Skipping it is leaving the work uncomplete.

Interview Q&A¶

Q1. Six weeks into a modernisation, you have made no user-visible progress; the PM is asking why. What do you say? You frame the conversation around enabled capabilities and dates, not just structural progress. "In the last six weeks we built the eval backstop, moved prompts to a registry, and added observability. As a result, feature work resumes in week 7 with measurable safety; the alternative was shipping features blind for another quarter. Here are three features we can resume in the next two weeks and one that is still gated and why." The PM gets dates and capabilities; the work feels accountable. Wrong-answer notes: "we're building infrastructure" without dates and capabilities is the PM's frustration justified.

Q2. A customer asks "is the agent getting worse?" Their assessment is not supported by your metrics. What do you say? "Thank you for raising it. Here is what we measure: eval scores, latency, error rate, customer-impact metrics. None of them show degradation in the last two months. That does not mean your specific cases are fine — could you share an example? If there is a real regression on your cases, we will add it to the eval and prioritise the fix. If not, the perception may be from a different cause; we can investigate together." The customer feels heard; the lead has data; if there is a real issue, it surfaces; if not, the customer gets reassurance based on evidence. Wrong-answer notes: "the metrics say no" without offering to investigate is dismissive and erodes trust.

Q3. The executive wants a "single number" of how the modernisation is going. What do you give them? Two numbers, not one: incidents per month (operational outcome) and eval coverage of known failure modes (forward-looking signal). Combined, they tell the executive whether the system is stable today and whether it is becoming more defendable over time. A single number is misleading; "we hit 80% eval coverage" sounds good but does not capture incidents; "incidents went from 4 to 0" sounds good but does not capture future risk. Two numbers honest about both. Wrong-answer notes: picking a single proxy that flatters the work is the path to a board surprise.

Q4. You committed to a date that you now know you will miss. How do you communicate? As soon as you know. The format: "The X migration was scheduled for Y; new date is Y+2 weeks. The reason is Z (specific). The implications are W (which downstream work also shifts). The mitigation is V (interim coverage, communication to consumers, etc.)." The slippage is owned; the new commitment is dated; the implications are honest. The stakeholder absorbs this better than discovering the miss after the date passes. Wrong-answer notes: "we're a little behind" without a new date is not communication; it is anxiety transferred.

What to do differently after reading this¶

Identify your four audiences explicitly. Plan a cadence per audience.
Write four versions of each significant update; one size does not fit four.
Lead with operational outcomes for the executive; with enabled capabilities for the PM; with specific changes for the customer; with operational changes for the on-call.
Communicate slippage immediately, with a new date and the reason.
Treat stakeholder management as half the work, not a chore. The technical work without the communication is a brittle modernisation.

Bridge. Stakeholder management is the practice that sustains modernisation over months. The final discipline is the structural plan that ties everything together: the new lead's first three months, sequenced explicitly. The next chapter is the 30-60-90 plan. → 11-the-30-60-90-plan.md