Every tool you use gets updated constantly. Your email client rearranges its toolbar. Your calendar app adds a feature you didn’t ask for. Your ATS pushes a new release notes email you don’t have time to read, let alone test before it goes live. This is what change fatigue actually looks like in practice, one small update at a time.

None of these updates are catastrophic on their own. But your brain doesn’t process them as isolated events. It processes them as one more thing competing for a limited amount of working memory. And system administrators are absorbing more of these events than almost anyone else in the org.

This isn’t unique to ATS admins, either. Any IT team pushing a system update, any product or UX team shipping a redesign, is asking people to absorb the same kind of load.

This is where the conversation about change fatigue usually goes wrong. People treat it like an attitude problem, something to manage with a better attitude and a pep talk, rather than a measurable cost. The research says otherwise.

Change fatigue is load, not laziness

Psychologist John Sweller’s cognitive load theory splits mental effort into three buckets. There’s the effort a task requires on its own, the effort wasted on friction from bad design or an unfamiliar layout, and the effort available for learning and judgment. Every unannounced UI shift, every “quick fix” nobody explained, adds to that second bucket. And it draws from the same limited pool your team needs for the first and third.

Decision fatigue research points the same way. Willpower and deliberate attention pull from a shared, limited reserve. If a system admin must relearn a workflow every few weeks, that’s not a minor annoyance stacked on top of the real work. It’s a direct tax on the same resource they need for the actual judgment calls their job depends on.

The volume has gone up, too. Gartner has tracked the number of planned enterprise changes hitting the average employee each year, and it has climbed sharply since 2016. Separately, most professionals surveyed by LinkedIn say they feel overwhelmed by the pace of change at their organization. That’s a measured trend, and HR technology teams are living squarely inside it.

The change fatigue mistake I see most often

Here’s a pattern that shows up again and again with clients rolling out a new ATS or overhauling an existing one. We build the system around what it should do, and almost no attention goes to what the team launching it can absorb.

A configuration change that makes perfect sense on a whiteboard still lands on a team that’s already juggling requisitions, candidate communication, and whatever fire is burning that week. If the rollout doesn’t account for that existing load, it doesn’t matter how good the design is. The team won’t have the bandwidth to adopt it well, and adoption is the entire point.

You get one real shot at launch

There’s a short window right after something launches when people are paying attention. They open the announcement, click through the new screens, maybe sit through a training session. Once that window closes, it doesn’t reopen on its own.

If a team is too buried in daily work to engage with a launch while it’s happening, they don’t circle back once things quiet down. The launch notes sit in an inbox nobody reopens. The training recording sits unwatched. By the time anyone has room to look again, they’ve usually already found a workaround, and the workaround has become the habit.

This works a lot like a first impression. A rough first date rarely gets a second one, no matter how thoughtful the follow-up message is. A rollout works the same way. If someone’s first real interaction with a new system happens while they’re underwater with other work, that impression sticks. Coming back to it later feels like homework instead of a fresh look.

Ignoring workload before a launch doesn’t just slow adoption down, it can close the window on full adoption for good, and that’s a much harder problem to solve after the fact.

Why change fatigue drives people to workarounds

This is where shadow processes come from, and it has nothing to do with laziness or resistance for its own sake.

Behavioral economists Samuelson and Zeckhauser named this back in 1988. People default to the status quo because it’s a known, reliable source of information. Anything new, by contrast, carries real switching costs and uncertainty. When a system doesn’t fit how a team works, or changes too often for anyone to build real fluency with it, going back to the spreadsheet isn’t dysfunction. It’s the rational move.

Researchers have a name for this too, “shadow IT”. It describes a consistent pattern across studies, and it shows these workarounds are rarely acts of defiance. They’re adaptations people make when the sanctioned tool doesn’t fit the job in front of them. Treat that as a signal instead of a discipline problem, and you learn something real about where your system is failing your team.

Most organizations don’t treat it that way. They patch around the symptom instead of asking why the fit broke down in the first place. This habit ensures that your team will search for the workarounds instead of coming to you to fix the system that doesn’t meet their needs.

Constant tweaking is its own kind of chaos

That patching instinct feels responsible on the surface: fix the thing that’s broken, one ticket at a time, as fast as possible. It’s easy to see why teams default to this. It’s cheaper to staff, easier to schedule around, and gives leadership a visible drip of progress to point to.

None of that makes it the right call for the people trying to adapt to daily change. You scope each fix to the complaint in front of you, not to how the business has evolved since the system was first built. As a result, six months of narrowly scoped patches produces a system that’s technically been improved a dozen times and somehow feels more fragmented than when you started. That fragmentation is precisely what drives people back to Excel.

There’s even a case, based on recent research challenging Kotter’s classic change model, that the standard playbook makes this worse. Kotter’s approach tells you to convince people the status quo is dangerous for the sake of building urgency. Recent work on status quo bias argues this backfires, since it fights a deeply wired preference instead of working with it, and amplifies the stress and defensiveness you’re trying to avoid.

What measured change looks like

None of this is an argument for freezing the system in place, or for never touching anything the team already knows. It’s an argument for treating every change as a withdrawal from a limited account and asking whether the withdrawal is worth it before you make it.

Before launching the next update, a few honest questions help:

• What is this team’s true workload right now, this month, or in the timeline of the rollout, not in theory?
• Is this change solving a real, current problem, or is it a fix aimed at a version of the business that doesn’t exist anymore?
• Does this change solve a future problem based upon an upcoming change in your business?
• Does this consolidate several small pain points into one coherent improvement, or is it one more isolated patch on top of the last isolated patch?

Most roadmaps skip that fourth question entirely. Skipping it is usually why the change doesn’t stick. A system built five years ago is rarely still solving today’s problems, not because it broke, but because the business kept moving and the system didn’t move with it in any coherent way. The requirements changed. Someone patched the system around the edges instead of reassessing it against what’s true now.

That’s precisely the gap a structured requirements review closes. It means taking an honest look at what’s changed since the last real assessment, rather than launching another sprint of small fixes. The next round of investment then goes toward the system your team needs today, not the one built for a business it has outgrown.

Change itself was never the issue. The constant, uncoordinated version of it chews through a resource your team can’t get back. Treat their attention with the same discipline you’d apply to budget or headcount. It also eats away at the value of your initial investment. Constantly putting your finger on holes doesn’t stop the dam failure. Instead of repairing the structure at its base, all it does is make the system admin a crisis manager holding things up by their shoulders and sheer will.

Change Fatigue FAQ

What is change fatigue?

Change fatigue is the cumulative mental and emotional toll of experiencing too many changes, too close together, without enough time to adjust to any one of them. It shows up as disengagement, slower adoption, and a pull back toward familiar tools and habits.

How does cognitive load affect software adoption?

Every unfamiliar interface or unexplained update adds friction that competes with the mental effort a person needs to actually learn and use a new system well. When that friction piles up, there’s less capacity left for real adoption, no matter how good the software is.

What are shadow processes?

Shadow processes, sometimes called shadow IT, are the spreadsheets, side tools, and manual workarounds people build when the official system doesn’t fit how they actually work. They’re not a sign of a lazy or resistant team. They’re a signal that the system needs a closer look.

How can organizations reduce change fatigue?

Start by accounting for a team’s existing workload before adding a new change, not after. Prioritize changes that solve real, current problems over reactive one-ticket-at-a-time patches, and give people a real, well-supported window to adopt something before moving to the next update.

Why does a requirements review work better than patching a system one ticket at a time?

A requirements review looks at what’s actually changed in the business since the system was last assessed, then addresses the root cause. Ticket-by-ticket patching only ever responds to the complaint in front of you, which tends to compound complexity rather than resolve it.