Lynn Kelley had rolled out big organizational changes across 32 countries at Textron. She'd worked with Bell Helicopter, Cessna Aircraft, EZGO Golf Cars, and automotive plants across France and Germany. Her success rate was climbing. So when a small change came along -- 250 people she knew personally, a CEO mandate behind it, a group that trusted her -- she skipped her own process. No pilot. No phased rollout. Just an email: effective immediately, here's the change.
The blowback was immediate and intense.
That weekend, while researching what went wrong, Lynn found herself at Martha's Vineyard with a friend. They were walking along a bay when a group of about 10 people appeared on the beach, clearly headed for a swim. The group walked all the way around the bay to a specific spot. One person ran in and was carried across the bay by a rip tide that pulled laterally rather than out to sea. A few more jumped in after him, some on inner tubes, flying across. Then a couple of people waded in to their knees, hesitated, turned around, and walked back to meet their friends on the other side.
Lynn watched the entire change adoption curve play out on a beach in real time.
In any group facing a change, she explains, roughly 20% will accept it. They're the ones who jumped in. About 60% are neutral -- floating with the current, not paddling, not resisting. And 20% will resist. They're the ones who walked back. The mistake most organizations make -- the mistake Lynn made with that email -- is launching the change to everyone simultaneously. The 20% who resist have the loudest voices. They pull the neutral 60% toward them. By the time leadership notices the momentum going the wrong direction, reversing it is extraordinarily difficult.
The Fix: Pilot First, Build FOMO Second
The lesson Lynn drew from that failure -- and coded into the change management methodology she later co-authored with John Shook in Change Questions -- is structural, not motivational. You don't convince the resistors. You don't even start with the neutral group. You start with the 20% who are ready.
Pilot the change with willing adopters. Get the bugs out. (Every change has bugs. If you launch to everyone at once, the resistors point to the bugs as proof the whole thing is a waste of time. If you pilot first, you fix the bugs before anyone else sees them.) Then publicize the early wins. Have the CEO talk about them. Have the pilot participants present at a team meeting. Write an internal article. Record a podcast.
What happens next is predictable and powerful: the neutral 60% develops fear of missing out. They start asking why the pilot group gets extra resources, extra attention, extra recognition. "How come they get to do that?" is the sound of momentum building in the right direction. Now you have pull instead of push. The middle group is asking to join rather than being told to comply.
Lynn calls this strategic speed, drawing on a Harvard Business Review study that compared two approaches to implementation. Organizations that used "operational speed" -- timeline-based rollouts with mandated milestones -- achieved moderate results. Organizations that used "strategic speed" -- checkpoint-based implementation with built-in reflection and course correction -- produced 52% better outcomes when studied two years later. The slower-looking approach was faster to lasting results because it caught and fixed problems early instead of scaling them.
The Rework Cycle: Why Big-Bang Launches Create Their Own Failures
Eric Ethington, president of Lean Shift Consulting and co-author of The Power of Process with Matt Zayko, describes a pattern that connects directly to why piloting matters. He and Matt spent years watching the same frustration play out in manufacturing, healthcare, and other industries: a team does great Lean improvement work on an existing process, then a new process or facility launches, and it reproduces all the problems the team already solved. The improvement resources get pulled off their current work to go firefight the new launch. By the time the new process is stabilized, the old process has regressed. Then the next launch hits, and the cycle repeats.
Eric calls this the "development rework cycle" -- an engineering death spiral where organizations keep consuming resources to fix problems that shouldn't have existed. The root cause, in his analysis, is that the learning from improvement work never makes it upstream into the design of new processes. Teams learn valuable things through kaizen, but those insights stay local. The next factory, the next clinic renovation, the next product launch starts from scratch.
The example from his webinar preview is vivid: a healthcare organization renovating a series of primary care clinics reopens the first one and discovers they didn't plan enough space for supply storage. Scramble, adapt, fix. Then they renovate the second clinic and discover the same problem. The learning from clinic one never reached the team designing clinic two.
Eric's solution is a dedicated role he calls the system architect -- someone who owns both the development of the new process and the capture and spread of the knowledge gained during that development. The system architect doesn't do all the work. They orchestrate the learning: making sure insights from the first deployment influence the second, that problems solved once aren't re-solved in parallel, and that the PDCA cycle applies to the deployment process itself, not just the processes being deployed.
The connection to piloting is direct. A pilot isn't just a test of whether the change works. It's a learning vehicle. The problems you find, the adaptations you make, the workarounds people invent -- all of that is knowledge that makes the next deployment better. But only if someone is deliberately capturing it and feeding it forward. Without that role, organizations pilot, learn, and then ignore what they learned when they scale.
Electrolux: The Slow Start That Enabled the Fast Spread
Electrolux's 20-year journey with the Electrolux Manufacturing System illustrates both approaches -- and the consequences of each.
The initial deployment was fast and broad. EMS launched in 2005 and was active across all sites by 2007-2008. Sandro Casagrande, who leads EMS methodology globally, describes the early phases: bring in external experts, create model areas in each factory, train change agents, cascade knowledge to team leaders, then push toward daily continuous improvement. It was a well-structured deployment, and it moved quickly.
Nine years later, only a handful of sites had reached advanced certification levels. The rest were stuck -- not for lack of training or tools, but because the leadership behaviors that sustain improvement weren't part of the deployment. The methodology had scaled. The culture hadn't.
The evolution that followed -- EMS Way, focused on leadership processes and behaviors -- was rolled out differently. Electrolux didn't try to deploy new leadership habits to 34 factories simultaneously. They developed the approach through practice, refined it based on what worked, and spread it through a combination of coaching, site-level experimentation, and cross-site learning. The first phase of EMS prioritized speed and breadth. The second phase prioritized depth, allowing sites to build real capability before expanding.
The contrast tracks exactly with Lynn's framework. The first deployment was a big-bang launch to everyone. It produced tools and training everywhere but uneven results. The evolution was a piloted, learning-oriented approach that built genuine adoption before scaling.
The System Architect in Practice
Eric's system architect role deserves attention because it solves a problem that exists in most organizations but is rarely named: nobody owns the learning between deployments.
CI teams own the improvement methodology. Project managers own the implementation timeline. Executives own the strategic priority. But who owns the question "what did we learn from the last time we did this, and how does that change what we do next time?" In most organizations, the answer is nobody. Each deployment starts fresh, with a team that may or may not include people who were involved last time, working from a playbook that may or may not reflect what was learned.
The system architect fills that gap. Eric describes the role as having six dimensions: resident visionary (setting direction for how processes will be developed), resident historian (capturing knowledge so it's available next cycle), mentor and coach to the development team, mentor and coach to leadership, program manager for the development work, and liaison between the team and leadership.
Two of his practical recommendations stand out for CI leaders:
First, "pick something meaningful and try." The system architect role makes sense in theory, but it only develops through practice. Choose an actual deployment -- a new line, a clinic renovation, a process redesign -- and assign someone to own the learning capture alongside the technical work. The fires of the day will pull resources away from anything theoretical. Attaching the role to a real project gives it gravity.
Second, "help needs to feel like help." Eric borrows this from a colleague and applies it directly: if leadership's version of helping a struggling deployment is requiring the team to report twice as often, that's not help. That's overhead disguised as support. The system architect plays a liaison role precisely because leaders and teams often speak different languages about what support looks like. Real help might be removing an obstacle, providing a resource, or simply giving the team permission to take more time. The system architect is positioned to translate.
Making Pilot Wins Visible at Scale
The practical bottleneck in any pilot-first strategy is visibility. A successful pilot that nobody outside the pilot group knows about produces no FOMO and no pull. The learning stays local. The neutral 60% never sees the evidence that would shift their stance.
This is where the infrastructure matters. When a pilot team documents their improvement journey in a shared system -- the problem they identified, the change they tested, the results they measured, the adaptations they made -- that documentation becomes the marketing material for the next wave of adoption. It's not a PowerPoint from a consultant. It's real work done by real colleagues in a real facility, with measurable outcomes.
In organizations using a shared improvement platform, a successful pilot is visible to every other team that could benefit. A manufacturing plant in Italy solves a changeover problem, and the team in Thailand can see it, study it, and adapt it -- without waiting for a best-practice sharing meeting that may never be scheduled. A nursing unit redesigns its discharge process and reduces turnaround by 20 minutes, and every other unit in the health system can see exactly how they did it.
This organic visibility does two things simultaneously. It creates the FOMO that Lynn describes -- other teams see the results and want in. And it solves the knowledge transfer problem that Eric describes -- the learning from the pilot is captured in a form that subsequent deployments can actually use, not locked in the heads of the people who happened to be in the room.
The Counterintuitive Timeline
Organizations default to big-bang launches because they feel faster. The CEO wants results across the enterprise. The board wants to see scale. Piloting feels slow, cautious, even timid.
The data says otherwise. Lynn's research points to that 52% improvement in outcomes from strategic speed over operational speed. Eric's rework cycle shows how fast launches create their own drag -- resources consumed fixing problems that a pilot would have caught. Electrolux's nine-year stall demonstrates the cost of deploying methodology broadly without building the behavioral foundation that makes it stick.
The organizations that get to sustainable, enterprise-wide improvement fastest are the ones that resist the urge to launch to everyone at once. They pilot with willing adopters. They publicize early wins. They let pull replace push. They capture learning deliberately and feed it into the next deployment. And they build the visibility infrastructure that makes local successes available to the entire organization.
It feels slower in month one. It's dramatically faster by year three.
Related KaiNexus webinars referenced in this post:
.svg)
Add a Comment