Engineering Change Management: Kotter's 8-Step Playbook

I've used Kotter's 8-step change model more times than I can count -- for large platform rewrites, for changing release processes, and even when growing meetups in the Persian tech community. It's not a silver bullet. But it gives a simple, human-centered structure to what otherwise becomes a chaotic "do-it-because-I-said-so" project.

The big picture: Kotter isn't about checkboxes. It's about people. Code and infrastructure are easy compared to changing habits and incentives.

1. Create urgency

Make the pain visible and real.

Early in my career I announced a migration because "it's the right thing to do" and expected everyone to follow. No one did. What worked instead: I collected measurable pain -- weekly production incidents, median deploy time ballooning from 90 to 180 minutes, and cost-per-deploy in downtime. Then I told two stories: a bug that cost a customer, and the real deploy timeline. Numbers plus human stories cut through apathy.

Show trends, not opinions. A clear chart beats a speech.

2. Build a guiding coalition

You need a cross-functional team of influencers, not org-chart titles.

For a microservice split I picked the release lead, a senior QA, an infra engineer, and a product manager. They didn't have to be managers -- they had credibility. Give this group authority to make low-level decisions fast so momentum doesn't get stuck in approval workflows.

3. Form a strategic vision

Write a short, crisp statement of where you're going and why.

Bad vision: "Move to microservices." Vague, scary, nobody can picture success.

Better: "Split the payments module into a service so we can deploy payments independently and cut incident blast radius in half within 6 months." Concrete. Measurable. Bounded.

One to two lines. Put it everywhere.

4. Communicate the vision relentlessly

Repeat with different formats. I've used all of these: a 5-minute demo at standup, a 15-minute brown-bag with Q&A, an illustrated one-pager, and a progress dashboard.

People are busy. Make it easy to say "I'll help." Small, well-scoped tasks work best.

5. Remove obstacles

Find and fix the blockers that sap momentum.

Real blockers I've faced: lack of CI minutes, permissive code ownership rules, deployment processes requiring admin approvals. Fixes that helped: a 48-hour automation sprint to add pipeline caching, a temporary change-freeze exception for the migration team, and a documented rollback plan so teams felt safe.

I learned to ask: "What keeps someone from doing a 2-hour task?" Fix that.

6. Generate short-term wins

Deliver tangible, visible wins early.

The first service cut reduced deploy time for a critical path by 70%. We demoed it, celebrated, and used it to recruit engineers from other teams. Wins should be meaningful and fast -- weeks, not quarters. They build trust.

7. Sustain acceleration

After a win, keep going. Redouble resources, remove new blockers, expand scope.

My mistake: I rested on the laurels of a single win and assumed the rest would happen. It didn't. Set the next milestone before the first celebration ends. Keep the dashboard. Keep publicizing progress.

8. Institute change

Make the new way of working the default: hiring, onboarding, docs, KPIs.

We added new code review checklists, updated our hiring rubric to favor ownership, and changed OKRs to include time-to-deploy as a steady metric. Cultural change is slow. Push for a few irreversible changes -- like requiring the new CI in PR validation -- that lock in the new behavior.

My pre-flight checklist before any change

• Do I have hard numbers showing the pain? (If not, measure for 2 weeks.)
• Do I have a tiny coalition of 3-5 committed people?
• Can I write the vision in one sentence: what, why, when?
• Can I break the work into 2-4 week slices with visible outputs?
• What are the top 3 blockers and who can remove them this week?
• How will I sustain this after the initial push?

Honest lessons

• Top-down mandates fail without grassroots energy. Authority doesn't equal adoption.
• Small wins beat big promises. One delivered improvement persuades more than a grand plan.
• Communication is tactical. Charts for execs, demos for devs, docs for maintainers.
• Celebrate but institutionalize. Don't throw a party and go back to old habits -- lock the change into processes and hiring.

If you're starting a change today, pick one small measurable win you can deliver in 2-4 weeks, find two people who'll commit to it beside you, and write the one-sentence vision. I've seen that pattern turn skeptical teams into advocates more reliably than spreadsheets and long project plans.