How Targeted Pilots Help Fight Change Fatigue.
When Harvard Business Review opens an article by referencing The Onion, you know it's going to be worth reading. (article linked below)
The piece, "Get Off the Transformation Treadmill" in the upcoming January issue, challenges the corporate habit of continuous transformation. One bold initiative to undo the damage from last year's bold initiative. Organizations become so exhausted by constant change that they lose the will to change at all. Throw AI disruption into this mix and it's downright toxic.
The examples, though, are enterprise-scale: Boston Scientific, Pixar, Microsoft. Companies with thousands of employees and dedicated change management functions. I wanted to look at this through the lens of smaller businesses and translate some of the core themes into tactics you can use today if your organization is also struggling with change fatigue.
The core insight hits hard for SMBs. When you're running a 30-person company, there's no buffer. Every change lands on the same people. There's no change management team absorbing the shock. It's just you and your team, and they're tired.
What the Transformation Treadmill Looks Like at 30 Employees
You've probably seen this movie before. Maybe you've directed it.
The CRM changes every 18 months because the last one wasn't quite right. The new sales process gets announced with enthusiasm, quietly ignored for three months, then replaced by another new process. You hired an expert to fix your processes but that went pear-shaped. The project management tool that was supposed to solve everything didn't, so now there's a different one. The team has learned that the safest response to any new initiative is to wait it out.
To drive this point home, I'll share a real-world example. Early in my career, I was part of a consulting team brought in on a five-year engagement to help improve operations. One of the client leaders, in an honest moment, told me they had decided to just wait out the remaining four years of the contract under the hope that they could go back to the old way of doing things.
A four-year commitment to wait it out. That's what you're up against.
This isn't malice. It's usually a founder or leader who genuinely wants to improve things and keeps searching for the right answer. But the cumulative effect is brutal. Gartner found that employee willingness to support organizational change dropped from 74% in 2016 to 43% in 2022. The average employee now experiences ten planned enterprise changes per year, up from two in 2016.
One finding should stop every SMB leader in their tracks: day-to-day changes (new managers, shifted responsibilities, altered workflows) are more damaging to employees than the big-bang transformations. It's not the major restructuring that breaks people. It's the constant small disruptions that never let them find their footing.
In an SMB, you don't have the luxury of separating "big" changes from "small" ones. It's all landing on the same 15 or 40 people. The exhaustion isn't from any single change. It's from the accumulated weight of changes that didn't stick, paired with the reasonable expectation that whatever you're announcing today will be undone in six months.
The Psychology angle that we often overlook.
There's a reason change is so hard, and it's not that people are lazy or resistant or stuck in their ways.
Daniel Kahneman and Amos Tversky's research showed that people feel losses roughly twice as intensely as equivalent gains. Lose $100, and the psychological pain is about twice as powerful as the pleasure of finding $100. This isn't a character flaw. It's how human brains are wired. It shows up in a capuchin monkey research study (also linked below). It's that fundamental.
When you announce "we're changing how we do X," your team's brains immediately start calculating what they're losing. Familiarity. Competence. Their sense of how things work around here. The confidence that comes from knowing what to do without thinking about it. Even if the new way is objectively better (faster, cheaper, more effective), the emotional math doesn't work in your favor. The gains have to be twice as large as the perceived losses just to break even.
There's another layer for founders specifically. The way things work in your company is often the way you or your key people set them up. Changing how things work can feel like admitting you were wrong. Identity gets wrapped up in the systems and processes you and your staff built. So change is resisted until the pain is unbearable, then you overcorrect with a massive transformation that exhausts everyone, and the cycle starts again.
Enter the Pilot: Change's Trojan Horse
About a decade ago, I managed a patient collections operation at a large hospital system, where we collected roughly $280M in cash annually. Together with the client team, we implemented changes that generated $70M in extra cash. That's a fantastic result, but it was 100% a team effort. And the changes that lasted were never the ones that arrived as mandates. They were the ones that started as experiments: pilots, A/B tests, whatever you want to call them. We'd develop a hypothesis, use data to back-test it, deploy it in a pilot, monitor returns, and then adjust it, pitch it, or implement it. It's that simple.
The pilot reframes everything. "We're testing this for the next 60 days" lands completely differently in the brain than "this is how we work now."
Pilots neutralize loss aversion because they change the stakes.
Reversibility. When something is a pilot, nothing has actually been lost yet. The old way still exists, sitting right there, ready to come back if the experiment doesn't work. The psychological pain of loss never kicks in because there's no loss. Just a temporary trial.
Bounded stakes. If a pilot fails, the blast radius is contained. It affected one team for two months, not the entire company forever. The downside is capped, which makes the risk feel manageable instead of existential.
Preserved identity. No one needs to admit they were wrong. They're experimenting, which is what smart leaders do. The team isn't being told their old way was bad. They're being invited to test whether a new way might be better. Nobody has to lose face.
Permission to fail. When you announce a transformation, failure isn't an option. That means people protect themselves by not fully committing. When you announce a pilot, failure is explicitly on the table. This makes people more willing to actually try, because they're not risking their credibility on something that might not work.
The process improvements that generated real results (like changing the term or minimum of a payment arrangement) didn't arrive as mandates. They started as pilots with specific teams, with clear success criteria, with explicit permission to roll back if the results weren't there. The teams that participated became advocates for the changes because they'd been part of proving they worked. By the time we scaled to the broader organization, we had evidence and internal champions. Not just a mandate and a prayer.
How to Structure Pilots That Actually Work
Not all pilots are created equal. A poorly designed pilot is just a slow-motion transformation with extra steps. What separates pilots that create lasting change from pilots that just delay resistance?
Time-bound, and not too long. Sixty to ninety days is usually right. Shorter than that and you won't have meaningful data. Longer than that and it stops feeling like an experiment. The uncertainty becomes its own source of fatigue. People need to know when they'll have an answer.
Success criteria defined upfront. Before you start, answer this question: what would have to be true for this pilot to become permanent? Write it down. Share it with the team. "If we see X metric improve by Y percent, we'll roll this out to everyone. If we don't, we'll go back to the old way." This makes success concrete, and it makes the reversibility credible.
Explicit reversibility, stated out loud. Don't assume people know you're willing to go back to the old way. Say it directly: "If this doesn't work, we return to our previous process. No harm, no foul." The more credible the offramp, the more willing people are to fully engage with the experiment.
Start with volunteers or your most adaptable team. Don't pilot with your most skeptical people. You're setting yourself up to prove the skeptics right. Start with the team that's most open to trying new things. Let them work out the kinks, build the case, become the advocates. When you expand, they become your internal champions.
Credit flows down, blame flows up. If the pilot works, the team figured it out. Celebrate them. If the pilot fails, you made a bad call on what to test. Own it publicly. This feels counterintuitive, but it's essential for the next pilot. If people see that failed experiments result in blame rolling downhill, they'll never fully commit to another one.
The Compounding Effect
The payoff isn't any single pilot. It's what happens over time to your team culture.
Instead of one traumatic transformation every eighteen months that burns everyone out and may or may not stick, you get a steady stream of small improvements that compound. Each successful pilot builds confidence (yours and your team's) that change can happen without chaos. Each failed pilot builds trust that you meant it when you said failure was acceptable.
The team starts to believe that changes will be tested, not imposed. Resistance drops because the stakes are lower. You end up changing more while exhausting people less. The transformation treadmill stops not because you stopped improving, but because improvement became normal instead of traumatic.
The HBR article calls this "brick by brick management." Steady, integrated strategic adjustments rather than periodic upheavals. For SMBs, the pilot is the brick. Small enough to be low-risk. Concrete enough to generate real evidence. Frequent enough to compound into something significant.
If your team is tired, and they've been through enough bold new plans, give them something different: a small experiment, a clear timeframe, an honest chance to prove whether something works. The Trojan horse isn't really about tricking anyone. It's about making change safe enough that people can actually engage with it.
Make it safe, and they'll stop waiting it out.
References
Chen, M. Keith, Venkat Lakshminarayanan, and Laurie R. Santos. "How Basic Are Behavioral Biases? Evidence from Capuchin Monkey Trading Behavior." Journal of Political Economy 114, no. 3 (2006): 517-537. https://www.jstor.org/stable/10.1086/503550
Gartner. "How to Reduce the Risk of Employee Change Fatigue." Gartner Smarter with Gartner. https://www.gartner.com/smarterwithgartner/how-to-reduce-the-risk-of-employee-change-fatigue
Kahneman, Daniel, and Amos Tversky. "Prospect Theory: An Analysis of Decision under Risk." Econometrica 47, no. 2 (March 1979): 263-291. https://www.jstor.org/stable/1914185
McKinsey & Company. "Have You Made It Safe to Fail?" McKinsey Digital, February 18, 2020. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/fasttimes/have-you-made-it-safe-to-fail
Rigby, Darrell, and Zach First. "Get Off the Transformation Treadmill." Harvard Business Review, January-February 2026. https://hbr.org/2026/01/get-off-the-transformation-treadmill