Technology organizations constantly face change: adopting new architectures, shifting to product-centric teams, introducing DevOps practices, or rolling out new tools. Yet many change efforts fail not because the technical solution is wrong, but because leaders underestimate the human and organizational side. John Kotter's 8-Step Change Model provides a structured way to lead change by building urgency, guiding coalitions, and embedding new behaviors. This article offers practical examples of the model in technology contexts, with a realistic software-team scenario, and a governance checklist for decision-makers.
Intro
Kotter's model, developed from research on successful transformations, consists of eight sequential steps: create urgency, form a powerful coalition, create a vision for change, communicate the vision, remove obstacles, create short-term wins, build on the change, and anchor the changes in corporate culture. While originally applied to large corporate turnarounds, the steps are equally relevant for technology teams facing changes such as moving to microservices, implementing agile at scale, or adopting a new security standard. The value for technology leaders is a clear roadmap to gain buy-in, overcome resistance, and sustain momentum. This guide is for engineering managers, IT directors, and technical founders who need to lead change, not just manage projects.
Management Context
Kotter's model applies when technology changes require significant shifts in how people work, not just new tools or processes. Unlike incremental improvements handled by continuous-improvement cycles like PDCA, or goal-setting frameworks like OKRs, Kotter's steps address the emotional and political barriers to transformation. The model is most useful when the change is cross-functional, has high stakes, and meets resistance. For example, moving from a project-based to a product-based operating model affects roles, funding, and reporting lines; it cannot be treated as a simple process tweak.
It is important to distinguish Kotter's model from adjacent methods. PDCA (Plan-Do-Check-Act) is a continuous-improvement cycle for existing processes with measurable baselines; it works when you can iterate small changes. OKRs (Objectives and Key Results) set outcome-based goals and are complementary but do not address the emotional journey of change. ADKAR focuses on individual transitions and can be used alongside Kotter, which operates at the organizational level. Stakeholder mapping helps identify affected parties but is not a full change framework. Kotter's strength is its emphasis on urgency, coalition building, and cultural anchoring, which many technology leaders overlook.
When not to use Kotter: if the change is a minor tool upgrade with low resistance, a simple communication and training plan may suffice. If the situation is a crisis requiring immediate action, a more directive approach may be needed. Also, Kotter assumes a top-down change with a guiding coalition; in highly decentralized or bottom-up cultures, you may need to adapt the steps. Finally, the model requires sustained effort; short-term wins must be genuine, not manufactured. Use Kotter when you need to change mindsets and behaviors across a team or organization, not just install software.
Technology Organization Example
Consider a mid-sized software company, AcmeTech, that decides to adopt a service-oriented architecture to improve scalability and team autonomy. The current monolithic application slows deployment and causes cross-team bottlenecks. The CTO sponsors the change, but the engineering organization of 200 developers is skeptical. Here is how Kotter's 8 steps could play out:
Step 1: Create Urgency The leadership team analyzes competitive threats and technical debt. They present data showing that release frequency has dropped 30% over two years and that competitors ship features faster. They hold town halls to explain the risks of inaction. Urgency is created by linking the change to business survival, not just technical preference.
Step 2: Form a Powerful Coalition A coalition is formed with the CTO, two respected principal engineers, the head of product, and an HR business partner. This group has the credibility, expertise, and authority to drive the change. They meet weekly to align on strategy.
Step 3: Create a Vision for Change The coalition drafts a vision: "Within 18 months, we will have a modular architecture that allows any team to deploy independently, with no cross-team coordination for releases." The vision is concrete and tied to business outcomes.
Step 4: Communicate the Vision The vision is communicated through all-hands meetings, internal blogs, and team-level Q&A sessions. Leaders repeat the message at every opportunity and link daily work to the vision. They use examples of successful decompositions in other companies (without claiming those as benchmarks).
Step 5: Remove Obstacles Obstacles are identified: outdated deployment processes, lack of containerization skills, and legacy code ownership. The coalition works to remove these: they invest in training, create a platform team to provide self-service infrastructure, and adjust performance reviews to reward modular design. They also address resistors, such as a senior manager who fears losing control, by involving him in the architecture review board.
Step 6: Create Short-Term Wins The first pilot is chosen: extract a small, low-risk module (e.g., the notification service) and run it as a separate service. The success metric is deployment frequency and lead time, with guardrails on error rates and support tickets. The win is celebrated and publicized.
Step 7: Build on the Change After the pilot, the team tackles more complex extractions. They use the credibility from the first win to justify further investment. They also refine their approach based on lessons learned, such as improving observability before extracting stateful services.
Step 8: Anchor the Changes in Culture To sustain the change, the organization updates its onboarding to teach the new architecture, includes modular design in engineering principles, and promotes the leaders who drove the change. The new way becomes "how we do things here."
This example illustrates a realistic application with specific roles, phases, and decision points. Note the pilot is narrow and measurable, as recommended for early validation.
Decision and Governance Checklist
Applying Kotter's model requires governance to ensure the change stays on track and decision rights are clear. The following checklist helps technology leaders assess readiness and monitor progress.
Kotter Step Governance Checklist
| Step | Key Questions | Decision Owner | Evidence to Review |
|---|---|---|---|
| Create Urgency | Is the case for change compelling and data-backed? | Sponsor (CTO/CIO) | Business metrics, competitive analysis |
| Form Coalition | Does the coalition have the right mix of authority, expertise, and credibility? | Sponsor | Stakeholder map, influence assessment |
| Create Vision | Is the vision clear, inspiring, and tied to outcomes? | Coalition | Vision statement, alignment with strategy |
| Communicate Vision | Are messages consistent and reaching all affected groups? | Communications lead | Communication plan, feedback surveys |
| Remove Obstacles | Have structural, process, and skill barriers been identified and addressed? | Change manager | Barrier log, action items |
| Create Short-Term Wins | Is there a defined pilot with metrics and guardrails? | Project lead | Pilot plan, success criteria |
| Build on Change | Are lessons from early wins being applied to expand the change? | Coalition | Retrospective findings, scaled plan |
| Anchor in Culture | Are new behaviors embedded in systems, rewards, and onboarding? | HR/People Ops | Updated policies, recognition programs |
In addition to step-by-step governance, leaders should use a decision log to document key choices, especially those that affect scope or resources. Regular change reviews (e.g., monthly steering committee) should ask: Are we still on track? Are we seeing the expected benefits? Do we need to adjust course? If the change is failing, leaders must decide to modify, continue, or stop based on evidence.
Continue/Modify/Stop Criteria
- Continue if: the coalition is active, short-term wins are meeting targets, and resistance is manageable.
- Modify if: progress is slower than expected, but the vision remains valid; or new obstacles emerge that require a pivot in approach.
- Stop if: the business case no longer holds, key sponsors withdraw, or the cost of change outweighs benefits.
Finally, avoid common pitfalls: skipping steps (especially urgency and coalition), declaring victory too early, and neglecting culture. The checklist ensures accountability and prevents the change from being seen as just another initiative.
Conclusion
Kotter's 8-Step Change Model offers technology leaders a disciplined way to lead transformations that require behavioral shifts. By following the steps, you can build momentum, overcome resistance, and make change stick. The key takeaways for practitioners are:
- Start with a compelling urgency based on data, not just technical preference.
- Form a coalition with the right mix of influence and expertise.
- Communicate a clear vision tied to business outcomes.
- Remove obstacles proactively, including skill gaps and legacy processes.
- Plan short-term wins with clear metrics and guardrails, and learn from them.
- Embed the change in culture through systems, rewards, and onboarding.
As you apply the model, use the governance checklist to assign decision rights and review progress. Remember that change is iterative; be ready to modify your approach based on evidence. Finally, distinguish Kotter from other tools: use PDCA for continuous improvement of existing processes, OKRs for goal setting, and Kotter for large-scale behavioral change. With careful application, you can increase the odds of success for your technology change initiatives.