LLMs and Generative AI in the enterprise.
Inspire, develop, and guide a winning organization.
Understand the unique values and behaviors of a successful organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how to enhance collaboration and performance in large-scale organizations through Flow Engineering
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Exploring the impact of GenAI in our organizations & creating business impact through technology leadership.
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
The debate over in-office versus remote work misses a fundamental truth: high-performing teams succeed based on how they’re organized, not where they sit.
Leaders can help their organizations move from the danger zone to the winning zone by changing how they wire their organization’s social circuitry.
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
June 3, 2025
It’s Friday at 9:52 p.m. You open the app on your phone to adjust the alarm on your smart speakers. You need to ensure you’re up early to make a flight. When the app opens, it’s different. “Oh, cool, a new update,” you think at first. But after twenty minutes of fruitlessly tapping around the screen, you discover through Reddit that the new app update has completely removed the ability to control alarms.
You spend the next hour setting up physical alarm clocks while trying not to wake your family.
Sound familiar?
This scenario isn’t just frustrating—it represents a fundamental disconnect in delivering software. Software developers are often proud of their innovations, and businesses are eager to ship them. But users are increasingly exhausted by the constant technological churn disrupting daily lives and workflows.
In their upcoming book, Progressive Delivery: Build The Right Thing For The Right People At The Right Time (IT Revolution Press, November 2025), authors James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman call this phenomenon technological jerk.
In physics, “jerk” isn’t just someone cutting you off in traffic—it’s the rate at which acceleration changes. It’s the feeling that makes you grab for the subway pole when the train lurches or brace yourself during an elevator’s sudden start.
As the authors explain in the book, “Just as physical jerk throws our bodies off balance, technological jerk throws our mental models and established workflows into disarray when software changes too abruptly or without proper preparation.”
This isn’t about resistance to change itself. It’s about our human capacity to absorb the rate of change. And in today’s software environment, that rate is accelerating far beyond what many users can comfortably process.
When users experience technological jerk, they don’t typically blame themselves—they blame your product. This manifests in ways that directly impact your business:
In 2019, Slack faced significant backlash after releasing a major UI redesign that disrupted established workflows. Despite the company’s belief that the new interface would ultimately improve productivity, users revolted against the change. Some organizations even delayed upgrading to maintain productivity.
Even worse, in January 2025, Sonos CEO Patrick Spence was forced to resign after an app update broke core functionality. The cost of failing to manage technological jerk isn’t just customer dissatisfaction—it can be existential.
If the effects are so damaging, why do we keep creating software experiences that jar our users? Several factors are at play:
When you’ve spent months designing and building a feature, the change seems intuitive, even obvious. You can’t un-see what you know. This cognitive bias makes it nearly impossible to accurately predict how disruptive a change will feel to someone encountering it for the first time.
Many organizations have embraced CI/CD to optimize their deployment pipelines, shipping code dozens or hundreds of times daily. But we haven’t created equivalent sophistication around how we release those changes to users and support their adoption journey.
The software industry conflates three distinct processes:
While optimizing for deployment speed, we’ve neglected the human-centered processes of release and adoption.
“But users asked for this!” is a common defense when pushback occurs. This ignores a crucial reality: users typically ask for outcomes, not specific implementations.
When a user says, “I want a faster search function,” what they’re really asking for is, “I need to find critical information during customer calls without losing the customer’s attention.” Your implementation of a “faster search” might actually disrupt the workflow they’ve optimized around the current search.
Product teams often speak of “our users” as a monolithic entity. “Our users want this.” “Our users will love this.” This ignores the reality that your user base contains multiple personas with dramatically different needs, technical sophistication levels, and change tolerance thresholds.
What delights your early adopters may alienate your steady mainstream users. Assuming “everyone” will react similarly to change is a recipe for creating technological jerk.
Some organizations have begun exploring solutions to this problem:
Companies like GitHub use sophisticated feature flagging not just for testing but as a fundamental control mechanism that separates deployment from release. Rather than abruptly pushing changes to all users simultaneously, they create control points that allow for gradual, deliberate exposure of new capabilities.
Microsoft has pioneered the concept of “ring deployments,” where changes progress through increasingly larger circles of users, starting with internal teams and expanding gradually to early adopters before reaching the general population. This creates a progressive exposure pattern that catches issues early while allowing most users to avoid the earliest, most disruptive moments of a new feature.
Some products now offer explicit user choice in when and how they adopt new features. Google Workspace, for instance, allows administrators to choose between “Rapid Release” and “Scheduled Release” tracks, acknowledging that different organizations have different change absorption capacities.
Just as DevOps emerged to bridge the gap between development and operations, a new discipline—Product Operations—is forming to manage the increasingly complex interface between product teams and users. This emerging function explicitly owns the user transition experience, much as DevOps owns the code transition experience.
These approaches represent important first steps, but they remain fragmented and inconsistent across the industry. What’s needed is a comprehensive framework that systematically addresses technological jerk by reconceptualizing how we deliver software.
Such a framework would need to:
This isn’t about slowing innovation—it’s about enabling sustainable innovation that users can absorb and benefit from. It’s about finding the sweet spot between technological stagnation and technological whiplash.
Progressive Delivery introduces a comprehensive framework to do just this—a systematic approach to managing technological jerk while maintaining innovation velocity.
Drawing on their extensive combined experience in the industry, as well as case studies from companies like GitHub, Disney, Adobe, and AWS, the authors demonstrate how organizations of various sizes and industries have addressed this challenge through a combination of cultural, procedural, and technical practices.
Until the book comes out, you can start by recognizing when you’re creating technological jerk in your own products:
These are all signs that your delivery approach may be creating more friction than function. By recognizing the problem, you’ve taken the first step toward building better relationships with your users through more thoughtful software delivery.
Because at the end of the day, what matters isn’t just what we build—it’s how we deliver it, to whom, and at what pace. Get that right, and both your users and your business will thrive.
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), which introduces a comprehensive framework for delivering software in ways that respect both innovation needs and user adoption capacities.
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.
No comments found
Your email address will not be published.
First Name Last Name
Δ
It's Friday at 9:52 p.m. You open the app on your phone to adjust…
Creating a lasting partnership between business and IT requires more than initial changes—it demands…
Moving beyond mutual understanding, true business-IT partnership requires shared ownership of outcomes. This means…
The foundation of any effective business-IT partnership is shared understanding and mutual trust. Without…