## Intro Technology leaders often face decisions where the path forward is not obvious: migrate to a new platform, restructure delivery teams, replace a legacy system, or adopt a new operating model. Kotter's 8-Step Change Model provides a structured way to move from recognizing the need for change to making it stick. It is especially useful when a team needs to align priorities, reduce ambiguity, and connect technology work to business outcomes. This article is for managers, founders, product leaders, IT leaders, and technical teams who want to apply Kotter's model to real decisions. It focuses on technology change, organizational change, digital transformation, and change leadership. The goal is practical: define the decision, involve the right people, document tradeoffs, choose measurable signals, and review whether the decision created useful value. By the end, you will be able to apply Kotter's 8-Step Change Model to a real decision in your organization, not just describe it in the abstract. We will cover the eight steps, provide a concrete example of a technology organization facing a platform migration, offer a decision and governance checklist, and discuss common pitfalls with ways to avoid them. ## Understanding Kotter's 8-Step Change Model John Kotter, a professor at Harvard Business School, introduced the 8-Step Change Model in his 1996 book Leading Change . The model is designed to help organizations successfully implement transformational change by addressing both the process and the human side. The eight steps are: - Create a sense of urgency : Help others see the need for change and the importance of acting immediately. - Build a guiding coalition : Assemble a group with enough power and influence to lead the change. - Form a strategic vision and initiatives : Clarify how the future will be different and how to get there. - Enlist a volunteer army : Communicate the vision broadly and get buy-in from many people. - Enable action by removing barriers : Remove obstacles and empower others to execute the vision. - Generate short-term wins : Produce visible successes early to build momentum and silence critics. - Sustain acceleration : Build on the wins to tackle bigger changes and avoid declaring victory too soon. - Institute change : Make the change stick by embedding it into the culture and processes. While the steps are often presented sequentially, in practice they overlap and may need to be revisited. For technology and organizational change, this model helps leaders avoid common failures such as moving too fast without buy-in, ignoring cultural resistance, or declaring victory prematurely. ## Applying Kotter's Model to Technology Change Technology changes—whether adopting cloud infrastructure, implementing a new ERP system, or shifting to DevOps—are not just technical projects; they are organizational changes. Kotter's model helps ensure that the human and structural aspects are addressed alongside the technical work. Consider a scenario where a mid-sized software company, Acme Corp, decides to migrate its monolithic application to microservices to improve scalability and developer productivity. Using Kotter's model, here is how the leadership might proceed: Step 1: Create a sense of urgency The CTO presents data showing that the monolith's deployment frequency has decreased from 20 per week to 5 per week over the past year, while customer-reported incidents have doubled. She explains that scaling the system to meet projected demand will be impossible without a change. She sets a goal: within 18 months, reduce deployment lead time from 3 days to 2 hours and increase deployment frequency to 50 per week. Step 2: Build a guiding coalition The CTO recruits a cross-functional coalition: the VP of Engineering, the Product Director, a lead architect, a senior operations manager, and two influential senior engineers. This group meets weekly to drive the migration strategy and address roadblocks. Step 3: Form a strategic vision and initiatives The coalition crafts a vision: "A modular architecture that enables independent deployment, faster feature delivery, and improved system resilience." They break this into initiatives: decompose the monolith into 12 services over 6 months, implement CI/CD pipelines for each service, and train development teams on new tools and practices. Step 4: Enlist a volunteer army The vision is communicated through all-hands meetings, internal blogs, and team workshops. The coalition identifies change champions within each team who are enthusiastic about microservices and can influence their peers. They also gather feedback early to address concerns. Step 5: Enable action by removing barriers The leadership removes obstacles: legacy deployment approvals that require manual sign-off are replaced with automated checks; a dedicated platform team is created to support service infrastructure; and training budgets are allocated for cloud-native technologies. Step 6: Generate short-term wins The first service is extracted and deployed independently within 8 weeks. The team celebrates this win publicly, showing that deployment lead time for that service dropped from 3 days to 4 hours. This builds credibility and momentum. Step 7: Sustain acceleration Buoyed by success, the coalition pushes to extract more services, addressing deeper architectural issues. They resist declaring victory after a few services are migrated; instead, they set new goals, such as achieving zero-downtime deployments and implementing robust monitoring. Step 8: Institute change To make the change stick, the CTO updates performance metrics to include deployment frequency and lead time for all teams. New hire onboarding includes microservices training. The architecture review board now requires new services to follow microservices patterns unless justified. Over time, the microservices architecture becomes the new normal. This example shows how the eight steps translate into concrete actions for technology change. ## Management Context: Defining the Decision When applying Kotter's model, start by naming the management problem clearly. What is the decision to make? Who is affected? What are the constraints and available evidence? In practice, produce a concrete artifact: a decision record, priority list, stakeholder map, risk view, operating principle, metric definition, or follow-up owner. For instance, before initiating the microservices migration, Acme's CTO drafted a one-page decision record that stated: - Decision : Migrate the core application from monolith to microservices. - Owner : CTO (Jane Smith) - Affected parties : 5 product teams, operations, support, customers. - Constraints : Budget of $500,000, timeline of 18 months, no more than 10% downtime during transition. - Evidence : Current monolith deployment lead time is 3 days; target is 2 hours. Customer incident data shows a 40% increase in critical bugs. - Options considered : (1) Refactor monolith in place, (2) Rewrite as microservices, (3) Adopt a serverless architecture. - Decision rationale : Microservices best balance scalability, team autonomy, and incremental migration. This record becomes a living document, revised as new stakeholder input or evidence emerges. Key concepts to consider include technology change, organizational change, digital transformation, and change leadership. Related areas like the ADKAR Model (which focuses on individual change), change management frameworks, and stakeholder mapping help test whether the decision is aligned with strategy, governance, adoption, and measurable value. ## Technology Organization Example in Depth Let's explore a second example: a technology organization deciding whether to replace its legacy ticketing system with a modern IT service management (ITSM) platform. The decision is whether to fund the platform improvement, delay a product feature, or reduce operational risk. In this case, the IT director, Priya Shah, uses Kotter's model to guide the change. Step 1: Urgency Priya gathers data: the current system has 15% downtime monthly, agents spend 30 minutes per ticket on manual data entry, and user satisfaction is at 55%. Competitors have moved to AI-assisted platforms, and support costs have risen 20% year over year. Step 2: Coalition Priya forms a coalition including the VP of Operations, the Head of Support, two senior support agents, and a procurement specialist. Step 3: Vision The vision: "A streamlined, AI-enhanced support system that reduces resolution time by 50% and improves agent productivity." Step 4: Communication Priya holds town halls and team meetings, explaining why the current system is failing and how the new platform will help. She addresses fears about job changes by emphasizing training and new roles. Step 5: Removing barriers The coalition negotiates with procurement to expedite the purchase, arranges for data migration support, and ensures all agents have access to training before go-live. Step 6: Short-term wins They pilot the new system with one support team for two weeks. Average ticket resolution time drops from 24 hours to 18 hours, and agent feedback is positive. This win is shared company-wide. Step 7: Sustain acceleration They roll out the system to all teams, integrating AI suggestions and improving knowledge articles. They monitor metrics and fix issues promptly. Step 8: Institute change The new system becomes the standard. Hiring includes training on it. The old system is decommissioned after 6 months. Regular reviews ensure continuous improvement. The useful output from this example is a short decision record, as described in the previous section, and a plan for follow-up. Within this context, related topics like ADKAR (which can be used to assess individual readiness for the new tool), change management, and stakeholder mapping help test whether the decision considers adoption, governance, and measurable value. Document what was actually observed after the decision, not just what was planned. For example, after the new ITSM platform was implemented, Priya recorded that average resolution time actually decreased by 35% (not the projected 50%), and user satisfaction rose to 70% (from 55%). These real numbers inform future changes. ## Decision and Governance Checklist To effectively govern a change initiative using Kotter's model, use a simple review checklist that includes: - What decision is being made? - Who owns the decision? - Who is affected? - What options exist? - What evidence is available? - What risk is acceptable? - What metric will show progress? Assign each item a named owner (not a group) and a review cadence. For example:
Checklist ItemOwnerReview Frequency
Define decision and scopeCTO (Jane Smith)Quarterly
Identify stakeholders and impactProduct Director (Mark Lee)Monthly
Generate and evaluate optionsLead Architect (Alex Chen)Weekly during planning
Collect evidence and dataData Analyst (Sara Patel)Bi-weekly
Assess risks and mitigationRisk Manager (Tom Wilson)Monthly
Select and track metricsEngineering Manager (Chris Garcia)Weekly
Review overall progress and adjustSteering CommitteeMonthly
For each decision, useful metrics may include cycle time, adoption rate, stakeholder satisfaction, cost avoided, risk reduction, delivery predictability, customer impact, or portfolio balance. The right metric depends on the decision, not the framework name. For instance, for the microservices migration, key metrics were deployment lead time and deployment frequency; for the ITSM replacement, ticket resolution time and user satisfaction. Always ask whether the decision would change if you considered related concepts like ADKAR, change management, and stakeholder mapping. A framework is only useful if it improves the quality and timing of real decisions. The named owner for the checklist itself should ensure it is revisited on schedule, not treated as a one-time exercise. In Acme's case, Jane Smith (CTO) owns the overall checklist and reviews it with the coalition monthly. ## Common Pitfalls and How to Avoid Them Even with a solid model, change efforts can falter. Here are common pitfalls when applying Kotter's model to technology and organizational change, why they happen, and how to avoid or recover from them. 1. Skipping or rushing the urgency phase - Why it happens : Leaders assume the need for change is obvious, or they fear causing alarm. - How to avoid : Use data to clearly articulate the threat or opportunity. For example, instead of saying "we need to modernize," say "our release cycle is 3 times slower than industry average, costing us $200,000 per month in lost revenue." - How to recover : If you skipped urgency and people are not engaged, stop and present the data. A compelling business case can reset the conversation. 2. Building a weak guiding coalition - Why : Leaders pick only their direct reports or people who agree with them, missing key influencers or those with formal authority. - Avoid : Include a mix of roles, seniority, and perspectives. Ensure the coalition has enough power to make decisions. - Recover : If the coalition is failing, reassess membership. Add a respected skeptic or a high-level sponsor who can remove barriers. 3. Poorly communicating the vision - Why : The vision is too vague, or leaders assume one email or town hall is enough. - Avoid : Craft a vision that is clear, compelling, and tied to personal benefits. Communicate it through multiple channels and repeat it often. - Recover : Re-communicate using stories and examples. Ask employees to explain the vision in their own words to check understanding. 4. Not removing barriers - Why : Leaders fail to identify obstacles such as outdated processes, lack of skills, or resistant middle managers. - Avoid : During planning, map potential barriers and assign owners to address them. For example, if procurement delays new hardware, get early approval from finance. - Recover : When barriers appear, act quickly. Remove or reassign individuals who block progress, or provide training where skills are lacking. 5. Expecting major wins too early - Why : Leaders get impatient and want to show dramatic results quickly. - Avoid : Plan for short-term wins that are achievable within 1-3 months. These should be visible and meaningful but not require the full transformation. - Recover : If no wins are forthcoming, create a smaller win by tackling a low-hanging fruit. For instance, automate a simple, painful process to show immediate improvement. 6. Declaring victory too soon - Why : After a few wins, leaders may feel the change is done and relax. - Avoid : Set long-term goals beyond the initial wins. Use metrics to show that more work is needed. - Recover : If you declared victory prematurely, re-evaluate the new status quo against the original vision. If gaps remain, re-engage the coalition and relaunch urgency. 7. Failing to anchor changes in culture - Why : Leaders neglect to update systems, processes, and norms that reinforce the old way. - Avoid : Identify how the change will be institutionalized: update performance reviews, hiring criteria, onboarding, and rewards. - Recover : If old behaviors creep back, review which systems still support the old way and change them. For example, if employees still use the old ticketing system because it's not decommissioned, decommission it. 8. Ignoring individual change - Why : Kotter's model is organizational, but individuals need to change too. Leaders may overlook personal resistance. - Avoid : Pair Kotter's model with the ADKAR Model for individual change management. ADKAR stands for Awareness, Desire, Knowledge, Ability, Reinforcement. Assess each person's ADKAR profile and address gaps. - Recover : If resistance is high, conduct ADKAR assessments and provide targeted coaching or training. By being aware of these pitfalls, you can proactively plan to avoid them and react effectively if they occur. ## Conclusion Kotter's 8-Step Change Model works best when used as a decision discipline, not a slide-deck exercise. The value comes from explicit criteria, clear ownership, realistic constraints, and regular review. It helps make disagreement visible early, shows why a choice was made, and helps the team adjust when evidence changes. As a next step, choose one current initiative and apply the model to it. Clarify the objective, stakeholders, options, risks, expected value, and review date. For example, if you are considering adopting a new project management tool, start by creating urgency with data on current inefficiencies, form a small coalition, and define a vision. Track metrics like adoption rate and user satisfaction, and review monthly. Compare your approach with related frameworks like ADKAR (for individual change), change management best practices, and stakeholder mapping. These can fill gaps and strengthen your change effort. Revisit the decision at the next planning cycle to confirm it still holds given new evidence, changed priorities, or shifting constraints. A good management framework should make the path clearer and the outcome more predictable. Apply Kotter's model with rigor and adaptability, and you will improve your organization's ability to navigate technology and organizational change successfully.