John Kotter, a Harvard Business School professor, spent decades studying why large-scale organizational transformations fail. His research found that most failures were not due to bad strategy or wrong technology — they were due to skipping foundational steps. He codified his findings into an 8-step process, published in his 1996 book Leading Change.
The most common mistake engineers make when driving change is starting at Step 4 or 5 — jumping straight to "here is the plan, let's execute." Without the first three steps, the plan has no foundation and will collapse under the weight of resistance.
Phase 1: Creating the Climate for Change
Step 1: Create a Sense of Urgency
People do not change when they see the light — they change when they feel the heat. You must prove that staying the same is more dangerous than changing. This is not about fear-mongering; it is about making the cost of inaction visible and concrete.
- Weak: "We should adopt Rust because it has better memory safety."
- Strong: "Our C++ memory leaks caused three production outages last quarter, costing $240k in SLA penalties. At current trajectory, we will breach our enterprise contract threshold in Q3."
The second version creates urgency because it connects the technical problem to a business consequence that leadership cannot ignore.
Step 2: Build a Guiding Coalition
No single person can drive organizational change alone, regardless of their title. You need a coalition of people with three types of power: positional power (managers and directors who can allocate resources), expertise power (respected senior engineers whose technical opinion others trust), and social power (the informal influencers — the people everyone listens to in Slack).
If you only have managers in your coalition, engineers will see the change as top-down mandate. If you only have engineers, you will lack the authority to remove blockers. You need both.
Step 3: Form a Strategic Vision
A vision is not a project plan. It is a compelling picture of a better future that people can emotionally connect to. It must answer: "What will be different, and why is that better for me?"
A good vision is memorable, directional, and motivating. If you cannot explain it in five minutes to a skeptical engineer, it is not clear enough yet.
Phase 2: Engaging and Enabling the Organization
Step 4: Enlist a Volunteer Army
Communicate the vision broadly and repeatedly. Kotter's research found that most transformation efforts under-communicate the vision by a factor of ten. You cannot send one all-hands email and consider it done. The vision must be repeated in team meetings, in code reviews, in one-on-ones, until it becomes part of the team's shared language.
The goal is not compliance — it is genuine buy-in. People who understand why will solve problems you never anticipated. People who are just following orders will stop the moment they hit an obstacle.
Step 5: Enable Action by Removing Barriers
This is where many technically sound initiatives die. You have the vision, you have the buy-in — but engineers cannot actually make progress because they lack permissions, time, tooling, or training. If you want people to migrate services to Terraform but they do not have AWS IAM permissions to create resources, the change will stall regardless of how motivated they are.
Your job at this step is to be a blocker-remover. Actively ask: "What is stopping you from making progress?" and then go fix those things.
Step 6: Generate Short-Term Wins
Do not wait six months for a "Big Bang" release to prove the change is working. Find something small, visible, and annoying that the new approach can fix immediately. Migrate one low-risk service. Automate one painful manual step. Then celebrate it loudly.
Short-term wins serve two purposes: they provide evidence that the change is working (countering skeptics), and they give the team a morale boost during the long slog of a large migration.
Key Point: The first six steps are entirely about building the social and organizational foundation for change. Most engineers want to skip to execution. Skipping these steps is why most transformations fail.