Lewin's Change Model: Unfreeze, Change, Refreeze

Three stages, sixty years old, and routinely dismissed as too simple for continuous delivery. The middle stage is the one everyone plans. The third is the one that decides whether any of it lasts.

Aldermoor Health introduced a code review policy: two approvals on anything touching patient data. Announced properly, agreed in a team meeting, nobody objected, and for a fortnight compliance was total.

Six weeks later it was running at about one in three.

Nothing had been reversed. No decision was taken to drop it. What happened is that the platform still permitted a single-approval merge, nobody was notified when one happened, and one Friday afternoon somebody needed to ship. Then it was normal again.

The policy was never refrozen. It was being held in place by attention, and attention is a depreciating asset.

Refreeze means the old way now costs something

The stage gets read as "make it stick", which is a wish rather than a mechanism. The operational version is narrower and testable:

A change is refrozen when doing it the old way requires more effort, or produces a visible signal, than doing it the new way.

Until that's true, the new way is running on goodwill — and goodwill is spent by the first genuinely urgent Friday.

Aldermoor's fix took an afternoon: branch protection requiring two approvals on the relevant paths, and a weekly line in the team channel counting single-approval merges. The policy hasn't slipped since, and nobody has thought about it in months. That's what refrozen looks like — not enthusiasm, but the absence of any need for it.

The three levers, roughly in order of how well they hold:

Lever	Example	Holds because
The old way is removed	Old scheduling system decommissioned	There is nothing to revert to
The old way is blocked	Branch protection, required field	Reverting takes deliberate effort
The old way is visible	Weekly count posted publicly	Reverting is noticed
The new way is the default	New template pre-selected	Reverting takes a decision
People were asked nicely	Team agreement, announcement	It doesn't

The bottom row is where most changes live. It works exactly as long as someone is watching.

The test you can run: for a change your team made three months ago, ask whether someone could do it the old way today without anyone finding out. If yes, it isn't refrozen, and its current compliance rate is a measure of how recently you mentioned it.

Unfreezing is the same question, pointed backwards

The first stage fails the same way, and for the same reason: the existing way is already frozen — by defaults, by permissions, by muscle memory, by the fact that it works.

Announcing a change doesn't unfreeze anything. What unfreezes is making the current state's cost visible to the people who'd have to move, which is the urgency problem from the other direction.

The practical form: before rolling anything out, list what currently holds the old way in place. Usually it's mundane — a bookmark, a default in a dropdown, a template with the old field, a runbook that references the old tool, a permission set nobody has revisited. Each of those is a small freeze, and each will quietly restore the old behaviour no matter how good the new thing is.

The test: write down three things that make the old way easy right now. If you can't name three, you haven't looked — and those three are your rollout plan.

The "nothing refreezes any more" objection, and what survives it

The standard modern criticism: Lewin assumes organisations have stable states, and they don't. Continuous delivery, continuous reorganisation, nothing sits still long enough to freeze.

The criticism is right about organisations and wrong about practices.

Your architecture may change quarterly. But "we require two approvals on patient-data paths" is a practice, and a practice absolutely can be frozen — that's what a required check in the pipeline is. The confusion comes from reading refreeze as stop changing, when what it means is make this the new default so that departing from it takes effort.

So the model survives the objection with one adjustment: refreeze the mechanism, not the state. You are not trying to hold the system still. You are trying to ensure that when attention leaves, behaviour doesn't drift back — which is a property of defaults and guardrails, not of stability.

Where the criticism does land: for a change that will itself be replaced in eight weeks, refreezing is wasted effort. Don't build branch protection for an experiment.

The test: ask whether this change is meant to be permanent. If yes, it needs a mechanism. If it's an experiment, say so out loud, because an unrefrozen experiment reverting looks exactly like a failed change.

Where Lewin is the wrong instrument

Three stages is a small model, and its smallness is both its value and its limit.

• It has no view on individuals. It describes the organisation's state. Whether a specific person has adopted is ADKAR's question; how long they'll feel disoriented is Bridges'.

• It has no sequencing detail. "Change" as a single stage covers everything Kotter spends six steps on.

• It implies a beginning and an end, which suits a discrete change — a system migration, a policy — and suits continuous evolution badly.

• It says nothing about whether the change is right. A well-refrozen bad decision is worse than one that reverted.

What it does better than any of the others is the third stage. Kotter's step eight says anchor it in the culture; Lewin makes it a distinct phase with its own work, which is why it's the model to reach for when your problem is that changes keep sliding back.

The test: if your last three improvements have quietly reverted, don't reach for a bigger model. You have a refreeze problem, and it's the most mechanically fixable of all of them.

What to do this week

Pick a change from the last six months that you believe landed. Check it, rather than assuming — count how often the old way is still being used.

If it's slipping, don't relaunch it. Find the one thing that still makes the old path available, and close it. A required check, a removed permission, a changed default, a number posted weekly where people can see it.

Aldermoor's code review policy needed one branch-protection rule and one automated message. Both took an afternoon, neither required anyone's agreement a second time, and the difference between a policy that lasted six weeks and one that has held for a year was entirely mechanical.

Whether it slid back at all is the kind of thing a post-implementation review is for — and "the change reverted" is the most common finding nobody writes down, because by the time anyone notices, it doesn't feel like an event.