Build in Small, Reversible Moves

There is a season every organization knows: the new system arrives. New platform, new org chart, new process, launched building-wide on a Monday, preceded by a town hall and a logo. Six months later, half of it is quietly abandoned, workarounds have grown over the rest like vines, and the next leader who says the word improvement watches the room's eyes go flat.

The failure gets blamed on resistance to change. I want to argue the resistance was earned, and that the problem was not the change but its shape: too big, too final, too fast for anyone to check the fit. My operating rule, in schools, in consulting, in every system I build, is the opposite shape. Prefer small, reversible changes. It is slower on the calendar and dramatically faster in reality, because it is the only shape that does not have to fight its own audience.

Change spends trust before it earns evidence

Every change draws on an account the org chart never shows: your people's willingness to absorb disruption on your word. The balance is finite. A massive, irreversible launch spends that balance all at once, before a single result exists to justify it. If the change works, you get some of the trust back, eventually. If it fails, or half-fails, which is the normal outcome for big designs meeting real conditions, the account empties, and the next change, however good, arrives at a room that has already paid too much for promises.

Small reversible moves invert the cash flow. Each one costs little, returns evidence quickly, and, kept or killed, demonstrates the same thing: changes here are experiments with adults in charge, not weather to be survived. Weick made this case for small wins long ago, noting that small concrete successes reduce the perceived stakes, attract allies, and lower the cost of the next attempt (Weick, 1984). The compounding is the point. A dozen kept small promises will move an institution farther than one grand launch, and leave it more willing to move again.

You cannot safely change what you have not mapped

The discipline starts before the first move. Inventory and map before reorganizing, always. Describe the current system as it actually runs, who touches what, in what order, where the workarounds live and what pain they are quietly absorbing. Workarounds especially: every one is a design document written by the people closest to the work, describing a failure the official process refuses to acknowledge.

Skipping the map is how confident redesigns delete load-bearing oddities. That folder structure that looks chaotic is holding someone's audit trail. The duplicate approval step everyone mocks exists because of an incident nobody wrote down. Mapping first is not caution for its own sake. It is respect for the intelligence already embedded in the current system, including the intelligence that was never asked to explain itself.

Reversibility is what makes feedback honest

Here is the connection to listening that makes this more than project management advice. People will only tell you the truth about a change they can afford to see fail.

When a rollout is final, feedback becomes politics. Criticizing the new system means declaring the leadership wrong, permanently, in public, so people route around it silently instead and your information dries up exactly when you need it most. When a change is explicitly a pilot, with a named end date and a stated rollback path, criticism becomes cheap and useful. We tried it, this part fights the Tuesday schedule, is suddenly a safe sentence. The rollback path is not an admission of doubt. It is the purchase price of honest data.

So every move I make carries the same tags: what we are trying, for how long, what observable result decides, and what happens if it fails. If we cannot state the rollback, the change is not ready. If the change genuinely cannot be reversed, it earns a different level of scrutiny, and a pilot of everything around it first.

What this looks like in a week

For example, when I reorganize anything that people depend on, files, workflows, schedules, the sequence is fixed. Map the current state. Propose each move with its reason and its risk level written down. Move one bounded piece, with the old path preserved. Let it run. Ask the people who live in it what broke, using questions specific enough to answer. Keep or revert, say which and why, then take the next piece.

Nothing about the sequence is clever. Its entire virtue is that at no point does anyone have to trust me very much. The system improves in daylight, at a pace people can check, and reversibility means my mistakes are lessons instead of monuments. Small moves, honestly tagged, fully reversible. It is the least dramatic theory of change I know, and the only one I have seen leave trust higher than it found it.