Death by a Thousand Updates
No single change broke anyone. It was the fourteenth one this quarter that did it.
6 min read | IT Managers & Directors | IT Management & User Adoption
Nobody quits over one password reset. But another new login screen? Another MFA prompt? Another email announcing an "exciting update" to a system everyone finally figured out how to use?
At some point, even your most patient employees start wondering why everything needs to change all the time. And IT gets caught in the middle.
The team that just spent weeks helping everyone adjust to a new platform is already preparing for the next rollout. Meanwhile, the tickets keep coming, the same questions keep resurfacing, and employees are getting a little less enthusiastic about learning something new.
That's change fatigue, and it rarely comes from one bad rollout. It comes from too many perfectly reasonable changes happening too close together.
One rollout is a project. Two is a busy quarter. Five new apps, three workflow changes, a password policy update, and a surprise MFA prompt? Now it's something everyone is just trying to get through.
In This Article
Why change fatigue is a capacity problem, not an attitude problem
What the numbers reveal about how much change employees can absorb
Five ways IT can manage change without slowing progress
A change receipt that makes the hidden cost visible
The Math Nobody's Doing
Change fatigue often gets mistaken for resistance. Employees don't want to learn something new. They're frustrated with technology. They just need better training.
But what if the problem isn't their willingness to adapt? What if organizations are simply asking people to absorb more change than they realistically can?
67% | 101 apps |
1–2 changes |
Look at what those numbers mean together. Organizations are managing more applications, employees are expecting more disruption, and leadership teams are planning major changes that will require even more adjustment.
The problem isn't necessarily any one decision. A new platform might improve productivity. Updated security policies might be essential. A better ticketing system might save everyone time.
But employees don't experience those decisions separately. They experience all of them, sometimes in the same week, and eventually "it's just one more change" becomes the problem.
Why Support Feels It First, and the Worst
IT usually knows when change fatigue is setting in, even if nobody calls it that.
It's the employee who asks for help with the same workflow they've already been trained on. The person who gets frustrated over a routine MFA prompt. Or the familiar "Can you just do it for me?" because learning another process feels like more trouble than it's worth.
Sound familiar? These aren't always signs of poor training or difficult users. Sometimes people are simply tired of starting over, and that frustration doesn't disappear.
It lands in the help desk queue as more repeat questions, more access issues, and more time walking people through processes they understood perfectly well before the last update.
The frustrating part is that every individual change may have been handled correctly. Each department followed its rollout plan, training was provided, announcements went out, and IT was prepared. But nobody looked at what all those changes would feel like together.
We've previously covered how to prepare for the support demand that follows a technology launch in Go-Live Is Not the Finish Line. Change fatigue is what happens when you're managing that same post-launch demand for the fifth time in a quarter, while preparing for rollout number six.
The answer isn't necessarily a better rollout plan. It's making sure the organization has room for the next one.
Budgeting Change Like It's Actually a Budget
Nobody's suggesting organizations stop improving their technology. Security requirements evolve, business needs change, and outdated systems eventually need replacing.
But employee attention and IT support capacity aren't unlimited, and treating them that way creates problems long after the rollout announcement has been sent.
Here are five ways to manage both without bringing progress to a halt.
1. Give your organization a change budget, and enforce it like a real one
Most organizations track what they're spending on new technology. Far fewer track how many changes they're asking employees to navigate at once.
Start with a shared change calendar that includes major software rollouts, policy updates, migrations, and workflow changes across departments.
Before approving another implementation, look at what's already scheduled. If employees are facing a platform migration, a new ticketing portal, and an updated password policy in the same six weeks, does another rollout really need to happen right now?
Sometimes the most productive decision is moving something to next quarter. The goal isn't fewer improvements. It's giving each improvement a better chance to succeed.
2. Batch the small stuff instead of drip-feeding it
You know those emails that start with "We've made a few small changes"? Now imagine getting one every Tuesday for five weeks.
Even minor updates demand attention. Employees have to read the announcement, figure out what changed, and adjust how they work.
Rather than introducing every small update separately, establish predictable change windows for nonurgent improvements. One monthly announcement covering several minor changes can be easier to manage than a steady stream of surprises.
Security emergencies and critical fixes still need immediate attention, but not every interface adjustment deserves its own rollout.
3. Consolidate logins before you add another one
Another application shouldn't automatically mean another username, password, and authentication process. Yet that's often exactly what happens, and every additional login creates another opportunity for confusion, forgotten credentials, and support tickets.
Before introducing a new tool, evaluate whether it supports single sign-on (SSO) and integrates with existing identity management systems. If it doesn't, factor that additional friction into the purchasing decision.
For existing applications that can't be consolidated, an organization-approved password manager may help reduce the burden.
We've covered how seemingly simple access issues quietly consume support capacity. Multiply those issues across dozens of applications, and the impact becomes harder to ignore.
Every login you simplify is one less unnecessary obstacle between employees and their work.
4. Tell people where they are in the calendar, not just what's changing
Most rollout announcements explain what's new, why it matters, and when it takes effect. What they rarely explain is how it fits into everything else employees have already been asked to learn.
Consider the difference:
Typical announcement: "We're excited to announce another platform update!"
Better approach: "This is our fourth major technology change this quarter. We know there's been a lot to adjust to, and this is the last planned rollout before the holidays."
Same update, very different message. People are more receptive when they understand what's coming and when they can expect some stability.
You don't need another elaborate communication campaign. Sometimes one sentence acknowledging the bigger picture is enough.
5. Give people a way to say "that's enough" before they stop reading entirely
By the time employees stop opening update emails or attending training sessions, change fatigue has probably been building for a while. Don't wait until the complaints become tickets.
Give employees a simple way to flag what's becoming overwhelming. That might be a quick pulse survey after major rollouts, a standing Slack thread, or a few minutes during an existing team meeting.
Ask what's causing the most confusion, which processes still feel unfamiliar, and whether recent changes have actually made their jobs easier.
Then use that feedback to adjust upcoming rollouts. If three departments are reporting frustration with recent changes, that's information leadership should have before approving the next one.
It's a relatively simple way to catch problems before they turn into another wave of avoidable support requests.
The Change Receipt
Every change comes with a cost that doesn't appear on the software invoice. Time spent learning a new workflow. Productivity lost while familiar processes are replaced. Additional support tickets. Frustration that builds when employees feel like they're constantly playing catch-up.
None of those costs necessarily makes a new technology a bad investment, but ignoring them can make a good investment harder to realize.
We explored a related challenge in The Seventh Tab Problem: organizations can keep adding technology without necessarily getting more value from the tools they already have.
Change fatigue adds another layer to that problem. Even when every rollout is justified, the combined impact can leave employees exhausted and IT teams absorbing the consequences.
The question isn't whether your organization should keep improving its technology. It's whether you're giving people enough room to benefit from the improvements you've already made.
Because the fourteenth update might be the one that finally pushes everyone over the edge, even if there was nothing wrong with the update itself.
About the Author
Michelle Burnham has worked in and around the technology industry for nearly a decade; collaborating with IT support teams and contributing to technical documentation, service-oriented content, and operational communications. With a background in editing, formatting, and visual design, she specializes in translating complex ideas into clear, engaging content. In addition to her freelance creative work, she serves as a contract graphic designer, copywriter, and video editor for Helpt.
No single change broke anyone. It was the fourteenth one this quarter that did it.
6 min read | IT Managers & Directors | IT Management & User Adoption
Nobody quits over one password reset. But another new login screen? Another MFA prompt? Another email announcing an "exciting update" to a system everyone finally figured out how to use?
At some point, even your most patient employees start wondering why everything needs to change all the time. And IT gets caught in the middle.
The team that just spent weeks helping everyone adjust to a new platform is already preparing for the next rollout. Meanwhile, the tickets keep coming, the same questions keep resurfacing, and employees are getting a little less enthusiastic about learning something new.
That's change fatigue, and it rarely comes from one bad rollout. It comes from too many perfectly reasonable changes happening too close together.
One rollout is a project. Two is a busy quarter. Five new apps, three workflow changes, a password policy update, and a surprise MFA prompt? Now it's something everyone is just trying to get through.
In This Article
Why change fatigue is a capacity problem, not an attitude problem
What the numbers reveal about how much change employees can absorb
Five ways IT can manage change without slowing progress
A change receipt that makes the hidden cost visible
The Math Nobody's Doing
Change fatigue often gets mistaken for resistance. Employees don't want to learn something new. They're frustrated with technology. They just need better training.
But what if the problem isn't their willingness to adapt? What if organizations are simply asking people to absorb more change than they realistically can?
67% | 101 apps |
1–2 changes |
Look at what those numbers mean together. Organizations are managing more applications, employees are expecting more disruption, and leadership teams are planning major changes that will require even more adjustment.
The problem isn't necessarily any one decision. A new platform might improve productivity. Updated security policies might be essential. A better ticketing system might save everyone time.
But employees don't experience those decisions separately. They experience all of them, sometimes in the same week, and eventually "it's just one more change" becomes the problem.
Why Support Feels It First, and the Worst
IT usually knows when change fatigue is setting in, even if nobody calls it that.
It's the employee who asks for help with the same workflow they've already been trained on. The person who gets frustrated over a routine MFA prompt. Or the familiar "Can you just do it for me?" because learning another process feels like more trouble than it's worth.
Sound familiar? These aren't always signs of poor training or difficult users. Sometimes people are simply tired of starting over, and that frustration doesn't disappear.
It lands in the help desk queue as more repeat questions, more access issues, and more time walking people through processes they understood perfectly well before the last update.
The frustrating part is that every individual change may have been handled correctly. Each department followed its rollout plan, training was provided, announcements went out, and IT was prepared. But nobody looked at what all those changes would feel like together.
We've previously covered how to prepare for the support demand that follows a technology launch in Go-Live Is Not the Finish Line. Change fatigue is what happens when you're managing that same post-launch demand for the fifth time in a quarter, while preparing for rollout number six.
The answer isn't necessarily a better rollout plan. It's making sure the organization has room for the next one.
Budgeting Change Like It's Actually a Budget
Nobody's suggesting organizations stop improving their technology. Security requirements evolve, business needs change, and outdated systems eventually need replacing.
But employee attention and IT support capacity aren't unlimited, and treating them that way creates problems long after the rollout announcement has been sent.
Here are five ways to manage both without bringing progress to a halt.
1. Give your organization a change budget, and enforce it like a real one
Most organizations track what they're spending on new technology. Far fewer track how many changes they're asking employees to navigate at once.
Start with a shared change calendar that includes major software rollouts, policy updates, migrations, and workflow changes across departments.
Before approving another implementation, look at what's already scheduled. If employees are facing a platform migration, a new ticketing portal, and an updated password policy in the same six weeks, does another rollout really need to happen right now?
Sometimes the most productive decision is moving something to next quarter. The goal isn't fewer improvements. It's giving each improvement a better chance to succeed.
2. Batch the small stuff instead of drip-feeding it
You know those emails that start with "We've made a few small changes"? Now imagine getting one every Tuesday for five weeks.
Even minor updates demand attention. Employees have to read the announcement, figure out what changed, and adjust how they work.
Rather than introducing every small update separately, establish predictable change windows for nonurgent improvements. One monthly announcement covering several minor changes can be easier to manage than a steady stream of surprises.
Security emergencies and critical fixes still need immediate attention, but not every interface adjustment deserves its own rollout.
3. Consolidate logins before you add another one
Another application shouldn't automatically mean another username, password, and authentication process. Yet that's often exactly what happens, and every additional login creates another opportunity for confusion, forgotten credentials, and support tickets.
Before introducing a new tool, evaluate whether it supports single sign-on (SSO) and integrates with existing identity management systems. If it doesn't, factor that additional friction into the purchasing decision.
For existing applications that can't be consolidated, an organization-approved password manager may help reduce the burden.
We've covered how seemingly simple access issues quietly consume support capacity. Multiply those issues across dozens of applications, and the impact becomes harder to ignore.
Every login you simplify is one less unnecessary obstacle between employees and their work.
4. Tell people where they are in the calendar, not just what's changing
Most rollout announcements explain what's new, why it matters, and when it takes effect. What they rarely explain is how it fits into everything else employees have already been asked to learn.
Consider the difference:
Typical announcement: "We're excited to announce another platform update!"
Better approach: "This is our fourth major technology change this quarter. We know there's been a lot to adjust to, and this is the last planned rollout before the holidays."
Same update, very different message. People are more receptive when they understand what's coming and when they can expect some stability.
You don't need another elaborate communication campaign. Sometimes one sentence acknowledging the bigger picture is enough.
5. Give people a way to say "that's enough" before they stop reading entirely
By the time employees stop opening update emails or attending training sessions, change fatigue has probably been building for a while. Don't wait until the complaints become tickets.
Give employees a simple way to flag what's becoming overwhelming. That might be a quick pulse survey after major rollouts, a standing Slack thread, or a few minutes during an existing team meeting.
Ask what's causing the most confusion, which processes still feel unfamiliar, and whether recent changes have actually made their jobs easier.
Then use that feedback to adjust upcoming rollouts. If three departments are reporting frustration with recent changes, that's information leadership should have before approving the next one.
It's a relatively simple way to catch problems before they turn into another wave of avoidable support requests.
The Change Receipt
Every change comes with a cost that doesn't appear on the software invoice. Time spent learning a new workflow. Productivity lost while familiar processes are replaced. Additional support tickets. Frustration that builds when employees feel like they're constantly playing catch-up.
None of those costs necessarily makes a new technology a bad investment, but ignoring them can make a good investment harder to realize.
We explored a related challenge in The Seventh Tab Problem: organizations can keep adding technology without necessarily getting more value from the tools they already have.
Change fatigue adds another layer to that problem. Even when every rollout is justified, the combined impact can leave employees exhausted and IT teams absorbing the consequences.
The question isn't whether your organization should keep improving its technology. It's whether you're giving people enough room to benefit from the improvements you've already made.
Because the fourteenth update might be the one that finally pushes everyone over the edge, even if there was nothing wrong with the update itself.
About the Author
Michelle Burnham has worked in and around the technology industry for nearly a decade; collaborating with IT support teams and contributing to technical documentation, service-oriented content, and operational communications. With a background in editing, formatting, and visual design, she specializes in translating complex ideas into clear, engaging content. In addition to her freelance creative work, she serves as a contract graphic designer, copywriter, and video editor for Helpt.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
Stop Answering Calls.
Start Driving Growth.
Let Helpt's US-based technicians handle your support calls 24x7 while your team focuses on what matters most.
©2026 Helpt, a part of PAG Technology Inc. All Rights Reserved.