top of page

Change Readiness Checklist

S. West
42 minutes ago
4 min read

The migration was announced at an all-hands, with a deck and a deadline. Six months later, half the teams were still deploying the old way.

Engineering leadership had decided to move every service onto a new deployment platform. The case was sound and the platform worked. But the announcement was the last time most engineers heard about it, the old pipeline was never switched off, and performance reviews still rewarded shipping features over migrating. The two senior engineers everyone asked for advice had not been consulted, and quietly told their teams to wait and see.

(Composite example, assembled from patterns common in engineering organisations running platform migrations and reorgs. The figures are illustrative.)

John Kotter's eight steps are not a recipe. They are the components that, when one is missing, predict that a change will stall. This checklist uses them as a pre-flight check: run it before, and again during, any reorg, migration or process change, and treat a missing step as a red flag.

Score each item: ✅ solid, ⚠️ shaky or ❌ missing.

Step 1: establish urgency

  • ☐ About 75% of management is honestly convinced business as usual is unacceptable (Kotter's threshold).

  • ☐ The urgency is real (a strategic threat, operational pain or a regulatory deadline), not manufactured.

  • ☐ There is specific evidence, consequences someone owns and a real timeline.

  • ☐ Leadership stops approving distracting work, or the team reads the urgency as fake.

Modern failure: invented crises. The team sees through one once, then is cynical about every claim that follows.

Step 2: form a powerful coalition

  • ☐ An executive sponsor (VP or CTO) for political cover.

  • ☐ A delivery lead (director or principal) for implementation muscle.

  • ☐ A few respected senior engineers for credibility on the floor.

  • ☐ The person everyone asks when something breaks, as an adoption signal.

  • ☐ The coalition can actually decide and act. A formal name is optional.

Step 3: create a vision

  • ☐ Short and concrete ("our deploys are boring").

  • ☐ A new engineer can summarise it after one paragraph (Kotter's test: explainable in five minutes or less).

  • ☐ Sharp enough that some people disagree, not vision-by-committee mush.

Step 4: communicate the vision

  • ☐ The same message in the same language, repeated across many channels: all-hands, one-to-ones, roadmaps and onboarding.

  • ☐ Not a single launch deck followed by silence.

  • ☐ Peer to peer: engineers explaining it to each other in their own words.

Kotter found that transformation efforts under-communicate the vision by a factor of ten. The gap is probably worse now, with attention more fragmented.

Step 5: empower action by removing obstacles

  • ☐ Approval processes that take longer than the work: removed.

  • ☐ Budget rules blocking necessary spend: fixed.

  • ☐ Performance criteria still rewarding the old behaviour: updated.

  • ☐ Org structure or tooling that makes the new way harder: addressed.

Empowerment is mostly removing things, not adding a new working group.

Step 6: generate short-term wins

  • ☐ Visible to people who weren't involved.

  • ☐ Unambiguous: nobody can argue it didn't happen.

  • ☐ Clearly connected to the vision.

  • ☐ Achievable soon enough to keep belief alive. Kotter's 1995 benchmark was compelling evidence within 12 to 24 months; in a weekly-shipping org, aim for a first visible win within a quarter (our heuristic, not Kotter's).

Trap: declaring everything a win. If every update has three "wins", the word stops meaning anything.

Step 7: consolidate gains and tackle causes

  • ☐ You didn't declare victory and move on after the first win. That is the dangerous moment.

  • ☐ You are using early credibility to fix the hard, structural problems.

  • ☐ You are moving from symptoms to causes, for example:

Symptom

Underlying cause

On-call rotation is painful

The architecture pages people for things it should absorb

Deploy frequency is low

The testing strategy can't give fast confidence

______

______

Step 8: anchor it in the culture

  • ☐ New hires learn the new way as the default.

  • ☐ Performance reviews reward the new behaviour.

  • ☐ The old path is gone, so nobody can fall back to it.

  • ☐ The explicit artefacts are updated: onboarding docs, READMEs, the PR bot and dashboards.

Implicit cultural change can work in slow, stable organisations. With high turnover, you must update the explicit artefacts, because the people who carried the implicit version will leave.

Red-flag rule: any ❌ is a likely point of failure. Fix it before you push harder.

How to use it

  • Who: the change lead with the sponsor and one or two respected engineers who will tell you the truth. An hour for the first pass, then a short re-score at each milestone.

  • Output: a scored checklist, the ❌ and ⚠️ items with an owner each, and a decision on whether to proceed, pause or reshape the change.

  • Done when: no step is ❌, every ⚠️ has an owner and a date, and the old path has a planned switch-off.

Where this changes

The full eight-step sequence is overkill for small, continuous changes on a single team; for those, check urgency, vision and the old path being removed, and move on. Kotter's model also has known limits, so adjust for them:

  • Too top-down: pair sponsorship with bottom-up momentum.

  • Not linear: the steps interleave and recur, so loop back as needed.

  • Kotter's own 2012 revision ("Accelerate!") runs the steps concurrently with a volunteer network beside the hierarchy. Use it for continuous change.

  • Ignores individual psychology: pair it with ADKAR (Prosci) or Bridges' transition model for the human side. See the ADKAR model explained for tech leaders.

Large or regulated organisations need more than this page: a stakeholder map, a communications plan and formal sign-off at each stage. For the reasoning behind this checklist, read Kotter's 8-step change model: a modern take. When the ❌ items are about people rather than process, managing resistance to change in software teams goes deeper, and change management for engineering teams covers the wider practice.

Final takeaway

Most stalled changes were not short of effort; they were missing a step nobody checked. Score all eight before you announce, fix the ❌ items first, and switch the old path off so the new one is the only one left.

Sources

bottom of page