You introduce a new system, explain the process, train the people involved, and demonstrate that the new approach works. Yet people can return to the previous way of working as soon as they have the choice.
It’s tempting to call this resistance and respond with another explanation, another training session, or another reminder. These actions focus on whether people know what to do. They don’t explain why the previous behaviour still makes sense.
When people return to old ways after organizational change, look beyond their willingness to adopt the new process. Their choices may be showing you that parts of the organization still support the former way of working.
Ask yourself: What does the old way continue to make easier, safer, or more predictable? The answer will reveal what your change hasn’t addressed yet.
Examine the Conditions That Still Support the Old Way
Start with the environment in which people make their daily choices. Look at the incentives, performance measures, processes, decision rights, technology, leadership signals, and consequences around them.
A new process may require collaboration while individual performance measures reward a different behaviour. A new tool may be available, but people may still need the previous tool to complete part of their work.
The same conflict can appear in decision-making. Decision rights may have changed in the documented process, while people continue waiting for the same approval because leadership still expects them to wait.
The instruction has changed, but an important part of the operating environment hasn’t. Choosing the previous approach can make sense when that environment still makes it easier, safer, or more predictable.
Repeating the message won’t remove this conflict. Another training session won’t change the measures, tools, expectations, or consequences shaping people’s choices. You first need to identify which condition continues to favour the previous behaviour.
You also need to consider whether the new approach puts some people at a genuine disadvantage. A change can reduce their autonomy, increase their workload, eliminate a role, or disadvantage one function to produce value somewhere else.
If leadership intends to make that trade-off, don’t try to convince the affected people that the change is better for them. State the trade-off clearly, explain why the organization selected it, and describe what it means for everyone affected.
If leadership didn’t consciously select the trade-off, the objection gives you information about the quality of the decision. Leadership must then decide whether to accept the consequences or reconsider the change.
This doesn’t mean that every objection should determine the direction of your transformation. Resistance provides information, but it doesn’t make the decision for you. You can examine the cause of an objection without accepting the objection itself.
Learn From the Moments When People Revert
Your design and rollout can’t reveal everything about how the new approach will work. Some information only becomes available after people begin using it.
Don’t limit your assessment to whether people follow the process when asked. Study the points at which they choose the former approach instead.
Look for workarounds and handoffs that move outside the new process. Examine how people respond when work becomes urgent, when they encounter an exception, or when they need to recover from a problem. Then, compare those situations with how the work happened before the change.
These choices may show that the surrounding environment still favours the previous behaviour. They may also show that the new approach hasn’t gained enough trust.
People may know exactly how to follow the new process and still choose the old way when given the opportunity. That second behaviour deserves your attention because it shows which approach they actually trust.
This is why your transformation plan needs time, ownership, and capacity after launch. Someone must examine what adoption reveals, identify the conditions behind each rational objection, and decide what response is needed.
Without that work, the plan treats the launch as the end of the change. A live system, completed training, and delivered communications show that the planned rollout activities happened. They don’t show whether the organization can succeed with the new approach without depending on former processes and workarounds.
Decide Whether the Change Is Finished
Before you declare a change complete, examine what people choose when both approaches remain available.
Find the points where the former behaviour returns and ask what that behaviour provides in each situation. Then, connect the choice to the relevant incentive, measure, process, decision right, technology, leadership signal, or consequence.
If the operating environment continues to make the old way easier, safer, or more predictable, change that environment. A different process can’t become sustainable while the conditions around it continue supporting the behaviour it was meant to replace.
If the new approach disadvantages some people, leadership must decide whether it consciously chooses that trade-off. If the answer is yes, state the trade-off and accept its consequences. If the answer is no, revise the change.
Tomorrow, find one place where people are returning to the old way.
Ask what that behaviour still makes easier, safer, or more predictable.
Then decide whether you need to change the environment around the new way or reconsider the change itself.
If you’re changing how software delivery works, Nave helps you see what is actually changing in the delivery system, investigate where work is slowing down, and measure whether your interventions improved it. Learn more at getnave.com.
Your change isn’t finished while people still have a rational reason to choose the old way.
I’ll see you next week, same time and place for more managerial goodness. Bye for now!
