Rebuild While Running
Change a live system without waiting for a clean-slate restart.
- Difficulty
- Expert
- Time to result
- ~ongoing to results
- Steps
- 6
- Confidence
- 96%
Rebuild While Running rejects the fantasy of a blank canvas for a functioning organization, society, or life. First define what the system must continue to deliver, then map the functions whose interruption would cause unacceptable harm. Introduce the smallest meaningful change with a fallback, observe it under real operating conditions, and retain or reverse it based on evidence before proceeding. The mechanism trades the simplicity of demolition for continuity, feedback, and lower transition risk. Sadhguru illustrates it with a mechanic being asked to repair an engine while it is running and says the same constraint applies to individuals and the world. The output is a sequence of verified changes that gradually alters the whole system without pretending its dependencies have disappeared.
Origin
Sadhguru tells a joke about a mechanic who compares repairing a car with a cardiologist's work. The doctor answers, 'Try to fix it when it's running,' which Sadhguru applies to changing individuals, society, and the world.
Core principles
- 01Most important systems cannot be paused and rebuilt from zero.
- 02Continuity is a constraint, not an excuse to avoid change.
- 03Transformation should be sequenced around essential functions.
- 04Each change must be observed in the operating system before the next one.
How to run it
- 1
Name the continuity requirement
Define the service, responsibility, or human need that must continue throughout the change. Make the acceptable interruption explicit.
Pro tip Describe continuity from the user's perspective, not only the operator's.
Watch out Do not preserve a function that is itself causing immediate harm.
- 2
Map live dependencies
Identify the people, processes, resources, and handoffs the system currently relies on. Mark where one change could create cascading failure.
Pro tip Trace one real transaction or day through the current system.
Watch out An undocumented dependency can turn a small change into a shutdown.
- 3
Select a bounded change
Choose the smallest intervention that produces a meaningful improvement or tests a critical assumption. Define its expected effect before acting.
Pro tip Prefer a reversible slice that users can actually experience.
Watch out Tiny changes without a path to the target design become permanent patchwork.
- 4
Prepare the fallback
Decide how to restore the prior function if the intervention fails. Assign the signal and threshold that trigger reversal.
Pro tip Test the fallback before the live change where possible.
Watch out A rollback plan that has never been exercised may not be a real fallback.
- 5
Change under observation
Introduce the intervention while monitoring continuity and the intended improvement. Capture unexpected effects rather than relying on the implementation report.
Pro tip Use an independent signal to verify the user-facing result.
Watch out A successful deployment is not proof that the live outcome improved.
- 6
Learn and sequence
Keep, revise, or reverse the change based on evidence, then choose the next bounded intervention. Update the dependency map as the system evolves.
Pro tip Record why each change was retained before moving on.
Watch out Do not continue a predetermined sequence when live evidence contradicts it.
In the wild
A support team wants to replace its ticket workflow but cannot stop serving customers. It maps the intake and escalation dependencies, moves one queue to the new process with a tested fallback, compares response times and missed cases, and expands only after the pilot holds.
→ The service keeps operating while evidence from each live slice guides the migration.
Sadhguru's mechanic complains that a cardiologist earns far more for fixing a heart than he earns for fixing an engine. The cardiologist replies that the mechanic should try fixing the engine while it is running, highlighting the constraint of transforming a live system.
→ The joke supplies the governing analogy for incremental change under continuity constraints.
Common mistakes
Waiting for a blank canvas
The dependencies of a live system rarely disappear, so postponing change until they do can become permanent inaction.
Changing without a fallback
Continuity cannot be protected if failure is detected only after users lose the essential function.
Preserving an unsafe system
Incrementalism is inappropriate when continued operation creates immediate unacceptable harm.
Is it for you?
Best for
Legacy organizations, social systems, products, or personal routines where a total shutdown is impossible or harmful.
Not ideal for
Immediate emergencies where the current system is actively unsafe and must be stopped before incremental improvement.
From the transcript
“The thing is you have to rebuild it when it's on.”
“That is the whole challenge, isn't it?”
“that goes for the society, that goes for the world”
From the episode
Sadhguru (World’s No.1 Guru) PREDICTS: "There Is A Mental Health Pandemic Coming! & We Are On The Brink Of Extinction!"