Execution
The Lean Change Engine transforms feedback into better interventions. As people interact with those interventions, they generate new feedback — a continuous cycle of learning and adaptation that helps practitioners navigate toward better outcomes.
Where it sits in the operating system
The Engine is the heart and soul of the Lean Change Operating System. It's both the mental model and the execution model for achieving adaptive change management.
It's how we move from understanding to action. It's not a process to follow, it's a cycle to help you figure out what to do next.
The Engine is an adaptive cycle of Insights, Options, and Experiments. While the cycle is often shown beginning with Insights, there is no prescribed starting point. Where you begin depends on your context.
Each action generates new insights, creating a continuous cycle of learning and adaptation rather than a linear process.
Your current understanding of the system
Never complete, and constantly evolving as the system changes. Insights aren’t just data — they’re observations, patterns, stories, early warning signs, and hunches about what’s going on.
Core questions
Possibilities, not commitments
Once you have insights, resist the urge to jump to a solution. Generate options instead, and explore several ways forward before deciding which one is worth testing. The Lean Change Playbook gives you a library of proven practices to draw from.
Every option carries a cost and a value — what it would take to run, and what it would be worth. Comparing the two is how you decide which to try first.
Core questions
Options turned into deliberate action
An experiment isn’t just “doing something.” It’s doing something deliberately, with a hypothesis about what you expect to happen and why. Keep experiments small enough that being wrong is cheap, and involve the people the change affects — their reaction is part of what you’re learning.
Core questions
Pivot, pursue, or pause
Once you’ve been through the cycle, you have a decision to make based on what you’ve learned. Whatever you decide, the cycle runs again — starting from better insights than last time.
Maybe the experiment needs adjusting. Maybe it worked, and it’s time to take bigger action. Or maybe it isn’t working, and it’s time to stop.
Core questions
Real-world case study
A multinational, and an approval process nobody could get through first time
A multinational’s Digital Solution Review — the approval every new technology request had to pass — had become a bottleneck. Submissions kept coming back for rework, and Enterprise Architecture spent its time fixing forms instead of reviewing solutions.
Interviews and surveys showed the form wasn’t the real problem: requestors were being asked to do solution architecture they weren’t equipped for. The team compared options on cost and value, then tested the most promising one — a six-month pilot putting solution architects alongside requestors before review.
A multinational company relied on its Digital Solution Review (DSR) process to evaluate requests for new technology solutions from employees across its operating sites and corporate offices. Before a new application or technology could be approved, a DSR was required to ensure it met architectural, security, and governance standards.
Over time, however, the process became a significant source of frustration. Requestors struggled to complete the required information, submissions were frequently returned for rework, and Enterprise Architecture spent considerable time correcting issues rather than reviewing solutions.
The change team, led by a Lean Change Certified Practitioner, began by generating insights before proposing solutions.
The team interviewed stakeholders from across the organization, surveyed frequent users of the DSR process, and met with Enterprise Architects and business requestors to understand their experiences. By combining insights from multiple sources and looking for patterns across the system, a consistent picture began to emerge.
The problem wasn’t simply that the DSR form was too complex. The process was expecting business requestors to perform solution architecture work that they were neither trained nor equipped to do. The real issue was a missing solution architecture capability — not a poorly designed form.
Rather than selecting the first solution, the change team generated multiple options and evaluated each using a simple Cost–Value Matrix. Cost considered the effort, disruption, and investment required to implement each option, while value represented the team’s assessment of how much the option was likely to improve the underlying change challenge. This allowed the team to identify solutions that offered the greatest potential impact for the least organizational effort.
Rather than committing immediately to a permanent organizational change, the change team chose to reduce uncertainty by running an experiment.
A six-month pilot was designed in which one to two contract Solution Architects would work directly with business requestors to prepare DSR submissions before Enterprise Architecture review. The objective was to test whether introducing solution architecture capability upstream would improve submission quality, reduce review cycle time, and increase stakeholder satisfaction before making a larger investment.
Training & certification
Learn how to apply the Lean Change Operating System to real-world change initiatives by enrolling in one of our training programs. More than a certification course, it's an immersive learning experience designed to transform how you think about, design, and lead change in complex environments.
Whether you're new to Lean Change or looking to become a certified practitioner, you'll gain practical tools, proven practices, and the confidence to continuously sense, learn, and adapt as change unfolds.