User-Side Leadership for an Enterprise Endpoint Protection Migration
Phased rollout completed with minimal disruption; user-facing guidance authored start to finish
The situation
The organization committed to an enterprise endpoint protection migration. The technical plan covered servers, agents, and policy configuration. The user-side plan didn't exist.
This is a pattern with a name. IT teams define success through backend metrics — agents deployed, policies enforced, compliance boxes checked. The human layer gets treated as a delivery detail rather than a project deliverable. No owner. No budget line. No communication plan.
The consequence is predictable and well-documented. Users encounter the change mid-task — a blocked application, an unfamiliar security prompt, a machine that feels slower than it did this morning — with no mental model for what happened or why. Their first instinct isn't "new endpoint protection agent." It's "IT broke something." The help desk phones before IT can get ahead of it.
The timing made this worse. Organizations absorbing multiple back-to-back tech changes face a compounding dynamic: the average employee now navigates twice as many planned changes as they did a decade ago, and willingness to support those changes has dropped by half. By the time this migration landed, the staff's tolerance for unannounced disruptions was already thin.
Without user-side planning, every department would discover the change at the same moment, in the same way. Help desk volume would spike without a runbook to absorb it. Trust in IT would take another hit. And the shadow IT problem the migration was meant to address would quietly get worse — because users who feel blindsided by security tools find workarounds.
What I led
User-side support for the migration, end to end. The work started before a single agent was deployed.
Department mapping. I identified which teams used applications most likely to trigger false positives or agent conflicts, and sequenced the rollout accordingly — lowest-risk departments first, highest-complexity last. The goal was controlled exposure: contain the first wave of help desk volume, learn from it, and adjust before the next one hit.
Pre-launch communication. Research is consistent on this: key messages need to be delivered through multiple channels, repeated across multiple touchpoints, before a change lands. A single email the day before isn't communication — it's a timestamp. I built a simple communication schedule: manager briefings a week out, department-level notices 72 hours prior, a plain-English FAQ published to the intranet before anyone's machine updated. The FAQ was written the way users actually ask questions — not "endpoint protection agent deployment" but "what's happening to my computer and when."
End-user guidance. Each department received documentation scoped to what they would actually see: which applications might behave differently, what a legitimate security prompt looked like versus something to report, and a single point of contact for questions that didn't fit the FAQ. The materials were written assuming zero prior context. They didn't explain the product. They explained what would happen, when, and what to do about it.
Help desk runbooks. Before the first rollout window, I briefed tier-1 support and gave them a reference document covering the predictable wave of calls: performance questions during initial scans, false positive reports on specific applications, and escalation paths for anything that required an agent exclusion. The goal was to keep tier-1 handling tier-1 volume without escalating unnecessarily.
Rollout alignment. I coordinated directly with the technical leads to ensure documentation was ready before deployment, not retrofitted after. If the runbook wasn't finished, the rollout window moved.
What changed
Disruption — kept minimal across the rollout windows, with no department-wide productivity events Help desk volume — surged within predicted bounds; the tier-1 runbooks absorbed most of it without escalation User trust — staff received guidance before the change reached their machines, which shifted the experience from "IT did something to me" to "IT told me this was coming" Repeatability — the communication templates, rollout sequencing approach, and runbook structure became the baseline for future technology rollouts
The lesson
The Prosci change management research puts a number to this: projects with excellent change management are nearly seven times more likely to meet their objectives than those without. A 7x difference on outcomes, traceable in large part to whether anyone planned for the human layer.
An endpoint protection migration that skips user communication doesn't fail to deploy — it deploys, and then generates weeks of cleanup. Help desk tickets that didn't need to exist. Trust erosion that takes months to recover. Shadow IT workarounds that undermine the security posture the migration was supposed to improve.
A migration plan that ignores end users is half a plan. The technical work matters. The communication, sequencing, and documentation matter as much. Skip them and you trade a clean rollout for a month of cleanup.