Change management is the structured approach to transitioning individuals, teams, and organisations from a current state to a desired future state. For engineering managers, change is constant - new tools, processes, architectures, and team structures require people to adapt their behaviour and habits. This guide provides a practical framework for leading change that sticks.
Change Management Models for Engineering Contexts
Several established models guide change management. Kotter's eight-step model begins with creating urgency, building a coalition, forming a strategic vision, enlisting volunteers, enabling action by removing barriers, generating short-term wins, sustaining acceleration, and instituting change. The ADKAR model focuses on individual change through five stages: Awareness, Desire, Knowledge, Ability, and Reinforcement.
For engineering managers, the Lewin model is often the most practical: Unfreeze (create readiness for change by helping people understand why the current state is unsustainable), Change (implement the new approach with support and resources), and Refreeze (stabilise the new approach through reinforcement and habit formation). This simple three-stage model provides enough structure without the complexity of larger frameworks.
Regardless of the model you choose, the fundamental principle is the same: people do not resist change itself - they resist being changed. Involving the team in designing the change, explaining the reasoning clearly, and providing adequate support during the transition dramatically increases the likelihood of successful adoption.
- Kotter's eight-step model provides a comprehensive roadmap for large-scale change
- ADKAR focuses on individual change through Awareness, Desire, Knowledge, Ability, and Reinforcement
- Lewin's Unfreeze-Change-Refreeze model is practical for team-level engineering changes
- People resist being changed, not change itself - involvement and communication are key
- Choose a model that fits the scale of your change - do not over-engineer small transitions
Planning Change Initiatives in Engineering Teams
Start every change initiative by articulating the case for change. Why is the current state unsatisfactory? What will be better after the change? What is the cost of not changing? If you cannot answer these questions clearly, the change is not ready to proceed. Engineers in particular respond to logical, evidence-based arguments - vague claims like 'this is best practice' will not generate buy-in.
Map the stakeholders who are affected by the change and assess their likely response. Identify champions who will advocate for the change, sceptics who need convincing, and resistors who may actively oppose it. Develop specific strategies for each group: give champions a visible role, provide sceptics with evidence and early results, and listen to resistors' concerns to understand what valid issues they may be raising.
Plan for the transition dip - the period after the change is introduced but before it has been mastered, when performance typically decreases. When an engineering team adopts a new deployment process, for example, the first few weeks will be slower and more error-prone as people learn the new workflow. Communicate this expected dip upfront and define how long you expect it to last, so the team does not mistake a temporary adjustment for evidence that the change was a bad idea.
Implementing Change Without Disrupting Delivery
Roll out changes incrementally whenever possible. Rather than switching the entire team to a new process on a Monday morning, pilot the change with a willing subset, gather feedback, refine the approach, and then expand. This reduces risk, provides evidence of effectiveness, and creates internal advocates who can help with broader adoption.
Provide adequate training and support during the transition. If you are adopting a new CI/CD tool, schedule pairing sessions where experienced users help newcomers. If you are changing the sprint planning process, facilitate the first few sessions yourself to model the new approach. Change fails when people are told what to do differently but not shown how to do it.
Maintain delivery expectations during the transition but adjust them to account for the learning curve. If the team typically delivers thirty story points per sprint, expect twenty to twenty-five during the first two to three sprints of a process change. Communicate this adjusted expectation to stakeholders proactively rather than explaining a velocity drop after the fact.
Understanding and Managing Resistance to Change
Resistance to change is a natural human response, not a character flaw. In engineering teams, resistance typically stems from rational concerns: fear of losing productivity while learning new tools, scepticism based on previous failed change initiatives, or genuine technical disagreements about the merits of the new approach. Treating resistance as something to overcome rather than understand is a recipe for failure.
Listen to resistance with genuine curiosity. Often, resistors have valid points that can improve the change plan if incorporated. A senior engineer who resists a new architecture may have experience with similar approaches that failed elsewhere. A team member who pushes back on a new process may have identified a practical issue the planners overlooked. Some of the best improvements to change plans come from the people who initially opposed them.
Distinguish between productive and unproductive resistance. Productive resistance raises specific, actionable concerns that can be addressed. Unproductive resistance manifests as generalised negativity without constructive alternatives. Address productive resistance by adjusting the plan; address unproductive resistance through one-on-one conversations that explore the underlying fear or frustration driving the behaviour.
Sustaining Change Over the Long Term
Many change initiatives succeed initially but fade over time as the organisation reverts to old habits. Sustaining change requires reinforcement: celebrating successes, measuring improvement, removing remnants of the old approach, and embedding the new way of working into team norms and documentation.
Update all relevant documentation, templates, and tooling to reflect the new approach. If the team's wiki still describes the old process, people will naturally revert to it. If the old tools are still available, people will use them instead of the new ones. Make the new way the path of least resistance by updating the environment to support it.
Track metrics that demonstrate the change's impact. If you changed your code review process to reduce cycle time, measure cycle time before and after. If you adopted a new testing framework to improve reliability, track defect rates. Concrete data showing improvement reinforces the change and justifies the disruption. If the data does not show improvement, be honest about it and either adjust the approach or reverse the change.
Key Takeaways
- Articulate a clear, evidence-based case for change before proceeding - engineers respond to logic and data
- Plan for the transition dip and communicate expected temporary performance decreases to stakeholders
- Roll out changes incrementally using pilots to reduce risk and build internal advocates
- Listen to resistance with curiosity - resistors often have valid concerns that improve the change plan
- Sustain change by updating documentation and tooling, and tracking metrics that demonstrate improvement
Frequently Asked Questions
- How do you manage change when the decision came from above and you disagree with it?
- Start by ensuring you fully understand the reasoning behind the decision - there may be context you lack. If you still disagree, advocate your position through appropriate channels, but do not undermine the decision to your team. Once the decision is final, commit to implementing it as effectively as possible. Your team will take their cue from you - if you are visibly reluctant, they will resist too. Present the change honestly, acknowledge your initial concerns, and focus on making the implementation as smooth as possible.
- How long should you give a change before evaluating whether it is working?
- Allow enough time for the team to move through the transition dip and reach baseline competency with the new approach. For process changes, this is typically three to six sprints. For tool changes, it might be one to three months. For cultural changes, six to twelve months is often needed. Define success criteria and evaluation timelines before the change begins, so you are not tempted to evaluate too early (during the transition dip) or too late (when it is difficult to reverse).
- How many changes can an engineering team absorb simultaneously?
- Less than you think. One significant change at a time is the general rule. Each change consumes cognitive capacity for learning, adaptation, and process adjustment. Multiple simultaneous changes create confusion about which new behaviour applies where and make it impossible to attribute outcomes to specific changes. If you have several changes to implement, sequence them with adequate time between each for the team to stabilise.
Explore Engineering Manager Templates
Download change management planning templates, stakeholder analysis worksheets, and transition communication guides designed for engineering managers.
Learn More