Nobody reads your rollout announcement

I have written exactly one change announcement I was proud of.

It went to about 4,000 people on a Tuesday morning. Two paragraphs, no jargon, a bolded deadline, one link, and a screenshot with a red arrow pointing at the button they needed to click. My manager forwarded it upward as an example of how this should be done. I felt like a professional.

Three weeks later I was on a 6am bridge call walking people through that exact button, and one of them told me she had never received the email.

She had. I checked. It was eleven messages down in her inbox, unread, sitting between a benefits enrollment reminder and an invite to a meeting that had been cancelled.

That was the week I stopped believing the writing was the problem.

Most of us learned change management when the hard part was technical. Could you build it, would it hold under load, did you have a rollback, had you cleared it with security. The tooling got good and those problems got easier. What's left is the part nobody staffed for: extracting one specific action from one specific human being who has 340 unread messages and a deadline of her own.

The cleanest experiment I know about

Somebody finally ran this properly, and the result deserves to be a planning constant rather than a war story.

An organization of roughly 10,000 employees and contingent workers was pulling Apple identities into managed, federated accounts: fifteen years of personal Apple IDs sitting on corporate email addresses, over 6,000 of them unmanaged. They started with the lowest-risk domain, a contractor domain, where Apple reported 743 unmanaged accounts. Everyone on it got a 30-day window to move themselves across using a self-service transfer that preserved their purchase history.

The communication was not sloppy. They pulled Google's mail logs to confirm exactly who had received Apple's automated transfer notices, then sent follow-up reminders only to those people instead of blasting the whole domain again. They chose the go-live date so the window's expiration would land on a Wednesday rather than a weekend, because Wednesday is when you have the most engineers and the most vendor support staff available on the day most likely to go sideways.

That second detail is the mark of someone who has been burned before.

63 accounts moved.

The baseline was 31, so a full month of careful, verified, individually targeted communication converted 32 people out of 743.

The bill came due on cutover day. Close to 1,000 developer and App Store Connect accounts had to be rebuilt by hand: new invite, correct role, team membership, certificates and provisioning profiles reassigned. Several minutes each. Six to ten people worked it for the entire day.

"A little too cautious"

The most valuable sentence in the story is the one the person who ran it said about herself afterward: in hindsight, she had been a little too cautious.

She had throttled her own communication on purpose. The company had several other large initiatives running concurrently, AI rollouts among them, and she did not want to add to the communication fatigue already in the air. So she kept the volume low and the tone neutral, and she laid the choice out fairly: transfer during the window, or do nothing and be issued a new managed account later. Two options, presented as equally valid.

Her retrospective judgment was that two minutes standing up in an engineering all-hands, or typing a direct recommendation into the developer chat channel, would have outperformed a month of tasteful email.

I think she's right, and I think the neutrality is the specific thing that cost her. Presenting two options as equally valid to someone with no context and no stake hands them a decision they never asked to make. They resolve it the way everyone resolves it, by closing the tab.

The word missing from most announcements is advocacy. Not "here is a change and here are your options," but "do this, by this date, and here's the ten seconds of reasoning." Restraint feels like professionalism. On the evidence it reads as optional.

The tone hypothesis dies here

If voluntary adoption were a writing-skill problem, blunter organizations would do better. They don't.

A merged city-county government IT org consolidating around 3,500 iOS devices onto a new MDM sent a 30-day notice about the account federation change. Largely ignored. They sent a 7-day forced-migration notice. Largely ignored too, by entire departments. Staff ended up telephoning individual users and walking them through a QR code fallback. Departments with a strong internal tech liaison finished in a couple of days. The ones without were, in their own words, the most painful thing ever.

A second org ran the same rollout, 2,000 users and a 30-day window, and got the same outcome.

The case that should settle it: a government cybersecurity and compliance team skipped the gentle framing and told staff flatly that this is a government email address, remove your personal data from it. No options, no hedging, pure compliance language. Reportedly the same low proactive adoption anyway.

Tone may matter far less than we assume, which stings, because tone is the lever we all reach for first.

Registration prompts are the purest case. A passwordless single sign-on rollout asks the user to notice a small prompt in the corner and click register. Admins report they ignore it, it goes away, they open their mail client, get asked for a password again, and file a ticket saying sign-on is broken. Others don't ignore it at all. They report it as a virus, or escalate it to security as a possible incident, which is arguably the correct instinct from a well-trained employee. And on an existing fleet there's usually no mechanism to force the registration at all. You can only ask.

Admins have a line about the operating system's notification tray, and I apply it more broadly than they mean it. Notification Center is where things go to die. Substitute any channel that needs the user to act and it still holds.

We did everything right and still broke something

Careful teams break things too, and never the part they were worried about.

After cutover, the identity team needed to distinguish two kinds of accounts: ones that had transferred voluntarily during the window, and ones the directory sync had just created fresh. They used account creation date. Reasonable thing to use. What they didn't know was that Okta's directory sync had silently overwritten the creation date on most of the existing managed accounts.

So they deleted and re-invited one engineer's account that had in fact transferred correctly, weeks earlier. That account was wired into a device-lab automation workflow, which broke on the spot. Caught fast, fixed fast, nothing production-facing. My favorite category of incident: every decision defensible, and one fact in the system nobody would have known to verify.

The other surprise was smaller and odder. A former contractor's personal recovery email address, still on file with Apple from years earlier, received the migration notifications. A confused ex-employee reached out to ask why they were suddenly getting notices about an old contractor account. Nobody's notification scope diagram includes the recovery address of someone who left in 2019.

Two habits worth stealing from teams that do a lot of these:

Watch pilot users attempt the procedure live. Consultants who migrate MDM platforms for a living are blunt about the documentation trap. If you produce documentation and you think everyone else is going to do exactly the same thing that you do, you're wrong. Guides get followed creatively. You learn that by sitting there while somebody does it, not by rereading your own doc.

Pilot with people outside IT. In one rollout, the marketing and creative teams surfaced real gaps in specific application versions that the IT testers had never hit, for the obvious reason that IT testers use IT software. A pilot drawn from your own team only proves the procedure works for people who already understand it.

People defer until something stops them

A macOS patch tool ships with a deferral limit: how many times a user can dismiss an update prompt before it stops asking. The product demo used 100. The real-world deployment example used 5. After the fifth deferral an auto-update fires with a visible 60-second countdown, then quits the app, updates it, and relaunches it.

Five, not a hundred. Somebody watched actual humans and worked out how many polite requests are worth making.

MDM migration consultants got there from a different direction. One consultancy built an internal tool that throws a full-screen, un-dismissable dialog, backed by a launch agent that re-triggers on reboot, purely to stop users from happily working on a Mac that's been unenrolled from the old MDM and not yet enrolled in the new one. Their reasoning is honest: once step one is done, the user has zero incentive to complete step two.

Nobody wants to be the team that ships a blocking dialog. Everyone who runs enough migrations ends up shipping one.

I resisted this for years. I thought hard deadlines and forced dialogs were what lazy IT departments did instead of explaining themselves, and I said so out loud to people with more scars than me who turned out to be right. What changed my mind was working out who actually pays for the long, gentle window. The people who ignore it are fine. Their accounts get rebuilt by somebody else, on a Wednesday, at no cost to them. The bill lands on six to ten people in a war room, and on one engineer whose lab automation died because a well-meaning team trusted a timestamp field that had been overwritten underneath them.

The ladder, in order

Most organizations plan the first two rungs and discover the last two under duress.

1. Soft notice. Broadcast email, announcement channel, intranet item. Buys you a record that you told people, useful in a postmortem. Budget zero behavioral change and you'll never be disappointed.

2. Targeted notice. Reminders to non-compliant people only, naming their specific account or device, verified against delivery logs so you know who genuinely got the first one. Better than broadcast. Still single-digit percentages.

3. Advocacy where the group already is. Two minutes, spoken or typed, from a named human, in the channel or recurring meeting these people already attend. With a recommendation instead of a menu. Most teams skip this rung, and it has the best cost-to-effect ratio on the ladder.

4. A dated deadline with a stated consequence. Not "please transfer at your convenience." On the 14th this account gets renamed and you'll be issued a new one. Short window, hard edge, said plainly, repeated.

5. A blocking interface. Full-screen dialog, forced restart, countdown timer, whatever your platform gives you. Only works on fleets you control, so find out early. On an existing fleet the answer is frequently no, which changes the whole plan.

6. A phone call. Expensive, effective, and where the government team ended up for thousands of devices. If your plan depends on this rung without admitting it, staff it in advance rather than discovering it at 4pm on a Friday.

One structural thing worth copying regardless of which rung you're on. The identity team ran two chat channels, split deliberately: one for announcements, one for support. That sounds like housekeeping. It bought them a rollout they could monitor and search in real time, an announcement thread that stayed readable instead of becoming 400 messages of "same here," and a support channel that doubled as a live record of which instructions were being misread.

What we're really protecting

The 30-day voluntary window is a comfortable fiction, and I'd like us to stop calling it generosity. It exists because it feels respectful and lets us say afterward that everyone got every chance. Both of those are about how the change makes IT feel.

A short window with a hard, well-communicated deadline is the kinder design. It ends when you said it would, on a day you staffed for, and nobody gets conscripted into a war room without warning.

Every other function solved the attention problem years ago. Marketing has known for two decades that reach and action are different numbers. Product teams instrument the whole path. We send one message to 5,000 people, confirm delivery in the logs, and mark it done, which measures our effort rather than anybody's behavior.

The change you're about to announce is competing with somebody's actual job, and their actual job is winning.

Plan like the announcement will lose.