Small Moves

Patterns That Shift Systems Without Triggering Defensive Responses

The most effective changes often don't look like changes at all.

They look like process improvements. Efficiency gains. Clarifications. Small adjustments that make things work a little better. Nobody argues against them because there's nothing to argue against. By the time anyone notices something significant has shifted, the new way is already how things are done.

This isn't manipulation. It's recognition that organisational immune systems respond to perceived threats. Big announcements, transformation programmes, and requests for buy-in all trigger defensive responses. Small moves often don't.

This post is about patterns, not recipes. I'm going to show you shapes that effective change takes, not step-by-step instructions. The difference matters. Recipes get copied and misapplied. Patterns get recognised and adapted to context.

Use these patterns when you've done the diagnostic work from earlier in this series: when you've confirmed that your frustration is signal rather than noise, when you've tried legitimate influence and found its limits, and when you understand the system well enough to work with it rather than against it.

Changing defaults

The single most powerful intervention available to anyone trying to create change is changing defaults.

Defaults are what happen when nobody makes an active choice. The template people start from. The setting that's pre-selected. The option that requires no action. The way things are done, unless someone decides otherwise.

Most people, most of the time, accept defaults. Not because they've evaluated the options. Because choosing requires effort and accepting the default requires none.

This means whoever sets defaults shapes behaviour at scale, invisibly, without resistance. Nobody argues against a default because there's nothing to argue against. It's just how things are set up.

Some examples:

Meeting defaults. The default meeting length in most calendar systems is 60 minutes. Change it to 25 or 50 minutes, and meetings get shorter. Not because anyone decided meetings should be shorter, but because the default changed. People accept the default.

Template defaults. If a template includes a section for "risks and dependencies," people fill it out. If it doesn't, they don't think about risks and dependencies. The template determines what gets considered.

Opt-in vs opt-out. If people have to opt in to a new practice, few will. If they have to opt out, few will. The same practice with different default participation levels will have completely different adoption rates.

Review defaults. If code review is required before merge, the code gets reviewed. If it's optional, it doesn't happen. The default determines the behaviour, not the stated value of code review.

When you're trying to create change, ask: Can I change a default? It's often easier to change the starting point than to change people's minds.

Renaming without rebranding

Words shape perception. The name of something influences how people think about it, what associations they bring, and how much resistance they feel.

Sometimes the most effective change is calling the same thing by a different name.

This isn't about deception. It's about removing unnecessary friction. If a practice triggers resistance because of its name, but would be accepted under a different name, the name is the problem.

Some examples:

"Retrospective" vs "team review." Some organisations have allergic reactions to anything that sounds like agile. The same practice, called a "team review" or "lessons learned session," faces no resistance.

"Experiment" vs "pilot" vs "trial." These words have different connotations. "Experiment" suggests science and uncertainty. "Pilot" suggests aviation and controlled testing. "Trial" suggests law and evaluation. Choose the word that fits your organisation's culture.

"Technical debt" vs "maintenance backlog." "Debt" implies someone did something wrong. "Maintenance" implies normal upkeep. The same work gets a different reception depending on what you call it.

"Feedback" vs "input" vs "thoughts." "Feedback" can feel evaluative and threatening. "Input" sounds more collaborative. "Thoughts" is softer still. The same request, differently worded, gets different responses.

The test for whether this is legitimate: would you be comfortable explaining the rename if asked? If yes, it's removing friction. If no, it's hiding something.

Reframing without lying

Framing is how you position something: what you emphasise, what you connect it to, and what context you provide.

The same initiative can be framed as either a cost reduction or an investment in efficiency. Risk mitigation or opportunity creation. Process improvement or cultural change. Each frame invites different responses.

Reframing is choosing the frame that allows your idea to be heard. Not misrepresenting what it is, but emphasising the aspects that resonate with your audience.

Some examples:

From "we should" to "I'm going to." "We should have better documentation", invites debate about whether we should. "I'm going to document my area and share it", invites nothing because you're not asking for permission.

From problem to solution. "Our deployment process is broken" triggers defensiveness. "Here's an approach that would reduce deployment failures by 40%", invites curiosity.

From change to continuity. "We need to transform how we work" triggers filtering. "We're building on what's already working" doesn't.

From your needs to their goals. "I want to try pair programming" is about you. "This could help with the onboarding problem you mentioned" is about them.

The ethics: reframing is legitimate when all the frames are true. You're choosing which true thing to emphasise. It becomes illegitimate when you're hiding something material or misrepresenting what the initiative actually involves.

Pilots, shadows, and parallel paths

Sometimes the only way to prove something works is to do it. But doing it at scale requires approval you can't get without proof. This is the evidence catch-22.

The solution is to start small, in spaces where you have authority or can easily get permission.

Pilots. A time-limited, scope-limited trial. "Let us try this for one sprint with one team." Pilots are low-risk for approvers because they're contained and reversible. They generate evidence that can justify expansion.

Shadows. Running a new process alongside the existing one, without replacing it. "We'll keep doing it the old way for official purposes, but also try this new approach and compare." Shadows don't threaten anyone because nothing is being taken away.

Parallel paths. Different parts of the organisation trying different approaches. "Team A will continue with the current process, Team B will try an alternative." Parallel paths create natural experiments that generate comparative evidence.

The key is getting to evidence without requiring prior approval for the thing you need evidence to justify. You're not asking permission to change how the organisation works. You're asking permission to run a small experiment in your own space.

Once you have evidence, the conversation changes. You're no longer proposing something unproven. You're proposing to expand something that demonstrably works.

Making the implicit explicit

Organisations run on implicit norms: things everyone knows but nobody says. Often, these implicit norms are the actual obstacles to change, but they're hard to address because they go unacknowledged.

Making the implicit explicit is simply saying the unsaid thing. Not to shame or accuse, but to make it available for discussion.

Some examples:

"The unwritten rule seems to be..." Name the pattern you're observing. "The unwritten rule seems to be that we don't raise concerns in this meeting. Is that intentional?" This creates space to either confirm the norm (which makes it available for questioning) or deny it (which opens space to act differently).

"What I'm hearing is..." Reflect back what's being implied but not stated. "What I'm hearing is that this decision has already been made and this meeting is for communication, not input. Is that right?" Forces clarity about what the situation actually is.

"The constraint we're not naming is..." Surface hidden constraints. "The constraint we're not naming is that this would require headcount we're not going to get. Should we work within that constraint or challenge it?"

Asking naïve questions. "Why do we do it this way?" asked genuinely, not sarcastically. Often, the answer is "we don't know" or "it made sense five years ago." The question exposes that the current approach is a choice, not a necessity.

The power here lies in the fact that once something is explicit, it has to be defended. Implicit norms survive by not being examined. Making them explicit forces examination.

The risk: this can feel confrontational. The tone matters enormously. Genuine curiosity ("I'm trying to understand") works. Implicit accusation ("Why are we doing this stupid thing?") triggers defensiveness.

Working within your authority

Most people underestimate how much they can change without permission.

You probably have authority over how you do your own work, how you run meetings you own, how you communicate with your immediate team, what questions you ask, and what you pay attention to.

These feel like small things. They are small things. But they're small things you can do without asking anyone, which means they don't trigger the organisational immune system.

Some examples:

Run your meetings differently. If you run a weekly team meeting, you can change its format. Add a question. Remove an agenda item. Try a different structure. Nobody needs to approve this.

Document what you learn. You can write things down and share them. A weekly note, a project summary, a lessons-learned document. This creates visibility and shapes attention without requiring permission.

Ask different questions. In any meeting you attend, you can ask questions. The questions you ask shape what gets discussed. "What would we need to believe for this to be wrong?" is a different question than "What are the next steps?"

Model the behaviour. If you want more candour, be more candid. If you want more collaboration, collaborate more. If you want better feedback, give better feedback. You don't need permission to change your own behaviour.

Build things. Prototypes, proofs of concept, examples. Sometimes the most effective way to propose something is to build it and show people. "What if we did X?" invites debate. "I built X, want to see how it works?" invites curiosity.

The limitation is scale. Working within your authority can change how your team works. It can't change how the organisation works. But changing how your team works creates evidence, creates visibility, and can attract others who want to work differently.

When things go wrong

These patterns don't always work. Sometimes you'll try something and it will fail. Sometimes you'll be discovered and challenged. This section is about what to do when that happens.

If the pilot fails: Own it cleanly. "We tried X, it didn't work, here's what we learned." Failed experiments aren't shameful if you learn from them. They're only shameful if you hide them or refuse to acknowledge they failed.

If you're challenged on renaming: Explain your reasoning openly. "I called it Y because I've found that X triggers resistance before people consider the substance. I'm happy to call it X if you prefer." If you can't say this honestly, you were doing something less legitimate than renaming.

If your framing is questioned: Don't defend the frame, discuss the substance. "You're right that I emphasised the efficiency angle. The full picture includes these other considerations. Does that change your view?"

If you're accused of going around the process: Take it seriously. Maybe you were. "I hear that concern. My intent was to gather evidence before asking for a larger commitment. If that feels like circumventing the process, how should I approach this differently?"

If trust is damaged: You probably can't fix it quickly. Acknowledge what happened, apologise if appropriate, and demonstrate through behaviour over time that you're trustworthy. Don't expect a single conversation to repair what took many interactions to break.

The general principle: when caught or challenged, move toward transparency, not away from it. Defensiveness and justification make things worse. Openness and genuine accountability create the possibility of recovery.

The limits of small moves

Small moves are powerful, but they're not sufficient for everything.

They work well for changes that can start small and grow. Process improvements. Cultural shifts. New practices. Things that can demonstrate value incrementally.

They don't work well for changes that require coordinated action across the organisation. Structural reorganisation. Major strategic shifts. Changes that only work at scale.

They also don't work well when the immune system is actively hostile rather than passively filtering. If there's a senior leader who has explicitly decided your direction is wrong, small moves won't help. They'll be noticed and stopped.

Know what small moves can and can't do. They're one set of tools, not the only set.

The accumulation of small things

Systems don't change through single interventions. They change through the accumulation of many small shifts that eventually add up to a different way of operating.

Each small move on its own is trivial. A renamed meeting. A new question in a retrospective. A pilot that nobody noticed. But over time, these accumulate. Norms shift. Defaults change. What was once novel becomes ordinary.

This is the evolutionary nature of the change this series describes. Not revolution. Not transformation. Gradual adaptation through many small variations, some of which survive and spread.

It requires patience. The frustration that motivated you to read this series wants fast results. Small moves don't provide fast results. They provide durable results, which is different and, ultimately, more valuable.

Next in the series: why change is social before it's structural, and how to build the networks that make evolutionary change possible.