Change Management

Most change efforts aren't defeated by resistance. They fail on how they arrive. Some changes have no real reason behind them beyond the appeal of something new. Others are sound but arrive without anyone in authority attached, so the first person who notices them treats them as an incident. Some are announced as a clean break with no plan for the years of live work still running on the old way. And some processes are rebuilt every quarter, so nothing stays in place long enough to prove itself.

This practice covers changing how people work: a new process, a new tool, a new system or a reorganized team. It treats resistance as information, insists on a reason for every change, gets authority attached before the work starts, and changes the conditions people work in rather than relying on reminders.

When to use this

• Use it when introducing a new process, tool or methodology, including AI-assisted development tools.
• Use it when a project's outcome depends on people working differently after it ships.
• Use it when changing the team's own delivery process.
• Use it when a change has met resistance and nobody is sure whether the resistance is right.
• Replacing a system is a portfolio decision as well; pair this practice with the evolve-or-replace steps in Portfolio & Program Management.

Principles

Every change answers to a real pressure. A business request, a user problem, a constraint discovered in production, or an assumption that stopped holding. Without one, change is motion mistaken for progress.

How a change arrives decides how it's judged. A change ordered from the top inherits legitimacy from whoever ordered it. A change that grows from the team has to earn legitimacy after the fact, usually in a room it didn't choose. Getting a sponsor attached before the work begins removes most of that difference.

Resistance is information. Hesitation about an unfamiliar tool usually comes from real scar tissue: shadow IT, unreviewed dependencies, decisions that became someone else's maintenance burden. Answer the concern with facts about what the change actually is.

Change the conditions, not the people. If the same problem keeps coming back across projects and people, the environment is producing it. A reminder fails under deadline pressure; a template, a default or a built-in step doesn't.

Prefer steps to leaps. Change in steps that each leave the organization better off, so it can stop at any point with a net gain.

Maintain the process; change it deliberately. Patch what leaks. Overhauling a working process every quarter burns the trust and habits that made it worth having.

Adoption is stronger evidence than approval. Voluntary, repeated use with nobody watching says a change works. Full attendance at a rollout and full license counts don't.

The practice

Name the pressure

1. Write down why the change is needed, where the pressure comes from, and the evidence for it.
2. State the outcome the change should produce and how you'll measure it, in the same way as any other outcome.
3. If you can't name the pressure, don't start. "It's what everyone is moving to" describes a trend, not a reason. I won't start a change I can't explain in one sentence to the people it affects.

Assess readiness

1. List who is affected and what each group loses: familiar processes, roles, control, or time while they learn.
2. Ask what has gone wrong with past changes of this kind. That history is where most resistance will come from.
3. Describe the current state honestly, including the workarounds people rely on. A change that removes an undocumented workaround breaks something nobody listed.

Attach authority before the work begins

1. Get a named sponsor who has already agreed the change is worth trying and can absorb the first wave of pushback without escalating it.
2. Write a one-page answer to the questions the most skeptical reviewers will ask, such as security, legal, cost and support, before anyone asks them.
3. Present the change as shared work, not one person's project. When a change is tied to a single advocate, attacking the change becomes a way of attacking the person.

Change in steps

1. Start with one team or one workflow, with an end date and an exit condition for the pilot.
2. Make each step leave things better than before, so stopping is always an option.
3. Announce each step as stop, start and continue: what ends, what begins, and what deliberately stays the same. People resist most when they can't tell what's being taken away.
4. Expand only when the adoption evidence from the previous step is in.
5. Decide in advance when the old way stops being supported, and who supports both ways until then. Running two ways with no end date doubles the cost of the work and halves the adoption of the new way.

Work with resistance

1. Listen first, and sort each concern by its cause using the table in Decision aids.
2. Answer misunderstandings with facts, and as early as possible. Once something unfamiliar has been classified as a risk, reclassifying it is much harder than getting the first read right.
3. Bring the people with the strongest objections into solving the problems they raised. They often see failure modes the advocates missed.
4. Treat a concern that turns out to be right as a finding. Change the plan, and say so.

Build the change into the conditions

When a change depends on people remembering to do something new, look for a place the behavior can live instead: a template, a default, a step in the pipeline, an artifact the next stage needs. I trust a process that gives the right behavior a natural place to happen far more than one that relies on memory, because memory is the first thing to fail when a deadline arrives.

Sustain and measure adoption

1. Measure use, not rollout: how many people use the change in their real work, how often, and whether they've stopped using the old way.
2. Ask the people doing the work. A rollout with full attendance and no enthusiasm looks the same on a status report as one that's working.
3. Keep what works. Once the change is adopted, patch problems as they appear rather than redesigning it on the next reorganization.

Decision aids

Is this change justified?

• What pressure caused it, and what's the evidence?
• What outcome will it produce, and how will that be measured?
• Who sponsors it, and have they agreed before work starts?
• What does the smallest useful first step look like?
• What would make you stop?

Reading resistance

Mandated or grassroots?

Who owns what

Signs it's going wrong

• The change is justified by what other organizations are doing, not by a pressure the business can name.
• An unfamiliar tool is rejected before anyone has looked at what it actually is.
• The team's process is redesigned every quarter, so nothing is ever measured long enough to judge.
• The same problem is handled with the same reminder in every retrospective. It needs a change in the conditions, not another reminder.
• Adoption is reported as training attendance or license counts.
• A pilot has no end date and never ends.
• People can't say what the change stopped. They'll assume it stopped everything familiar.

Related terms

Sponsor, Outcome, Exit Condition, Delivery Lead, PMO, Authority, Portfolio, Program

Where this came from

• The Methodology Tax: Why Grassroots Innovation Gets Rejected: how a change arrives decides how it's judged, sponsorship before the work begins, and adoption as stronger evidence than approval.
• DevSpark: Change Must Start With a Real Need: every change answers to a real pressure.
• The Beaver Builds a Pond: changing the conditions that produce a problem, and maintaining a process instead of rebuilding it.
• Evolution over Revolution: A Pragmatic Approach: changing in steps that each leave things better.
• QA Was Always My Last Battle Front: giving the right behavior a natural place to happen instead of relying on reminders.