Skip to content

October 2, 2025

Your Users Aren’t Lazy—They’re Managing Change Overload

By Leah Brown

Picture this: A seasoned medical coder sits down at her workstation every morning and flies through insurance claims at lightning speed. Her fingers dance across function keys and the ten-key pad without her eyes ever leaving the screen. She processes more claims in an hour than most people could handle in a day.

Then your team delivers a “user-friendly” modernization of her software. Suddenly, she needs a mouse. The keyboard shortcuts she’s memorized over decades no longer work. Tasks that took seconds now require multiple clicks through dropdown menus. Her productivity plummets.

Is she being resistant to change? Lazy? Unwilling to learn?

None of the above. She’s managing change overload in the only way that makes sense: by protecting the workflows that keep her livelihood intact.

This scenario, shared by coauthor Heidi Waterhouse in the upcoming book Progressive Delivery, illustrates a fundamental misunderstanding that’s costing organizations millions in failed software rollouts, user frustration, and abandoned features.

The Change Paradox

Here’s what seems contradictory but is actually perfectly logical: the same person who eagerly upgrades their iPhone every year might resist a minor update to their work software. The same developer who constantly experiments with new programming languages might refuse to adopt your team’s new deployment tool.

This isn’t hypocrisy—it’s smart change management.

People have a finite capacity for absorbing change. We instinctively protect our most critical workflows while remaining open to improvement in areas where failure isn’t catastrophic. Your iPhone upgrade can be undone or worked around. Your work software, which determines whether you can pay your mortgage, demands much more careful consideration.

Beyond Stakeholders: Understanding Your Full Constituency

Most organizations think about their users as “stakeholders”—people who have a financial or organizational interest in the product’s success. But Progressive Delivery requires thinking about “constituents”—everyone who is actually affected by your software, whether they appear on your org chart or not.

Consider medical records software. The obvious stakeholders are:

  • Doctors who input patient data.
  • Hospital administrators who purchase the software.
  • IT teams who maintain the systems.
  • Your development team who builds features.

But the full constituency includes:

  • Nurses who need to access information during emergencies.
  • Patients who use portals to view their own data.
  • Family members helping elderly relatives navigate health information.
  • Regulatory bodies ensuring privacy compliance.
  • Insurance companies processing claims.
  • Medical billers like our friend above.

Each constituent has different change tolerance levels, different technical sophistication, and different stakes in maintaining stability versus embracing innovation.

The Three Types of Change Capacity

Not all users approach change the same way. Understanding these differences is crucial for delivering software that actually gets adopted:

  1. The Builder Mindset Some users see software as LEGO blocks—they want to understand how things work and customize their experience. These are your early adopters who read release notes, experiment with beta features, and provide detailed feedback. They have high change tolerance because they enjoy the process of discovery and optimization. They’re willing to invest time learning new workflows because they see it as creative problem-solving.
  2. The Tool Mindset Most users see software as a hammer—they want it to reliably perform specific tasks without requiring constant attention. They’ve developed efficient workflows around current functionality and view changes through the lens of “will this help me get my job done better?” They have moderate change tolerance when improvements clearly align with their goals, but they resist changes that disrupt established patterns without obvious benefit.
  3. The Survival Mindset Some users interact with software in high-stakes environments where mistakes have serious consequences. Medical professionals, financial traders, air traffic controllers—these users have optimized their workflows for safety and reliability above all else. They have very low change tolerance because their primary concern isn’t efficiency improvement—it’s avoiding catastrophic failure.

The Cost of Misreading Your Constituency

When you misunderstand your users’ change capacity, you create what Progressive Delivery calls “technological jerk“—the jarring experience of change happening too fast for people to absorb.

  • Slack’s 2019 redesign perfectly illustrates this mismatch. Slack’s design team saw an opportunity to create a more modern, streamlined interface. They were thinking like builders—excited about cleaner visual hierarchy and improved information architecture. But most Slack users weren’t builders—they were people managing dozens of conversations across multiple workspaces while trying to get their actual jobs done. The redesign disrupted muscle memory, changed keyboard shortcuts, and reorganized familiar layouts. What felt like an improvement to the design team felt like chaos to users trying to maintain productivity.
  • Sonos’s 2024 app disaster represents an even more dramatic failure. The company released an app update that broke core functionality like sleep timers and queue management. Users weren’t just annoyed—they were unable to perform basic tasks with expensive hardware they’d already purchased. CEO Patrick Spence was forced to resign in January 2025.

In both cases, the companies built better software from a technical perspective but failed to consider how changes would land with people who depended on existing workflows.

The Adobe Alternative: Progressive Control

Adobe provides a masterclass in respecting user change capacity while still driving innovation. When they integrated AI into their Creative Cloud suite, they could have simply pushed the latest models to everyone simultaneously. Instead, they implemented what Progressive Delivery calls “radical delegation.”

Users can choose which AI model version to use for different projects. Someone working on a long-term brand campaign can maintain consistency with Firefly v1, while someone experimenting with new creative techniques can opt into Firefly v3. The same user might make different choices for different contexts.

This isn’t just about offering a “classic mode” checkbox. Adobe created granular controls that let users manage their own change absorption rate based on their specific needs and risk tolerance.

Three Strategies for Respecting Change Capacity

  1. Delegate Control to the Point of Impact: Instead of deciding when users should adopt new features, give them the tools to make that decision themselves. Microsoft’s “Try the new Outlook” toggle lets users test the redesigned experience and revert if needed. Google Workspace offers separate release tracks for organizations with different change tolerance levels. The key is making this choice meaningful—not just a temporary beta flag that eventually disappears, but ongoing control over their experience.
  2. Design for Multiple Speeds Simultaneously: Your power users and cautious users don’t need to move at the same pace. GitHub ships hundreds of small changes that are mostly invisible to casual users but provide meaningful improvements for developers who spend all day in the platform. Meanwhile, major feature releases are carefully communicated and gradually rolled out. This allows your constituency to self-select into the change pace that matches their capacity and context.
  3. Build Reversible Experiences: Make it safe to experiment by making it easy to step back. This isn’t just about technical rollback capabilities—it’s about user confidence. When people trust they can explore new functionality without getting trapped in unfamiliar territory, they’re more willing to try changes. Netflix’s interface experiments are a good example. They test thousands of variations, but users never feel stuck with a version they dislike because the changes are either subtle or easily reversible.

The Empathy Advantage

Organizations that successfully implement Progressive Delivery share a crucial insight: user “resistance” is usually valuable information about change capacity, not character flaws to overcome.

When users complain about the pace of updates, they’re telling you about their bandwidth for absorption. When they create workarounds to avoid new features, they’re showing you that your timing doesn’t match their readiness. When they stick with “legacy” workflows, they’re protecting something valuable that you might not understand.

Instead of viewing this feedback as obstacles to overcome, Progressive Delivery treats it as essential input for delivering software that actually creates value.

The Path to Sustainable Innovation

Here’s the paradox: When you respect users’ change capacity, you can actually innovate faster. Users who trust that you won’t disrupt their critical workflows are more willing to experiment with new capabilities. Users who feel heard and respected become advocates rather than resistors.

Progressive Delivery isn’t about slowing down innovation—it’s about ensuring innovation actually reaches the people who need it, when they’re ready to receive it.

Your users aren’t lazy. They’re not change-averse. They’re not technologically backward.

They’re intelligent people managing complex workflows in environments where stability matters. They’re making rational decisions about where to invest their limited change capacity. They’re protecting their ability to be productive while remaining open to genuine improvements.

The question isn’t how to overcome user resistance. The question is how to build delivery systems that work with human change capacity rather than against it.

When you get that right, everyone wins: users get software that actually makes their lives better, and you get the sustainable adoption that drives real business value.


This post explores concepts from the upcoming book Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).

- About The Authors
Leah Brown

Leah Brown

Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.

Follow Leah on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Your Users Aren’t Lazy—They’re Managing Change Overload
    By Leah Brown

    Picture this: A seasoned medical coder sits down at her workstation every morning and…

    The Vibe Coding Loop
    By Gene Kim , Steve Yegge

    The following is an excerpt from the forthcoming book Vibe Coding: Building Production-Grade Software With…

    AI’s Mirror Effect: How the 2025 DORA Report Reveals Your Organization’s True Capabilities
    By Leah Brown

    The 2025 DORA State of AI-assisted Software Development report delivers a sobering reality check…

    Welcome to the Vibe Coding Kitchen: Your First Lesson
    By Gene Kim , Steve Yegge

    The following is an excerpt from the forthcoming book Vibe Coding: Building Production-Grade Software With…