Lewin's Change Model: Unfreeze, Change, Refreeze

Contributor
May 26
6 min read

Kurt Lewin proposed his three-stage change model in the 1940s. It is older, simpler, and less detailed than the modern frameworks. It is also more often right about the fundamental shape of organizational change than any of them. Strip away the specifics of ADKAR and Kotter and Bridges and you arrive at something close to Lewin: you have to make change possible before you make it, and you have to make it stick after.

This guide is the practical version for engineering teams.

The Three Stages

Unfreeze. Create the conditions where the current state can change. Surface dissatisfaction with how things are. Loosen the grip of established habits. Build motivation for the change.

Change. Implement the new way. Train people, build new tools, run new processes. Move from the old state to the new.

Refreeze. Make the new state stick. Institutionalize new habits. Establish new defaults. Resist the gravitational pull back to the old way.

The metaphor is from a block of ice. You can't reshape ice while it's frozen; you have to melt it first. After reshaping, you have to refreeze it or it loses its new shape.

Why Unfreezing Matters

The most common change management failure: jumping straight to "change." Leadership decides on the new state and announces it. The team is supposed to adopt it because it was decided.

This doesn't work because the team is currently frozen in the old state. The old way is comfortable, familiar, and works well enough. The energy of inertia is on its side. Without unfreezing, the announcement bounces off.

Unfreezing is the work of making the current state feel inadequate. Specific failures the team has experienced. Costs they've been paying. Better outcomes they could imagine. The goal isn't to manipulate; it's to make the team's actual experience of the current state explicit, so the case for change becomes self-evident rather than imposed.

Practical unfreezing techniques:

Surface incident data showing recurring problems the change would address
Bring in users or customers whose experience makes the current state's costs visible
Quantify the cost of the status quo (time spent on toil, incident frequency)
Show what teams in similar situations have done differently
Invite the team into the diagnosis — let them name the problems

The pattern that fails: announcing the change without first establishing the case for change. People assume the change is for someone else's benefit and resist.

The Change Itself

Once unfrozen, the change can happen. This is what most "change management" content focuses on, and it's the most documented stage.

Key practices:

Train people on the new way
Provide the tools and infrastructure that support it
Run the new process explicitly for a while, even if it feels awkward
Address obstacles as they come up
Allow the productivity dip that comes with learning new patterns

The work of the change stage is mechanical compared to unfreeze and refreeze — execute the plan. The reason changes fail isn't usually because this stage was done badly; it's because the bookends were skipped.

Why Refreezing Matters

Months after the change, the team has adopted the new pattern. Leadership declares victory and moves on. Two quarters later, half the team is back to the old pattern.

This is the refreeze failure, and it's pervasive. Without explicit reinforcement, organizations revert to their previous state. The old pattern was the default; the new one was the deviation. Without ongoing energy to maintain the new state, gravity pulls things back.

What refreezing actually requires:

New defaults in tooling — the new pattern is the path of least resistance
New onboarding — new hires learn the new way as the only way
New norms documented and visible — runbooks, READMEs, team agreements
The old pattern made unavailable where possible — turn off the legacy system, retire the deprecated tool
Reinforcement in performance reviews — what gets evaluated reflects the new state
Stories told about the change becoming "how we do things"

The most powerful refreeze technique: making the old way actively harder than the new way. As long as the old way is available and easier, the team will drift back under pressure.

A Worked Example

A team is moving from manual deploys to a CI/CD pipeline.

Unfreeze (2 weeks):

Pull data on the last quarter of incidents — 60% trace to manual deploy errors
Survey the team about their deployment experience — pain points are well-known
Invite a respected senior engineer to share their experience with CI/CD at a previous company
Discuss publicly: "the cost of how we deploy today is X. Here's what's possible."

By the end, the team agrees the current state is worth changing. Not because they were told to; because they've articulated the costs themselves.

Change (6 weeks):

Build the pipeline
Migrate services one at a time
Train the team on new tools and patterns
Run a 1-2 week period of dual operation (both methods work) so people can adopt gradually
Address issues as they come up

Refreeze (3 months):

Decommission the manual deploy mechanism — it's no longer an option
Update onboarding docs to teach only the new way
Update the deploy runbook to reference the pipeline as the only path
Build dashboards showing pipeline metrics, displayed visibly to the team
Mention pipeline adoption in performance reviews as expected baseline

Six months later, "we deploy through CI/CD" isn't even a thing people say. It's just how it works.

Where the Model Helps Most

Lewin's model is particularly useful for diagnosing where a change effort is stuck.

If the change feels imposed and resisted: you skipped unfreezing.

If the change is being adopted but slowly: you're in the change stage. Patience and execution.

If the change was adopted and is now slipping back: you skipped or under-invested in refreezing.

Each diagnosis points to a specific intervention. Detailed frameworks add nuance, but Lewin's three stages give you the right place to look first.

Where the Model Is Weak

The model is simple, which is both its strength and its limitation.

It doesn't address the political and emotional dimensions of change as well as Bridges or Kotter. It assumes change is roughly linear, which doesn't always hold. It's silent on the individual versus organizational levels of change, where ADKAR is explicit.

But for getting the basic shape right — that change has a before, a during, and an after, each requiring different work — Lewin remains the cleanest framework available.

Modern Critiques

Lewin's model has been criticized by some modern theorists for being too sequential, too rigid, and based on a metaphor (frozen state) that misrepresents how organizations work in fast-moving environments. The argument: in modern engineering orgs, you never really "freeze" anything because the environment is constantly evolving.

This critique is partly fair. In a rapidly evolving environment, the goal isn't to refreeze into a static state — it's to establish patterns that adapt to ongoing change. But this is still refreezing of a kind: refreezing the pattern of adaptation rather than refreezing a specific state.

A team that has internalized "we make small changes daily and roll back when things fail" has refrozen a meta-pattern. It's stable even though no specific state is permanent.

When to Reach for Lewin

For most change efforts, Lewin's model is the right place to start thinking. Three questions:

Have we built the case that this change is necessary? (Unfreezing)
Are we executing the change with adequate support? (Change)
What will keep the team from reverting? (Refreezing)

If any answer is unclear, that's where to focus.

For more detailed planning, layer ADKAR (for individual-level change), Bridges (for psychological transition), or Kotter (for political and leadership work) on top. But start with Lewin.

Key Takeaway

Lewin's three-stage model — unfreeze, change, refreeze — is the simplest useful framework for organizational change. Unfreezing builds motivation by making the current state feel inadequate. Change executes the new pattern. Refreezing makes it stick through new defaults, norms, and reinforcement. The most common failure is skipping unfreezing (announcing change without building the case) or refreezing (declaring victory before the new pattern is institutionalized). When a change effort is stuck, ask which of the three stages is missing. The answer is usually obvious once you look.

ShiftQuality