The change communication — who needs to know, when, and how

A change without communication is a change that surprises stakeholders. The change goes out, the service degrades, the support team fields tickets, the customers see errors - and no one told them to expect it. The communication plan is the part of the change record that names who needs to know, when they need to know, and how they will be told. A plan in a Slack message drifts; a plan in the pull request description is part of the change record.

The four audiences

Every change has four audiences. Each needs a different message, at a different time, on a different channel.

flowchart LR
    C["Change"] --> A1["Operators: runbook and timing"]
    C --> A2["Stakeholders: business impact"]
    C --> A3["Customers: user-visible change"]
    C --> A4["Auditors: record of who-knew-what-when"]
    A1 --> CH1["Pre: PR + on-call channel"]
    A2 --> CH2["Pre: email + meeting"]
    A3 --> CH3["Pre: status page + release notes"]
    A4 --> CH4["Pre: PR description + CAB ticket"]

• Operators. The on-call team, the platform team, the service owner. They need the runbook, the deploy window, the rollback path. Channel: pull request comments, on-call channel.
• Stakeholders. The product manager, the customer success team, the leadership. They need the business impact, the customer-facing effect, the timing. Channel: email, standup, change-advisory-board.
• Customers. End users who see the change. They need a release note, a status page entry, a heads-up if the change is user-visible. Channel: status page, release notes, in-app banner.
• Auditors. Compliance, security, internal audit. They need the record: who knew what, when, and what was decided. Channel: pull request description, CAB ticket, change record.

A change record that omits any of the four audiences has a gap. The most common gap is the customers: a team that communicates internally but never tells users about a user-visible change.

Pre-change, during-change, and post-change

The communication plan has three phases. Each phase has a different audience and a different message.

flowchart TB
    P["Pre-change: T-24h"] --> D["During-change: T-0"]
    D --> POST["Post-change: T+1h"]
    P --> P1["Operators: PR + on-call ping"]
    P --> P2["Stakeholders: CAB + email"]
    P --> P3["Customers: status page scheduled"]
    D --> D1["Operators: deploy channel live"]
    D --> D2["Stakeholders: status update"]
    D --> D3["Customers: status page in-progress"]
    POST --> POST1["Operators: verification + close"]
    POST --> POST2["Stakeholders: outcome summary"]
    POST --> POST3["Customers: status page resolved"]

• Pre-change (T-24h). Operators get the PR linked in the on-call channel. Stakeholders get a CAB reminder. Customers see a scheduled status page entry.
• During-change (T-0). Operators run the deploy in the deploy channel, with live updates. Stakeholders see a status update. Customers see an in-progress status page entry if the change is user-visible.
• Post-change (T+1h). Operators post the verification result and close the deploy channel. Stakeholders see an outcome summary. Customers see a resolved status page entry.

The plan lives in the PR description. The deploy channel is created from the PR; the status page entry is linked from the PR; the CAB ticket is referenced in the PR. Every artefact the change generates is anchored to the same record.

Writing the communication plan in the PR

TITLE="Rotate payments DB primary key (Q3 schedule)"
BODY=$(cat <<'EOF'
## What
Rotates the payments DB primary key per Q3 rotation.

## Why
Q3 key rotation per security policy SEC-2026-08.

## When
Window: 2026-08-22 02:00-04:00 UTC.

## Who
Author: alice; Approver: bob; CAB: CHANGE-2026-119.

## Where
Cluster: payments-prod; namespace: db.

## How
Run rotation playbook; verify replicas connected;
rollback via snapshot restore.

## Communication
- Pre-change T-24h: PR linked in #oncall-deploys;
  email to payments-stakeholders; status page entry
  scheduled.
- During-change: deploy channel #deploy-payments-0822
  with live updates every 5 minutes.
- Post-change T+1h: verification summary in deploy
  channel; outcome email; status page resolved.
- Customer impact: brief 5xx spike during cutover;
  no extended outage expected.

## Rollback
Primary: snapshot restore via runbook RB-2026-119.
Fallback: failback to old primary via DNS switch.
Trigger: 5xx rate > 1% sustained 2 minutes.

Refs: #1234, CHANGE-2026-119
EOF
)
gh pr create \
  --title "$TITLE" \
  --body "$BODY" \
  --base main \
  --head feat/payments-key-rotation \
  --reviewer bob,carol \
  --label "change,production,key-rotation,comms-defined"

The communication section names the channel, the audience, and the timing for each phase. The deploy channel name is fixed in the PR; the status page entry is created from the PR; the email distribution list is in the stakeholder section.

Production discipline

1. The communication plan is a required section of the change record. A pull request without a communication section does not merge.
2. The four audiences are addressed. Operators, stakeholders, customers, auditors - each has a channel and a timing.
3. The deploy channel is created from the PR. A channel created from a Slack conversation drifts; a channel named in the PR is part of the record.

Cross-course references

• This course, Part LXIV (Auditability) - the audit chain the communication plan preserves.
• This course, Part XLVIII (Conditional deploys)
  • environment protection rules that gate the deploy job and integrate with status pages.
• Kubernetes for Production Sysadmins - Parts XXXVIII-XL (IncidentComms) cover the during-incident communication this lesson’s during-change phase overlaps with.

Quiz