Leading Through Change

Why Change Fails — The Baseline

McKinsey (2015) data: 70% of organizational transformations fail to achieve their goals. The number has been remarkably stable for 20 years. Harvard Business Review research consistently finds the same root causes: insufficient urgency, weak coalition, poor communication, not removing obstacles, declaring victory too early.

For engineering leaders specifically, the failure modes cluster around:

• Technology-first thinking: “We will migrate to microservices” without addressing the organizational, skill, and cultural changes required
• Underestimating inertia: The existing system works (mostly). People know how to operate it. Changing means becoming incompetent again temporarily.
• Change fatigue: Especially in large orgs, people are already living through 3-5 concurrent change initiatives. Your change is competing for finite adaptation energy.
• The frozen middle: Senior leadership sponsors the change. ICs are often willing. Middle management — who must change their daily operations and manage the disruption — frequently stalls it.

---

Kotter’s 8-Step Model (1996)

The most widely cited change framework. Kotter designed it based on studying over 100 organizational transformations. The sequence matters — skipping steps or doing them out of order is a primary cause of failure.

The Eight Steps

Step	Action	Engineering Example	Common Failure
1. Create Urgency	Help people see why change is necessary NOW, not later	“Our deployment frequency is 10x slower than competitors. We are losing engineers to companies with better DX.”	Presenting data without emotional resonance. People change because they feel urgency, not because they see a chart.
2. Build a Guiding Coalition	Assemble a group with enough power and credibility to lead the change	EM + Staff Engineer + Product Lead + one influential senior IC + sympathetic VP	Building a coalition of people who agree with you instead of people who have influence
3. Form a Strategic Vision	Create a clear, compelling vision of the future state	“Every developer deploys to production within 30 minutes of merge, with full confidence in automated testing and rollback”	Vision that is too abstract (“world-class engineering”) or too tactical (“adopt Kubernetes”)
4. Communicate the Vision	Share the vision repeatedly through multiple channels	All-hands, team meetings, 1:1s, Slack posts, architecture reviews — same vision, different framing	Communicating once in a slide deck and assuming people got it. Kotter says 10x more than you think is necessary.
5. Empower Action	Remove obstacles that prevent people from acting on the vision	Allocate 20% time for migration work. Change incentives to reward adoption. Remove the approval gates that slow things down.	Saying “you are empowered” without actually removing structural barriers
6. Generate Short-Term Wins	Plan for and create visible, unambiguous improvements early	Migrate one service end-to-end within 4 weeks. Show the deploy time drop from 4 hours to 30 minutes.	Pursuing the big bang migration with no visible progress for 6 months
7. Consolidate and Build	Use credibility from wins to change systems, structures, and policies that do not fit the vision	After proving CI/CD on 3 services, mandate it for all new services. Update the hiring criteria to include cloud-native skills.	Declaring victory after the pilot and assuming the rest will follow
8. Anchor in Culture	Connect the change to organizational values and norms. Make it “how we do things here.”	New onboarding includes the new practices. Promotion criteria reflect new skills. Stories of success become organizational lore.	Moving on to the next initiative before the current change is embedded

Why Kotter’s Model Is Both Right and Insufficient

Kotter’s strength is the sequencing and the emphasis on urgency and coalition. His weakness is that the model is linear and top-down — it assumes change is driven by leadership and adopted by the organization. In engineering organizations, where ICs have significant informal power and change often needs to be bottom-up (tool adoption, practice changes, cultural shifts), a purely Kotter approach can feel tone-deaf.

The integration: Use Kotter for the organizational/structural aspects of change (steps 1-2, 5-8) and combine with ADKAR (below) for the individual human experience of change.

---

ADKAR Model (Prosci)

While Kotter addresses organizational change, ADKAR (developed by Jeff Hiatt at Prosci) addresses the individual human experience. Each person must move through five stages:

The Five Stages

Stage	Question the Person Is Asking	Leader’s Job	Engineering Example
Awareness	“Why do we need to change?”	Explain the business and personal case for change	“Our current monolith means a single bug can take down the entire platform. Here is the incident data.”
Desire	“What is in it for me? Do I want this?”	Connect change to personal motivation	“You will own your service end-to-end. No more waiting 3 weeks for the ops team to deploy your code.”
Knowledge	“How do I change? What do I need to learn?”	Provide training, mentoring, resources	“Here is a 2-week pairing program with the platform team. Here is the learning path.”
Ability	“Can I actually do this? Do I have the skills and support?”	Create practice opportunities, remove performance pressure during learning	“Your first 3 deployments will be paired. We are not measuring velocity during the transition.”
Reinforcement	“Will this stick? Will I be rewarded for the new way?”	Recognize and reward new behaviors, address backsliding	“Your team’s 99.9% uptime since the migration is exactly the kind of ownership we want to see. I highlighted this to [VP].”

Where People Get Stuck

Stuck at Awareness: They do not see the problem. This is surprisingly common with experienced engineers who are comfortable with the current system. They have optimized their workflow around existing constraints and genuinely do not see the cost.

Stuck at Desire: They understand the problem but do not want to change. Common reasons: fear of looking incompetent during the transition, loss of expert status (the “monolith expert” becomes a beginner), belief that the change will be reversed (they have seen it before), or legitimate disagreement that this is the right change.

Stuck at Knowledge/Ability: They want to change but do not know how or cannot yet perform. This is the easiest gap to close — it is a training and support problem. But many organizations skip straight from Desire to expected performance, which sets people up to fail.

Stuck at Reinforcement: The change happened, but the old incentives, processes, and cultural norms pull people back. The most common reason changes do not stick.

ADKAR Diagnostic

When someone is resisting change, diagnose which stage they are stuck at. The intervention is completely different for each:

• Stuck at Awareness? More communication about why.
• Stuck at Desire? Address their personal concerns and motivations.
• Stuck at Knowledge? Training and resources.
• Stuck at Ability? Practice, coaching, reduced pressure.
• Stuck at Reinforcement? Recognition, revised incentives, structural changes.

The mistake: Applying the wrong intervention. Most leaders default to “more communication” (Awareness), but the person might be stuck at Desire (they understand but do not want to) or Ability (they want to but cannot). Explaining the why louder does not help someone who cannot do the how.

---

Managing Resistance — Understanding Before Overcoming

Why People Resist (And Why They Are Often Right)

Resistance is not a character flaw. It is information. Before trying to overcome resistance, understand it:

Resistance Type	What They Are Saying	What to Do
Rational resistance	“This will not work because [specific technical/business reason]”	Listen carefully. They might be right. Incorporate valid concerns.
Political resistance	“This threatens my team’s scope/budget/relevance”	Address the political concern directly. Find a way to make the change a win for them too.
Emotional resistance	“I am afraid of looking incompetent / losing my identity / being left behind”	Empathize. Provide safety. Show that learning is expected and supported.
Fatigue resistance	“We just went through a reorg / migration / process change. Not another one.”	Acknowledge the fatigue honestly. Sequence changes with recovery time.
Historical resistance	“We tried this 3 years ago and it failed. What is different this time?”	Acknowledge the history. Explain concretely what is different. If nothing is different, reconsider.

The Adoption Curve in Engineering Teams

Rogers’ Diffusion of Innovations (1962) maps neatly to engineering teams:

Segment	% of Team	Behavior	Your Approach
Innovators	~5%	Already experimenting with the new approach on side projects	Give them early access. Let them be pioneers.
Early Adopters	~15%	Interested and willing, need some support	Invest heavily here. They become your proof points and internal advocates.
Early Majority	~35%	Pragmatic. Will adopt when they see it working for others.	Show them the early adopters’ success. Provide clear migration paths and support.
Late Majority	~35%	Skeptical. Will adopt when it becomes the default.	Make the new way the path of least resistance. Change defaults, tooling, templates.
Laggards	~10%	Will resist until the old way is no longer possible.	Set a hard deadline for the old way. Be empathetic but firm. Do not let them hold the org back.

The chasm: The gap between Early Adopters and Early Majority is where most engineering changes die. Early adopters love the new thing because it is new. The early majority will not adopt until it is proven, documented, and easier than the old way. Crossing this chasm requires investment in documentation, tooling, defaults, and visible success stories.

---

Leading During Uncertainty

Not all change is planned. Sometimes you are leading through ambiguity — reorgs, layoffs, market shifts, strategic pivots — where you do not have answers yourself.

The Transparency-Certainty Tradeoff

During uncertainty, leaders face a dilemma:

• Say too little: People fill the void with worst-case assumptions. Rumors spread. Trust erodes.
• Say too much: You commit to things that might change. When they change, you lose credibility.

The principle: Share what you know, acknowledge what you do not know, commit to sharing more when you can.

Template: “Here is what I know: [facts]. Here is what I do not know: [specific uncertainties]. Here is when I expect to know more: [timeline]. Here is what will NOT change: [anchor points].”

The last element — what will NOT change — is underrated. During uncertainty, people need anchors. “Regardless of the reorg outcome, our team’s mission remains the same. Your roles are not at risk. Our Q3 commitments stand.”

What Your Team Needs During Uncertainty

Need	How to Provide It
Information	Share what you can, as soon as you can. Even partial information is better than silence.
Normalcy	Maintain routines. Keep 1:1s, standups, retros. Routines provide stability.
Agency	Give people things they CAN control. “I cannot tell you about the reorg, but I can tell you that your growth plan is in your hands. Let us work on it.”
Permission to feel	“It is normal to feel anxious about this. I do too.” Do not pretend everything is fine.
Honesty about what you do not know	“I do not know” is trustworthy. Making up reassurances is not.

The Leader’s Own Uncertainty

You are also uncertain. You are also anxious. You might be personally affected by the change. The temptation is to either hide your uncertainty (appearing invulnerable) or share everything (dumping your anxiety on the team).

The middle path: be honest about your feelings while demonstrating that you can function effectively despite them. “I am also uncertain about the outcome. Here is how I am thinking about it, and here is what I am doing in the meantime.” This models emotional regulation — the ability to feel difficult emotions and still lead effectively.

---

Organizational Transformation — The Multi-Year Lens

Major engineering transformations (monolith to microservices, on-prem to cloud, waterfall to agile, building an AI platform) take 2-4 years, not 2-4 months. Most failure comes from underestimating the timeline and over-promising the speed.

Transformation Phases

Phase	Duration	Focus	Leader’s Role
Unfreezing	3-6 months	Building urgency, coalition, vision. Making the case for change.	Evangelist, coalition-builder
Transitioning	12-24 months	Executing the change. Running old and new systems in parallel. Continuous learning.	Coach, obstacle-remover, patience-holder
Refreezing	6-12 months	Embedding the change in culture, processes, and incentives. Making it the new normal.	Systems-thinker, culture-shaper

The J-Curve of Performance

During any significant change, performance dips before it improves. This is inevitable — people are learning new skills, new tools, new processes. The team is temporarily less productive.

Performance
    |
    |  ....                          .............. (new normal)
    | .    .                    ....
    |.      .              ....
    |        .          ...
    |         .       ..
    |          .    ..
    |           ....        <- The Valley
    |_________________________________ Time
    ^                ^              ^
    Change           Valley        New Normal
    begins           (3-6 mo)      (12-18 mo)

The critical leadership moment: At the bottom of the J-curve, pressure to revert is highest. Stakeholders see declining metrics and push to go back. This is where your coalition, your short-term wins, and your conviction are tested.

How to navigate the valley:

• Set expectations upfront. “Performance will dip. Here is why, and here is how long I expect it to last.”
• Track leading indicators (adoption rate, learning milestones) alongside lagging indicators (velocity, uptime). Leading indicators should be improving even while lagging indicators dip.
• Celebrate learning milestones. “The team deployed their first microservice. It took twice as long as expected. That is exactly where we should be at this stage.”
• Have the courage to stay the course while remaining open to evidence that the change is genuinely wrong (not just painful).

---

Anti-Patterns

Anti-Pattern	Description	Consequence
Big Bang transformation	Change everything at once. No sequencing, no pilot.	Overwhelm, chaos, rapid revert.
Change by decree	“Starting Monday, we use X.” No urgency-building, no coalition, no training.	Compliance without commitment. Passive resistance.
Vision without empathy	Articulating the future state without acknowledging the loss of the current state	People feel unheard. Resistance increases.
Premature victory	“We migrated 3 services! The transformation is complete!” (47 services remain)	Momentum dies. Coalition disbands. The remaining 90% never happens.
Change fatigue stacking	Launching a new change initiative every quarter without finishing the previous one	Nothing gets embedded. People learn to wait it out.
The burning platform	Creating artificial urgency through fear (“change or die”)	Short-term compliance, long-term cynicism. Works once; never again.
Ignoring the frozen middle	Focusing on IC adoption while middle managers are not equipped or motivated to support the change	Managers become blockers. ICs get caught between leadership vision and management inertia.
Confusing change with improvement	Assuming that any change is progress	Some changes are lateral moves. Validate that the change actually improves outcomes.

---

References

• Kotter, J.P. (1996). Leading Change. Harvard Business School Press. — The 8-step model. Essential reading.
• Kotter, J.P. (2012). “Accelerate!” Harvard Business Review. — Updated thinking on dual operating systems for change.
• Hiatt, J. (2006). ADKAR: A Model for Change in Business, Government, and Our Community. Prosci. — The individual change model.
• Bridges, W. (2009). Managing Transitions. 3rd ed. Da Capo Press. — The psychological process of transition (endings, neutral zone, new beginnings). Complements Kotter.
• Lewin, K. (1947). “Frontiers in Group Dynamics.” Human Relations. — Unfreeze-Change-Refreeze. The original change model.
• Rogers, E.M. (1962). Diffusion of Innovations. Free Press. — Adoption curve and the chasm concept.
• Moore, G.A. (1991). Crossing the Chasm. HarperBusiness. — How to move from early adopters to mainstream adoption.
• Heifetz, R. & Linsky, M. (2002). Leadership on the Line. Harvard Business School Press. — Adaptive leadership; distinguishing technical from adaptive challenges.
• Satir, V. (1991). The Satir Model. Science and Behavior Books. — The Satir change model (status quo, foreign element, chaos, integration, new status quo).
• Heath, C. & Heath, D. (2010). Switch: How to Change Things When Change Is Hard. Crown Business. — Direct the rider (rational), motivate the elephant (emotional), shape the path (environmental).