07. Release communication¶

Versioning is the artefact substrate. Communication is the human discipline that wraps each release. Stakeholders informed before, during, and after — the discipline that prevents the chapter-1 "surprise erodes trust" failure.

A platform engineer at a Mumbai SaaS company ships a model migration without notice. Customer-success teams field calls the next day: "the assistant seems different; what changed?" The customers had not been told; the customer-success team had not been told; the change was technically correct (eval passed, canary held, feedback profile stable) but the human dimension was missed. The team adopts a release communication discipline: stakeholders informed before, status updates during, summary after. The next migration produces zero "what changed?" calls because everyone who needs to know, knew.

This chapter is the communication discipline.

The three audiences¶

Audience	Cares about	Timing
Engineering team	What is shipping, when, who owns	Daily
Customer-facing teams (PM, support, success)	User-visible changes, what to tell customers	Weekly
Customers	Material changes affecting their experience	Per-release, for material changes

Each audience has different needs and time horizons.

Pre-release communication¶

Before the release ships:

Engineering channel. The change is announced in the team's standing channel — what is changing, when the canary starts, what the rollback looks like.
Customer-facing teams. For material changes (a new model, a feature change), the PM and customer-success are informed in advance with talking points.
Customers. For material changes (changes the customer will notice), the customer is informed with timing and what to expect.

The notice gives time for questions, preparation, and pushback. A change announced 24 hours before shipping respects the audience; one announced after produces the chapter-opening calls.

During-release communication¶

As the canary runs:

Engineering channel. Status updates at each canary step — promoted to 25%, metrics holding, etc.
Customer-facing teams. Updates if material; usually quiet during expected canary.
Customers. Quiet during expected canary; communicated if rolling back.

The during-release communication is mostly internal; the discipline is to keep the team informed of the rollout's progress.

Post-release communication¶

After 100% promotion:

Engineering channel. Release summary — what shipped, what the canary metrics looked like, any lessons.
Customer-facing teams. Material changes are summarised; the talking points are updated.
Customers. Material changes are noted (often in a release notes page, sometimes in product communication).

The post-release communication closes the loop. Stakeholders know the release happened, how it went, what changed.

What "material change" means¶

Not every release warrants customer communication. A material change is one the customer will notice:

A model migration that may shift tone or behaviour
A new feature or significant capability change
A change in cost (if customer-pricing is affected)
A change in availability (e.g., privacy zone change)
A change driven by regulatory compliance the customer should know about

Non-material changes (prompt tweaks, internal refactors, performance improvements) do not need customer communication. They go in the change log; the customer is unaffected.

The communication templates¶

For consistency and ease, templates per change type:

Internal release announcement:

Release: Model migration smart-reasoner from sonnet-4-5 to sonnet-4-6
Owner: platform-team
Canary: 2026-05-27 starting at 5%
Eval: passed, scores +0.02 overall
Risk: low; previous migrations of this size have gone smoothly
Rollback: route weight to 0, < 10 minutes
Contact: jane.doe@example.com

Customer-facing announcement (material):

Subject: Update to our AI assistant

Between [date] and [date], we are upgrading the AI model behind your
assistant. You may notice slightly different phrasing in responses;
the underlying decisions and capabilities are unchanged or improved.
We have tested the upgrade against our quality benchmarks and will
roll back if we observe any issues.

If you have feedback, please contact [support].

Templates can be customised per release; the structure is consistent.

When the release does not go well¶

If the release encounters issues:

Engineering channel. Immediate update on the issue, the action, the timeline.
Customer-facing teams. As soon as the issue is confirmed, with what to tell affected customers.
Customers. For material customer-facing issues, communicate honestly — what happened, what you are doing, when you expect resolution.

Silence during an incident erodes trust faster than honest disclosure. The discipline is to communicate even when the news is not good.

Common mistakes¶

Silent releases. No pre-release notice; customer-facing teams blindsided.

Material release with no customer notice. The chapter-opening case.

Over-communicating non-material releases. Customers get fatigued; future material notices are ignored.

Incident silence. Issues during release; team handles internally without telling stakeholders; trust erodes when the issues become visible.

Templates not maintained. Each release reinvents the wheel; quality varies.

Interview Q&A¶

Q1. Why is pre-release communication necessary for material changes? Because surprise erodes trust faster than any technical issue. A customer hearing "the AI assistant changed yesterday" from their own observation feels less safe than one who was told in advance. The pre-release notice respects the stakeholder; it sets expectations; it invites pushback if the change is wrong. The communication is not optional for material changes; it is the human discipline that complements the technical discipline. Wrong-answer notes: "the change is technical, customers don't need to know" misses that the customer experiences the change.

Q2. What is the difference between material and non-material changes for communication purposes? Material: customer will notice. Examples — model migrations affecting tone, new features, capability changes, cost changes, privacy changes. Non-material: customer will not notice. Examples — internal prompt tweaks, performance improvements, refactors. Material warrants customer communication; non-material goes in the change log. The distinction prevents notice fatigue (customers ignoring all notices because most are about things they cannot perceive). Wrong-answer notes: "communicate everything" produces fatigue; "communicate nothing" produces surprise.

Q3. The release encounters issues at 25% canary. What goes into the communication? Internal: immediate status — issue confirmed, action being taken (hold or rollback), timeline. Customer-facing teams: as soon as confirmed — what affected customers may notice, what to tell them. Customers: depending on impact — if affected, communicate the issue, the action, the timeline; if the issue is contained within the canary (rolled back without broader impact), often no customer-facing communication needed. The discipline is "communicate honestly and proportionally; do not be silent when impact has occurred." Wrong-answer notes: "fix it before communicating" produces silence that erodes trust.

Q4. The team has shipped 30 changes this quarter. The communication discipline says material gets customer notice; non-material does not. What is the test for "material"? Will the customer notice? Either positively (a new capability) or negatively (behaviour change, cost change). If yes, material. If the change is internal (a refactor, a performance improvement that does not affect latency the customer perceives), non-material. The test is "will the customer's experience change visibly"; if yes, communicate. The test is subjective; the team's discipline is to err on the side of communication for borderline cases, with the volume kept low enough that customer attention is preserved. Wrong-answer notes: "all prompt changes are non-material" misses that some prompt changes shift tone visibly.

What to do differently after reading this¶

Establish communication templates per change type.
Pre-release notice to engineering and customer-facing teams; to customers for material changes.
During-release status updates internally; customer notice for material rollbacks.
Post-release summary internally; customer-facing for material releases.
Communicate honestly during incidents.

Bridge. Communication is the per-release discipline. Change windows and freeze periods are the broader operational discipline that governs when releases happen at all. → 08-change-windows-and-freezes.md