Your team already has the org-change playbook — the worked recipe for drafting a change announcement, a rollout plan, and a manager FAQ for one specific situation. This module is the layer above the recipe. It’s where you master the thing the recipe can’t teach: the judgment about who hears what, in what order, from whom — so the change lands instead of detonates — build the full rollout arc for a real or sample change, and prove, against a real rubric, that you can run it.
It’s Module 5 of the certifiable People & HR track — the Stage 3 orchestration module. Everything in M1 through M4 feeds into this one: the role clarity you built in M1 is what makes the new structure legible to the people absorbing it; the hiring integrity from M2 is what makes the internal promote credible; the onboarding structure from M3 is what you run when someone steps into a new scope; the review discipline from M4 is where the effects of this change surface six months later. A change landed badly breaks all of those downstream. A change landed well reinforces them.
An org change doesn’t fail in the announcement. It fails in the 48 hours after — when the two people who applied for the head role find out from Slack at the same time as everyone else, when the all-hands goes out and the manager doesn’t know the answer to the first question their team asks, when the FAQ covers the official questions and nobody raised the actual ones. The rollout is the thing. The message is just what the rollout carries.
Why the sequence is the highest-leverage decision you’ll make
This is the insight most HR practitioners know intellectually and underinvest in practically: the sequence — who hears what, from whom, in what context, before it goes wider — determines whether a change lands or detonates, independent of how well the message is drafted. An announcement is a decision dropped into a room all at once. A rollout sequences the conversations so the people most affected hear it first, from the right person, with space to ask the questions they’d actually ask, before the public message confirms what they already know.
The failure mode is specific and common. The all-hands email goes out at 9am. Two people who applied for the head role and didn’t get it read it at the same time as everyone else. They start a DM thread before their manager has said anything. The manager, caught flat-footed, does their best — but they’re improvising a conversation nobody prepared them for, in response to two people who’ve had 45 minutes to form an interpretation. That’s not a communication failure. The message was probably fine. It’s a sequencing failure: the people most affected heard it last, from the company, not from the person who made the decision.
The sequence is the thing you build before you write a word of the announcement. Three tiers:
- The people most affected hear it first, in a 1:1, with space for questions. For Mizan’s CX restructuring: Nadia hears about the promotion first, in the offer conversation. Then the two CS generalists who applied hear it — in separate 1:1s, with their manager present for the harder one — before any wider communication goes out.
- Managers who report into the change get the enablement pack before the announcement. They need to know what happened, why, what they’re authorized to say, and what they should not say — before their team asks them. The pack is not optional; a manager winging it in response to a disappointed direct report is the highest-risk moment in the whole rollout.
- The company-wide message goes out only after those conversations are done. Not before. Not simultaneously. After.
The craft Claude brings to this is speed — it drafts each version of the message, the FAQ, and the talking points in minutes, in the Desktop chat with the context you give it. The mastery is knowing that the sequence is the architecture those messages slot into, and that no amount of good drafting fixes a broken sequence.
The narrative for three rooms — leading with the problem, not the org chart
Most change communications fail at the first sentence. “We are restructuring our customer-facing functions to better align with our go-to-market strategy” — nobody knows what that means, nobody feels anything about it, and the person reading it immediately starts pattern-matching on what it might mean for them. The narrative that works leads with the problem it solves, the solution, and what it means specifically for the person in this room.
Three rooms means three primary questions, three narratives:
- The affected individual: their primary question is “what does this mean for me?” — specifically, for my role, my reporting line, my day-to-day. The narrative for Nadia is the offer conversation: the decision, the reasoning, the scope of the new role. The narrative for the two generalists who applied is harder — it has to acknowledge the decision directly, not elide it, explain the reasoning without making it a comparison exercise, and open a real conversation about their future, all in one 1:1 that they are probably dreading as much as the manager is.
- The manager pack: their primary question is “what do I say when someone asks me the hard question?” — not the official question, but the real one. The pack doesn’t leave managers to improvise. It gives them the Q&A for the three questions they’ll actually face, what to say and what not to say, and an explicit invitation for their team to come back with more. (The next section is the full craft of building that pack.)
- The all-hands: their primary question is “why is this happening and what does it mean for how we work?” The all-hands is not the place for individual specifics. It’s the place for the problem-solution narrative, clearly told. The Mizan all-hands version leads with the pattern they’d been watching — clients who had a great setup call with CS would then get a separate implementation call where the team re-learned what had already been agreed — before it names the solution. The org chart comes last, not first.
Claude drafts all three versions fast. Give it the context — the problem, the decision, the people involved, the org you’re writing for — and it generates each version in the Desktop chat, one prompt per room. The mastery is recognizing which version belongs in which room — and that the individual version and the all-hands version cannot be the same document, no matter how clean the all-hands is. The individual version has to be specific enough to feel like a conversation, not a broadcast; the all-hands has to be general enough to be fair to everyone who didn’t have that conversation with you first.
The manager pack — the Q&A nobody prepares
Managers don’t naturally know how to hold space for a direct report who applied for a role and didn’t get it. The instinct is to avoid the hard questions, keep it general, or say something well-meaning that doesn’t actually help. “I think you’re amazing and this doesn’t reflect on you at all” — generous and useless. It doesn’t answer the question the person is actually asking, and the person knows it. The manager pack is the document that changes that, because it makes the hard conversation preparable instead of improvised.
A pack that actually works is specific, not aspirational:
- The three questions people will actually ask. Not the official questions (“is the reporting structure changing?”) — those have clean answers. The questions people actually ask are: “Why wasn’t I chosen?” “Does this mean my role is changing?” “What’s my future here?” The pack gives the manager honest, specific answers to each. Not platitudes, not deflections, not “I’m not sure, let me check.” The answer to “why wasn’t I chosen?” is not “it was a very difficult decision” — it was, but that’s not an answer. The answer is what made the promoted person the right fit for this particular role and what the manager sees in this person’s future — specifically, not generically.
- What not to say. “I think you were robbed” is an empathy instinct that creates a lasting problem: you’ve just told someone they deserved something they didn’t get, which makes every day they work alongside the person who got it harder. “You’ll have your chance” is a promise you can’t keep. The pack names these explicitly, so the manager doesn’t reach for them under pressure at the moment they most want to be kind.
- The invitation to come back. The first conversation is not the end of the conversation. The pack ends with a script for closing: “I want to make sure we stay in this together — can we check in again in two weeks, same time, ten minutes at the end of our 1:1?” That sentence tells the person their manager is not managing them out of their feelings; the conversation is going to continue. It also sets up the earliest signal of whether the change is landing well or beginning to fracture.
Claude drafts the manager pack fastest of all three documents — give it the role, the decision, the reasoning, and the names, and it generates a complete Q&A in the Desktop chat in minutes. The mastery is reviewing it to make sure the answers are honest and specific enough that a real manager could deliver them in a real 1:1 without reading from the page — the test of a good pack is whether it survives contact with the person it’s about.
The sequence — the engineering, not just the list
The sequence is not a list of communications. It’s a dependency map: each step unlocks the next, and the order of operations is not interchangeable. Nadia has to know before the generalists, because if a generalist hears through the grapevine and comes to Nadia to ask (“is this true?”), Nadia has to be the one who already knew — not learning in real time from a direct report’s question. The manager pack has to be distributed before the announcement, because a manager’s first response to “what do you think of this?” cannot be “I just read the same email you did.”
The craft of a good sequence is timing: enough space between each tier for the conversations to actually happen, but not so much that information travels on its own before the next tier is reached. For a change the size of Mizan’s CX restructuring, the window is three days — not three weeks, which would leak, and not three hours, which wouldn’t give managers time to absorb the pack and prepare. Each step in the sequence names the owner, the channel, and the timing, and the dependency logic belongs in the document — not assumed.
- Day 0 — CEO and Nadia, 1:1 offer conversation. This is the one conversation where the announcement is also the decision. Nothing is sent before this happens.
- Day 1 — Nadia is told; then the two CS generalists who applied (separate 1:1s, Omar present for the second). The manager pack is previewed with Omar before the second conversation so he can hold it with confidence.
- Day 2 — Manager pack distributed to Omar and the implementation manager. They have 24 hours with it before anything goes wider. Questions go to the CEO.
- Day 3 — Company-wide: the all-hands message (Slack) at 9am, all-hands call scheduled within 48 hours for live Q&A.
- Day 14 — First check-in: each manager asks in their regular 1:1 cadence. Summary to the CEO by end of day.
The sequence document is one page — not a project plan, not a Gantt chart. Five to seven rows, each naming the who, the what, the channel, the when, and the person responsible for the conversation. Claude drafts it in minutes once you’ve described the change and the people. The mastery is reviewing it against one question: if I were the most affected person in this change, is this the sequence that would make me feel like someone thought about me first, not last?
The feedback loop — closing the gap
A change that’s announced and never revisited sends a signal: leadership said what it needed to say, the change is done, and they’re not interested in how it’s landing. The gap between “what leadership said” and “what the team heard” is real and predictable — it’s not a communication failure, it’s a calibration gap, and the only way to close it is to ask. The feedback loop is the mechanism that asks, on a schedule, with a named owner, and does something with the answer.
A loop that actually works is specific, not open-ended:
- A specific question, not an invitation. “Let me know if you have questions” is an invitation to not say anything — it puts the burden on the person who’s already uncertain about what it’s safe to say. “In our 1:1 next week, I want to spend ten minutes on how the new structure is working for your team” is a question that gets answered. The difference is who carries the initiative: the loop carries it, not the person who might be quietly struggling with the change.
- A specific cadence. Two-week check-in: how is the new structure landing — is coordination easier or harder? Are there gaps in who owns what? Four-week check-in: is the narrative leadership told matching the day-to-day reality? What’s the one thing that isn’t working yet? The four-week question is where the real answer usually lives — two weeks out is still in the adjustment; four weeks out is when structural problems become visible because people have stopped waiting for them to resolve on their own.
- A specific owner and a specific next step. The manager collects the answer, but it goes somewhere — not into a 1:1 that the change owner never hears about. The loop closes when the person who made the decision (in Mizan’s case, the CEO) gets a one-paragraph summary from each manager at the two-week mark: what the team said, and what — if anything — needs to be adjusted. That summary is not optional. It’s the thing that turns the rollout from an event into a process, and the thing that catches the structural problem before it becomes a resignation or a client escalation.
The feedback loop is the document most teams skip because it feels bureaucratic after the announcement is done and the moment has passed. It’s also the document that catches the implementation handoff that still doesn’t have a clear owner, the CS generalist who is quietly updating their profile, the finance team who still doesn’t know who to call when they have a CX question — before any of those become a surprise. Build it with the same discipline as the rest: specific, owned, with a defined cadence, not aspirational.
Your assignment
Build the three rollout documents for one org change — your own (recommended: the output is real infrastructure your team actually deploys) or the sample company Mizan, whose CX restructuring is worked through in full in this module. Open the relevant context — the org chart, the role descriptions, any prior communications about the change — in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat. No terminal needed.
Module 5 deliverable — the org change rollout
1. org-change-narrative.md (two pages)
- the affected-individual message: names the decision directly, explains
the reasoning without making it a comparison, opens a specific
conversation about their future, invites questions
- the manager pack: the three hard questions with specific, honest answers;
what not to say and what to say instead; the closing invitation
- the all-hands announcement: leads with the problem, not the org chart;
names the solution and what it means for how the team works
- Arabic version of the all-hands and manager pack: authored for the
Gulf-Arabic reader (not translated from English)
2. rollout-sequence.md (one page)
- five to seven rows: who hears it, from whom, in what channel, when
- the dependency logic: why this order, and what each step unlocks
- the owner named for each conversation
3. feedback-loop.md (one page)
- the 2-week check-in: specific question, owner, what happens with the answer
- the 4-week check-in: the deeper question, who sees the summary
- the signal that closes the loop (what the change owner receives and acts on)
Arabic-first teams: the all-hands and manager pack must be authored in Arabic —
Gulf-natural register, not translated. Western numerals, Arabic narrative.How it’s graded — the rubric
This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.
Module 5 rubric
1. The narrative leads Not "we are restructuring" — the reader knows
with the problem what's changing and why in the first paragraph.
The problem is named; the solution follows it.
The org chart is not the opening move.
2. The sequence is right The most affected people hear it first, from the
right person, in a 1:1, before the announcement.
Managers have the pack before the all-hands goes
out. The dependency logic is named, not assumed.
3. The manager pack The Q&A covers the hard questions — why wasn't
is honest I chosen, what's my future here — with specific,
non-platitudinous answers a real manager can say
in a real 1:1 without reading from the page.
4. The feedback loop Specific timing, specific question, specific owner,
is real specific next step. The answer goes somewhere.
Not "let me know if you have questions" — a named
date, a named question, a named recipient.
5. The Arabic version The all-hands and manager pack exist in Arabic,
is authored authored for the Gulf-Arabic reader — not
translated. Register is natural; numerals Western.The bar, shown — a worked model answer (Mizan)
You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample company — yours doesn’t need to look like this, it needs to clear the same bar.
org-change-narrative.md — Mizan, all-hands version (excerpt)
We've been watching a pattern for six months: clients who had a great setup
call with the CS team would then get a separate implementation call where we'd
re-learn what had already been agreed. That handoff was confusing for clients
and frustrating for both teams. We're fixing it.
Starting next week, CS and implementation are one unified Customer Operations
function, and Nadia — who's been running CS for two years — is its head. Your
point of contact doesn't change; the coordination behind the scenes gets better.
What this means for you:
- Finance team: you'll have a named CX contact for your account questions —
no more figuring out who to ask
- Dev team: the integration work you hand off now has a named function to
receive it — Khalid's replacement onboards into that structure from day one
- CS / implementation team: you'll have a structure, a head, and a shared
brief — we'll do a team session this week to walk through what it means
day-to-day
We're holding an all-hands on Thursday to answer questions. Bring them.rollout-sequence.md — Mizan CX restructuring
Day 0 CEO → Nadia 1:1 / offer conversation. Nadia is told before
anything else happens. No written confirmation
until she accepts.
Day 1 CEO → generalists Two separate 1:1s. Omar present for the second.
(the two who applied) The decision is named directly; the reasoning
is given; their future is a specific conversation,
not "we'll talk about it." Manager pack previewed
with Omar before the second conversation.
Day 2 Manager pack → Distributed to Omar + implementation manager
managers by 10am. They have 24 hours to absorb it and
prepare before anything goes wider. Questions
go to the CEO directly.
Day 3 Company-wide Slack message (all-hands narrative) at 9am.
announcement All-hands call scheduled for Thursday.
Day 14 Manager check-in Each manager asks in their regular 1:1: "How is
the new structure working for your team?" One-
paragraph summary to CEO by EOD same day.
Day 28 Deeper check-in "What's the one thing that isn't working yet?"
Answer feeds into a 30-min retrospective with
Nadia + CEO; adjustments made if needed.org-change-narrative.md — Mizan, manager pack FAQ (excerpt)
Q: Why was Nadia chosen and not [name]?
A: This was one of the hardest calls we've made. [Name] has strong client
relationships and we'd like to find a role that grows in that direction.
Nadia had both the CS experience and two years of context on the
implementation side — she'd been working across both informally for six
months. That crossover was the deciding factor, not a comment on [name]'s
ceiling.
What not to say: "I think you were robbed." / "You'll have your chance."
Both are generous and create problems — the first makes every day
alongside Nadia harder; the second is a promise you can't keep.
Q: Does this change my role?
A: Your day-to-day doesn't change. Your title stays the same. What changes
is that you now have a clear reporting line — into Nadia, as head of
Customer Operations — instead of the informal split across CS and impl.
That's a cleaner structure, not a demotion.
Q: What's my future here?
A: I want to be specific about that, not generic. [Name] has [specific
strength you name]. I'd like us to map out what a role that plays to
that looks like in the next six months. Can we use our next 1:1 for that?
Closing:
"I want to make sure we stay in this together. Can we check in again in
two weeks — same time, ten minutes at the end of our 1:1?"What you’ve proven — and what’s next
Clear the rubric and you’ve done what the first four modules were building toward: a complete org change, from narrative to sequence to feedback loop, demonstrated against the same bar a senior HRBP would hold. That’s the Stage 3 completion of “Certified People & HR with Claude.”
From here the track closes with one thing:
- The capstone: one complete people initiative — an org change, a restructured hiring process, a new onboarding program for a new function — taken from problem to rollout to 30-day assessment, graded end to end, in English and Arabic. The capstone is the credential: pass it and you receive the certificate.
Before you start the assignment, the operating guide is the layer that goes underneath all five modules — the confidentiality rules for people data, the approval gates for anything that touches compensation or role classification, and the data-handling standard an HR function running Claude inherits across every task, not just this one.