Change Leadership Retrospective

Compare what the change promised with what it delivered, sort what to keep, stop and start, check whether the new way of working is actually sticking, and turn the lessons into changes someone owns.

Practice, not research: the retrospective format here. Structured debriefs improve performance on average (strong research: Tannenbaum & Cerasoli, 2013; Keiser & Arthur, 2021), though those studies tested debriefs in training and professional settings, not change retrospectives as such. Kotter's (1996) warning against declaring victory too soon is consulting practice. Judging a change by sustained adoption follows diffusion research, which is strong as a description of how new practices spread (Rogers, 2003).

Use it when:

• A change you led has gone live or been stopped, and you want to learn from it before memories soften.
• You are about to start a similar change and want last time's lessons in front of you.
• A change is halfway through and stalling, and you need an honest midpoint review.

Skip it when:

• You want a team retrospective on a project's delivery: use 8.12 Project Retrospective.
• The change has not started yet: use 3.7 Change Context Scan.

A change retrospective exists to counter two habits of change leaders. The first is declaring victory too soon. In Kotter's (1996) account of why transformations fail, celebrating the launch before the new behavior has taken root is a classic error, because the old way returns once attention moves on; his model is consulting practice, but this warning is widely shared. The second is measuring the wrong finish line. Diffusion research describes adoption as something that spreads through a population over time (Rogers, 2003), so the honest result of a change is the new practice in daily use, not a closed project plan.

Memory works against you too. Lessons fade, and success is easier to recall and safer to say aloud than failure, so the record drifts toward the flattering version. The page therefore starts from what was promised, forces each area to have a keep, a stop and a start, asks for evidence that the change is sticking, and ends with lessons that have an owner, since a lesson nobody acts on is only a diary entry.

Say what you are reviewing and from where you saw it. Invite at least one person who had to live with the change, not only those who ran it.

Strong answer: "New shift-swap system for drivers, February to September. My role: project sponsor and depot manager. Status: partially successful. Present: the project lead, two team leaders and two drivers from the night shift."

The change and the period:

Your role in it:

Status: ☐ Successful ☐ Partially successful ☐ Failed ☐ Stopped

Who took part (roles), including from the receiving end:

Illustrative example: the company, the roles and the figures are made up.

A regional bus operator in Norway replaced phone-based shift swaps with an app for drivers.

Step 1: the depot manager, who sponsored the change, rated it partially successful. Two night-shift drivers joined the review alongside the project lead and two team leaders.

Step 2: self-service swaps worked on day shifts; night shifts still phoned the office. The main reason was his own decision to train only during day hours to save overtime.

Step 3: keep team leaders presenting the change; stop announcing by email; start one briefing per shift. On his own leadership: keep visiting the depot weekly; stop accepting status reports without asking drivers; start checking adoption by shift, not in total.

Step 4: somewhat sticking. The office still handled a large share of swaps, nearly all from night shift. The office stops taking phone swaps once every shift has had a session.

Step 5: three lessons with owners: training on all shifts, adoption tracked by group, and the office's own role in the old way of working planned from the start.