10. Stakeholder Communication — Same signal, different language¶

~16 min read. Strong engineering judgment fails quietly when stakeholders hear the wrong version.

Built on the ELI5 in 00-eli5.md. The crew — reminder that many people steer outcomes together — shapes how technical choices must be explained.

1) One decision, many audiences¶

Look. One architecture decision does not arrive in one audience. It lands in many cabins on the ship.

Product asks, "Will users feel the value, and when?" Legal asks, "What data moves, and who controls it?"

Finance asks, "What will this cost at small and large volume?" Execs ask, "Does this create leverage for the business?"

The engineering answer may be one sentence. The stakeholder explanation cannot be one sentence repeated everywhere. That would be technically consistent. It would still fail.

same decision
     │
     ├── product  ─→ user value + timeline
     ├── legal    ─→ data use + controls
     ├── finance  ─→ run cost + scale shape
     └── exec     ─→ business leverage + risk

See. Translation is not distortion. Translation is choosing the right window.

The compass stays the same. The words around it change. Simple, no?

2) Translate without mutating the truth¶

This is the key discipline. Do not tell different stories. Tell the same story with different emphasis.

Suppose the decision is, "Use retrieval before fine-tuning for the first release."

For product, you may say, "This gets faster iteration and fresher answers for users."

For legal, you may say, "This keeps source control clearer and reduces embedded data drift."

For finance, you may say, "This avoids early training spend and keeps scaling costs inspectable."

For execs, you may say, "This preserves optionality while proving business value sooner."

See the pattern. The course did not change. Only the translation changed.

Bad communication mutates the decision itself. Then the crew thinks different ships are sailing. That creates politics, not alignment.

3) Use tradeoff frames, not advocacy theater¶

Stakeholders do not need raw internal debate. They do need structured tradeoffs.

So what to do? Present choices with benefits, limits, and consequences. That is where RFCs help.

A useful RFC section can be very simple: - decision to make - options considered - tradeoffs by audience - risks and controls - recommendation and why now

┌────────────────────┐
│ decision to make   │
└─────────┬──────────┘
          │
          ├── option A: fast, weaker control
          ├── option B: slower, stronger control
          ├── option C: cheap now, costly later
          └── recommendation: choose one with reasons

Look. Stakeholder trust rises when they can see the rejected paths. Not every rejected path needs ten pages. But the reasoning should be inspectable.

That is the ship's log at communication level. It records why the turn happened. Not only that the turn happened.

Yes? A clean tradeoff frame lowers noise. It also lowers surprise later.

4) Worked example: one model choice, four translations¶

Suppose your team must choose between a larger model and a smaller one. The larger model answers better. The smaller one is cheaper and faster.

First, picture the shape.

larger model
   ├── better quality
   ├── higher cost
   ├── slower latency
   └── more headroom for complex tasks

smaller model
   ├── lower cost
   ├── faster latency
   ├── weaker long-tail quality
   └── easier broad rollout

Now translate. For product: "The smaller model reaches more users quickly, but quality drops on harder cases."

For legal: "Both options use the same data path, but the larger model may require stricter vendor review."

For finance: "The larger model creates steeper usage cost if adoption grows."

For execs: "The choice is between better flagship quality and wider near-term reach."

See. No distortion happened. But each audience hears the part they must act on.

The weather check belongs here too. Call out downside risk clearly. Do not hide it in appendix language.

5) Communication rituals that keep teams aligned¶

One good memo is not enough. Communication in AI work must repeat at decision points.

Use short rituals. Before sprint start, share the question, risk, and expected decision. After a spike, share evidence, tradeoff, and recommended next move.

During review, separate facts from assumptions. Label what is known. Label what is still probabilistic.

After a decision, write the ship's log entry. Capture owner, choice, rationale, and revisit trigger.

question ──→ evidence ──→ tradeoff ──→ decision ──→ ship's log

This rhythm helps the crew stay coordinated. Product hears impact. Legal hears controls. Finance hears scale implications. Execs hear leverage.

And engineering does not have to re-explain from zero each week. Simple, no?

Where this lives in the wild¶

Microsoft 365 Copilot rollout — product manager explains user-facing latency and drafting quality without burying the adoption plan in model jargon.
Enterprise contract review assistant — legal counsel needs a plain statement of data retention, review controls, and escalation paths.
Customer support bot expansion — finance partner wants usage-cost ranges before approving wider traffic.
GitHub Copilot enterprise adoption — engineering director frames code quality lift, governance needs, and rollout sequencing for executives.
Retail demand forecasting copilot — operations lead needs tradeoffs translated into staffing impact and override workflows.

Pause and recall¶

Why is translation for stakeholders not the same as distortion?
What does each audience usually care about first: product, legal, finance, and exec?
Why are tradeoff frames better than one-sided advocacy?
What should a ship's log entry capture after a decision?

Interview Q&A¶

Q: Why must the same technical decision be translated differently for different stakeholders? A: Because each stakeholder owns a different consequence of the decision. Communication works when the same truth is connected to each audience's responsibility.

Common wrong answer to avoid: "Because non-technical people cannot understand engineering" — the issue is consequence framing, not intelligence.

Q: What makes an RFC useful in AI engineering communication? A: It makes options, tradeoffs, risks, and recommendations inspectable. This reduces ambiguity and hidden assumptions.

Common wrong answer to avoid: "It gives leadership more detail" — detail alone is not the point; structured decision support is.

Q: Why should downside risk be stated explicitly in stakeholder updates? A: AI systems have uncertain behavior under scale and edge cases. Hidden risk later becomes broken trust.

Common wrong answer to avoid: "So nobody can blame engineering later" — protection politics is not the goal; honest coordination is.

Q: Why is repeated communication necessary after the initial decision meeting? A: Conditions change as evidence arrives. Stakeholder alignment decays unless the crew hears updated tradeoffs at each decision point.

Common wrong answer to avoid: "Because people forget quickly" — memory matters, but evolving uncertainty is the bigger reason.

Apply now (5 min)¶

Exercise: Choose one AI decision from your team. Write four versions of the same message for product, legal, finance, and exec. Keep the core truth identical. Change only the emphasis.

Sketch from memory: Draw the audience map from one decision to four translations. Then label where the compass, the crew, the weather check, and the ship's log appear.

Bridge. Clear words help a lot. Still, even perfect wording fails when people expect magic from probabilistic systems. → 11-managing-expectations.md