Change Leadership and Transformation

Why This Matters at the Director/VP Level

Every engineering leader eventually faces a moment where they need to change something fundamental about how their organization works. Maybe it's re-platforming from a monolith to microservices. Maybe it's shifting from waterfall to agile, or from agile to something else. Maybe it's restructuring the entire engineering organization around different team topologies. Maybe it's adopting a new technology stack, a new deployment model, or a new way of working with product.

These large-scale transformations are where directors and VPs earn their keep — or fail spectacularly.

Here's the uncomfortable truth: most large-scale transformations fail. Industry data consistently shows that 60-70% of organizational change initiatives don't achieve their stated goals. Not because the technical direction was wrong, but because the human side of change was mismanaged.

Your job as a leader isn't just to decide the right direction. It's to actually get hundreds of people to change how they work, what they believe, and what they do every day. That's a fundamentally different skill than choosing the right architecture or the right methodology.

This section covers how to lead large-scale change well — the frameworks, the psychology, the tactics, and the hard-won lessons from leaders who've done it (and from those who tried and failed).

Types of Large-Scale Transformation

Technical Re-Platforming

Moving from one technical architecture to another. Examples: monolith to microservices, on-premise to cloud, REST to event-driven, single database to distributed data.

These are deceptively hard because they feel like technical problems but are actually organizational problems. The technology isn't the hard part. Getting 200 engineers to learn new patterns, adopt new tools, and change their mental models — while continuing to ship features and keep the business running — that's the hard part.

Methodology Changes

Shifting how teams plan, build, and deliver software. Examples: waterfall to agile, Scrum to Kanban, project-based to product-based, feature teams to platform + stream-aligned teams.

These are hard because they challenge deeply held beliefs about how work should be done. People have built their careers and identities around certain ways of working. Telling them to change isn't just a process update — it feels like a personal critique.

Organizational Restructures

Changing how teams are organized, who reports to whom, and how work flows through the organization. This includes reorgs, creating new functions (like platform engineering or SRE), merging teams, splitting teams, or shifting from functional to cross-functional structures.

These are hard because they're personal. People's managers change. Their teammates change. Their scope changes. Their career trajectory might change. And all of this happens while they're expected to keep doing their jobs.

Kotter's 8 Steps for Leading Change

John Kotter's framework is the most widely referenced model for leading organizational change, and for good reason — it works. Here's how to apply it in an engineering context.

Step 1: Create a Sense of Urgency

People don't change when things are comfortable. You need to create a compelling case for why the status quo is unacceptable.

In engineering, this often means making the pain visible. Show the data:

"Our deployment frequency has dropped 60% in the last year because of our monolith."
"We spent 40% of engineering time last quarter on unplanned work caused by our aging infrastructure."
"Three of our last five outages were caused by the same architectural limitation."
"We've lost four senior engineers in the last 6 months, and in exit interviews, they all cited our outdated tech stack."

The urgency has to be real, not manufactured. People can smell fake urgency, and it destroys trust. If you can't make a genuine, data-backed case for change, maybe you shouldn't be making the change.

Step 2: Build a Guiding Coalition

You can't drive change alone. You need a coalition of influential people who are aligned on the direction and committed to making it happen.

In an engineering org, your guiding coalition should include:

Your direct reports (engineering managers, senior directors)
Technical leaders (staff engineers, architects) — these people have enormous informal influence
Cross-functional partners (product, design, QA leaders) — change that only involves engineering rarely stays contained
Early adopters — engineers who are excited about the change and will be the first to try it

The coalition needs to represent different perspectives and different parts of the organization. If your guiding coalition is just your leadership team in a room agreeing with each other, you're missing the people who will make or break adoption on the ground.

Step 3: Form a Strategic Vision and Initiatives

Your vision needs to answer three questions:

Where are we going? (The end state)
Why are we going there? (The business reason)
How will we get there? (The high-level plan)

The vision should be simple enough to explain in two minutes. If you can't, it's too complicated. "We're moving to a microservices architecture so that teams can deploy independently, reducing our time-to-market from weeks to hours" is a good vision. A 40-page architectural document is not a vision — it's a plan. You need both, but don't confuse them.

Step 4: Enlist a Volunteer Army

Beyond your guiding coalition, you need a broader group of people who are actively driving the change. These are the people in each team who champion the new way, help their teammates adopt it, and provide feedback on what's working and what's not.

You can't force this. People volunteer when they believe in the vision and see personal value in the change. Your job is to make the change attractive: provide learning opportunities, recognize early adopters, make sure the new way is genuinely better than the old way.

Step 5: Enable Action by Removing Barriers

People who want to change will hit obstacles. Your job is to identify and remove those obstacles before they become excuses.

Common barriers in engineering transformations:

Skill gaps. People don't know how to work in the new way. Invest in training, pairing, and mentoring.
Tooling gaps. The tools don't support the new way of working. Prioritize tooling investment.
Process conflicts. Old processes contradict the new direction. Update them.
Incentive misalignment. People are still being measured and rewarded on old metrics. Change the metrics.
Middle management resistance. Some managers feel threatened by the change. Address their concerns directly.

Step 6: Generate Short-Term Wins

Large transformations take months or years. If people don't see tangible progress along the way, they lose faith. Plan for visible, meaningful wins within the first 60-90 days.

Examples of short-term wins:

One team successfully deploys using the new pipeline
A pilot service in the new architecture handles its first production traffic
Deployment frequency for the pilot team increases measurably
An engineer who was skeptical becomes an advocate after experiencing the improvement firsthand

Celebrate these wins publicly. They build momentum and provide proof that the change is real and beneficial.

Step 7: Sustain Acceleration

After the initial wins, there's a temptation to declare victory and move on. This is where most transformations die. The first 20% is exciting. The next 60% is a grind.

To sustain acceleration:

Keep the guiding coalition engaged and visible
Continue removing barriers as new ones emerge
Expand the change to more teams, building on the lessons from early adopters
Maintain urgency — remind people why you're doing this
Be transparent about what's working and what's not

Step 8: Institute Change

The transformation is complete when the new way is "just how we do things." It's no longer a change initiative — it's the default.

This requires:

Updating documentation, processes, and training materials
Embedding the new way into hiring and onboarding
Removing the old way entirely (if possible) so there's no path back
Recognizing and promoting people who exemplify the new way

The ADKAR Model

While Kotter's model is about organizational change, the ADKAR model (from Prosci) focuses on individual change. Both are useful, and they complement each other well.

ADKAR stands for:

Awareness

The individual understands why the change is happening. Without awareness, people resist because they don't see the problem.

How to build awareness: Communicate the reasons for change repeatedly, through multiple channels. Town halls, team meetings, written communications, one-on-ones. People need to hear the message 7-10 times before it sinks in. That's not an exaggeration — it's research-backed.

Desire

The individual wants to participate in the change. Awareness alone isn't enough — people can understand why change is needed and still not want to do it.

How to build desire: Connect the change to things people care about. "This will make your daily work less frustrating." "This will help you grow skills that are in high demand." "This will reduce the 3 AM pages." Address the "what's in it for me?" question honestly.

Knowledge

The individual knows how to change. They have the skills and information needed to work in the new way.

How to build knowledge: Training, documentation, pairing with experienced practitioners, workshops, lunch-and-learns. Don't assume people can figure it out on their own. Invest in structured learning.

Ability

The individual can actually implement the change in their daily work. Knowledge and ability are different — I might know how to play piano in theory, but I can't actually play.

How to build ability: Practice, coaching, safe environments to make mistakes, gradual ramp-up. Don't expect people to be fully proficient on day one. Build in time for the learning curve.

Reinforcement

The change sticks. Without reinforcement, people revert to old behaviors, especially under pressure.

How to reinforce: Celebrate successes, measure adoption, address backsliding directly, make the old way harder than the new way, align incentives with the new behavior.

Using ADKAR Diagnostically

ADKAR is particularly useful for diagnosing why a change isn't sticking. If someone isn't adopting the new way, figure out where they are in the ADKAR progression:

If they lack Awareness, more communication is needed.
If they lack Desire, you need to understand their concerns and address them.
If they lack Knowledge, they need training.
If they lack Ability, they need practice and support.
If they lack Reinforcement, you need to adjust incentives and accountability.

The mistake is treating all resistance the same way. Sending someone to training when their real issue is Desire (they don't want to change) is a waste of time and can feel insulting.

Leading Through Uncertainty

Large transformations come with genuine uncertainty. You don't know exactly how long it will take, exactly what problems will emerge, or exactly what the end state will look like. And yet people look to you for clarity and confidence.

Being Honest About What You Don't Know

The worst thing you can do is pretend you have all the answers. People see through it, and when reality proves you wrong, your credibility is damaged.

Instead, be explicit about what you know and what you don't:

"I'm confident that microservices is the right architectural direction. I'm less sure about the exact migration sequence — we'll learn as we go and adjust."
"We know we need to restructure the org, and here's the target state. The exact timeline will depend on how the first phase goes."

This isn't weakness — it's honesty. And it gives people permission to raise concerns and flag issues early, which is exactly what you need.

Making Decisions with Incomplete Information

You will never have enough information to be certain. Waiting for certainty is a form of failure. Use the 70% rule: if you have 70% of the information you wish you had, make the decision. At 90%, you've probably waited too long.

Make reversible decisions quickly. Make irreversible decisions carefully. But make decisions.

Managing Your Own Anxiety

Leading through transformation is stressful. You're putting your reputation on the line. If it fails, it's your failure. If it succeeds, everyone will say it was inevitable.

Find your support system — peers, mentors, executive coaches, your own manager. Process your anxiety somewhere other than with the people you're leading. They need to see confidence (honest confidence, not false confidence) from you.

Adoption Tracking

You can't manage what you don't measure. But measuring adoption of a large-scale change requires thinking carefully about what to track.

Leading Indicators

These tell you whether adoption is happening:

Number of teams that have started the migration/adoption
Percentage of new services built using the new approach
Training completion rates
Tool adoption metrics (how many people are using the new tools)
Number of active champions per team

Lagging Indicators

These tell you whether the change is delivering the expected benefits:

Deployment frequency (did it improve as promised?)
Incident rates (did reliability improve?)
Time to market for new features
Developer satisfaction scores
Cost metrics (did costs decrease as expected?)

The Adoption Curve

Not everyone adopts at the same pace, and that's normal. Expect:

Innovators (5-10%): Jump in immediately. These are your champions.
Early adopters (15-20%): Adopt quickly once they see it working for the innovators.
Early majority (30-35%): Adopt when they see broad evidence of success.
Late majority (25-30%): Adopt when the old way becomes harder than the new way.
Resisters (5-15%): May never fully adopt voluntarily.

Your strategy should be different for each group. Don't waste energy trying to convince the resisters first — start with the innovators and early adopters, build momentum, and let social proof do the heavy lifting for the majority.

Change Fatigue

This is a real and underappreciated risk. When you're running a major transformation, your people are already at their limit. If you pile on additional changes, you'll get pushback — not because the changes are wrong, but because people are exhausted.

Signs of Change Fatigue

Cynicism about new initiatives ("oh, another transformation")
Passive resistance (people agree in meetings but don't change behavior)
Decreased engagement scores
Increased turnover, especially among high performers
Nostalgia for "the way things used to be"

Managing Change Fatigue

Limit concurrent changes. Don't run three transformations simultaneously. Sequence them. Finish one before starting the next, or at least stagger them so the peak intensity doesn't overlap.

Protect stability zones. Identify the things that won't change and communicate them explicitly. "We're changing our architecture, but we're not changing our team structure, our sprint cadence, or our product priorities." People can handle change when they have stable ground to stand on.

Acknowledge the burden. Don't pretend that change is easy or fun. "I know this is a lot. I know it's hard. And I know I'm asking you to learn new things while still delivering on your commitments. Thank you for pushing through this." Acknowledgment goes a long way.

Create recovery time. After a major change milestone, give people a breather. A period of stability where nothing new is introduced and teams can consolidate what they've learned.

Communicating the "Why" at Scale

Communication is the single most underinvested area in most transformations. Leaders think they've communicated the vision because they said it once in an all-hands meeting. They haven't.

The Communication Multiplier

You need to communicate the "why" at least 7-10 times more than you think is necessary. By the time you're sick of repeating yourself, your message is just starting to land with the broader organization.

Use multiple channels:

All-hands presentations
Written documents and FAQs
Team-level discussions (your managers cascading the message)
One-on-ones for people with specific concerns
Slack channels for ongoing questions and updates
Regular progress updates (weekly or biweekly)
Demo sessions showing the new way in action

Framing the Message

Different audiences need different framings of the same change:

For engineers: Focus on how it improves their daily work. Less manual toil, better tools, more interesting problems, fewer 3 AM pages.

For engineering managers: Focus on how it helps their teams deliver better results. Faster shipping, happier engineers, fewer fires.

For product partners: Focus on how it improves time-to-market and feature velocity. "After this migration, your teams will be able to ship independently without coordinating with other teams."

For executives: Focus on business outcomes. Cost savings, faster time-to-market, improved reliability, reduced risk, competitive advantage.

Handling Questions You Can't Answer

During large-scale changes, people will ask questions you can't answer yet. "What happens to my team?" "Will I still be working on the same product?" "Is my role going away?"

Don't make promises you can't keep. Don't speculate. Instead:

Acknowledge the question and the anxiety behind it
Share what you do know
Give a timeline for when you'll have more information
Follow up when you said you would

The worst thing is silence. When leaders go quiet during uncertain times, people fill the vacuum with worst-case assumptions.

Building Coalitions

Change doesn't happen through hierarchy alone. You need coalitions of people across the organization who are aligned on the direction and actively working to make it happen.

Identifying Key Influencers

Every organization has informal influence networks that don't match the org chart. The staff engineer who everyone respects might have more influence than a director. The engineer who's been at the company for 10 years and knows every system might carry more weight than a new VP.

Identify these influencers and bring them into your coalition early. If they support the change, adoption accelerates dramatically. If they oppose it, adoption stalls regardless of what leadership says.

Winning Over Skeptics

Not all skeptics are resisters. Many skeptics are thoughtful people who see risks that you've missed. Treat skepticism as a gift:

Listen genuinely. Don't just hear their objections — understand the reasoning behind them.
Acknowledge valid concerns. "You're right that the migration will be disruptive. Here's how we're planning to manage that."
Involve them in the solution. "I'd like you to help us design the migration plan so that we address the risks you've identified."
Give them a role. Skeptics who become involved in shaping the change often become its strongest advocates.

The Coalition Across Functions

Engineering transformations affect everyone: product, design, QA, operations, customer success. Build your coalition across functions, not just within engineering.

If product managers don't understand why deployment velocity will temporarily decrease during a migration, they'll push back hard. If QA isn't involved in the shift to automated testing, they'll feel sidelined. If operations isn't part of the SRE transformation, they'll resist it.

Include cross-functional partners from the beginning. Let them shape the approach. Make them co-owners of the outcome.

Real-World Examples

Successful Transformation: The Monolith Migration

A 600-person engineering organization had a monolithic application that was 12 years old and over 2 million lines of code. Deployments took 4 hours and happened twice a week. Every deployment was a company-wide event. Feature development had slowed to a crawl because every change risked breaking something else.

The new VP of Engineering decided to migrate to microservices. Here's what she did right:

Created urgency with data. She showed that deployment frequency had decreased 5x over 3 years, that the number of deployment-related incidents had tripled, and that the company was losing deals because competitors could ship features faster.

Built a coalition. She recruited three senior staff engineers (all widely respected skeptics) to help design the migration strategy. She brought product leadership into the conversation early and got their commitment to allocate 20% of capacity to migration work.

Started small. Instead of a big-bang rewrite, she picked one bounded context (user notifications) and extracted it into the first microservice. This was low-risk, well-understood, and would provide a visible proof point.

Generated short-term wins. The notification service was deployed independently within 6 weeks. The team that owned it went from deploying twice a week (as part of the monolith) to deploying 5 times a day. They talked about it constantly. Other teams wanted that experience.

Built the platform. She invested in a platform team that built the tools and templates to make extracting services straightforward. Each subsequent extraction was easier than the last.

Tracked adoption. She measured the percentage of traffic flowing through microservices vs. the monolith. She shared this metric weekly. It became a source of pride as the number grew.

Managed the grind. The migration took 2.5 years. There were months where progress felt slow, where the dual-system complexity made things harder, not easier. She acknowledged the difficulty, celebrated incremental progress, and kept the vision visible.

The result: after 2.5 years, 85% of traffic flowed through microservices. Deployment frequency across the org increased 8x. Incident rates decreased by 40%. Engineer satisfaction scores increased significantly. And the three skeptics she'd recruited to her coalition became the strongest advocates for the new architecture.

Failed Transformation: The Agile Mandate

A different company — large enterprise, 1,200 engineers — decided to "go agile." The CTO attended a conference, got inspired, and announced that all teams would adopt Scrum within 6 months.

Here's what went wrong:

No genuine urgency. The company was profitable and growing. Engineers didn't feel pain with the current process. The CTO's urgency was real to him (he could see the competitive threat) but he never effectively communicated it to the broader organization.

Top-down mandate. Instead of building a coalition, the CTO hired a consulting firm to implement Scrum across all teams simultaneously. Engineers and managers weren't involved in the design. They were told "this is how we work now."

Cookie-cutter approach. Every team got the same Scrum template regardless of their context. Teams building real-time systems were forced into 2-week sprints. Teams doing research were forced to estimate in story points. Teams that had working processes were told to abandon them.

No skill building. The consulting firm ran 2-day training sessions and then left. Managers were expected to become Scrum Masters overnight. Engineers were expected to estimate in a format they'd never used. Nobody invested in ongoing coaching.

No short-term wins. Because the implementation was cookie-cutter, early results were mixed. Some teams improved. Many got worse. The teams that got worse became vocal about the failure, and their stories spread faster than the success stories.

Declared victory too early. After 6 months, the CTO declared the agile transformation complete. In reality, most teams were doing "agile theater" — they had standups and sprints but hadn't changed how they actually worked. Within a year, most teams had quietly reverted to their old processes with a thin agile veneer on top.

The lesson: you can mandate process changes, but you can't mandate behavioral changes. Without genuine urgency, coalition building, skill development, and sustained attention, the change won't stick.

Common Mistakes

1. Underestimating the Timeline

Large-scale transformations take 2-5 years, not 6 months. If you think you can re-platform a 10-year-old monolith in a quarter, you're going to have a bad time. Set realistic expectations and plan for a multi-year journey.

2. Neglecting the "Frozen Middle"

Senior leadership supports the change. Engineers on the ground are often excited about it. The people who most often resist are middle managers — the "frozen middle." They have the most to lose (their expertise is in the old way) and the most influence over daily team behavior. Win them over or work around them, but don't ignore them.

3. Trying to Change Everything at Once

Pick one transformation at a time. If you're re-platforming your architecture, don't simultaneously restructure the org and change your development methodology. Each change compounds the disruption and increases the risk of failure.

4. Not Investing in Communication

You need to communicate 10x more than you think. And communication isn't a one-time event — it's an ongoing campaign. Budget time and energy for it. Assign someone to own the communication plan.

5. Ignoring the Emotional Side

Change is emotional. People are scared, frustrated, and grieving the loss of familiar ways of working. Acknowledging these emotions isn't soft — it's strategic. Emotions that aren't addressed become resistance.

6. Measuring Activity Instead of Outcomes

"We trained 500 engineers on the new methodology" is activity. "Deployment frequency increased 3x" is an outcome. Focus on outcomes. Activity without outcomes is expensive theater.

7. Not Planning for Reversals

Sometimes a transformation doesn't work. Maybe the approach was wrong. Maybe the timing was wrong. Maybe the market shifted. Having the courage to stop or reverse a failing transformation is as important as having the courage to start one. The sunk cost fallacy has killed more transformations than it's saved.

8. Burning Out Your Best People

Your early adopters and champions carry a disproportionate share of the transformation burden. They're learning the new way, helping others, providing feedback, and still doing their regular jobs. Monitor their workload and well-being. If they burn out, your transformation loses its most critical asset.

9. Forgetting to Decommission the Old Way

If the old way is still available, people will keep using it. After a reasonable transition period, actively decommission the old systems, processes, and tools. As long as there's a comfortable fallback, adoption will plateau.

Business Value

Leading transformations well is one of the most valuable things a director or VP can do. Here's the concrete impact:

Competitive advantage. Organizations that can transform successfully are more adaptable. They can respond to market changes, adopt new technologies, and evolve their practices while competitors are stuck with legacy approaches.
Engineering productivity. Successful platform migrations typically yield 2-4x improvements in deployment frequency and 30-50% reductions in lead time for changes. For a 200-person engineering org, that's the equivalent of adding 60-100 engineers in effective capacity.
Talent attraction and retention. Engineers want to work in modern environments with current technologies and effective practices. A successful transformation makes your organization more attractive to top talent and reduces attrition among your existing team.
Risk reduction. Legacy systems carry increasing risk over time: security vulnerabilities, compliance gaps, dependency on scarce expertise. Transformation reduces these risks before they become crises.
Cost optimization. Many transformations (cloud migration, platform consolidation, automation) directly reduce costs. Even those that don't reduce direct costs often dramatically reduce the hidden costs of slow delivery and frequent incidents.
Organizational capability. Perhaps most importantly, an organization that has successfully navigated one transformation is better equipped to navigate the next one. Change leadership becomes a muscle — the more you exercise it, the stronger it gets.

The ROI on successful transformations is enormous but often difficult to quantify precisely. The ROI on failed transformations is also clear: millions in wasted investment, months of lost productivity, damaged morale, and increased attrition. Getting change leadership right is not optional — it's essential.

Common Pitfalls

Underestimating the timeline. Large-scale transformations take 2-5 years, not 6 months. Setting unrealistic timelines leads to declared "victory" while teams are still doing theater instead of actual change.
Neglecting the frozen middle. Senior leadership supports the change and ground-level engineers are excited, but middle managers -- who have the most to lose and the most daily influence -- resist quietly. Failing to win them over stalls adoption.
Trying to change everything at once. Running simultaneous re-platforming, reorg, and methodology changes compounds disruption and increases the risk of all three failing.
Under-investing in communication. Saying the vision once in an all-hands and assuming the message landed means most of the organization never truly understands why the change is happening. You need 7-10x more communication than feels necessary.
Ignoring the emotional dimension of change. Treating resistance as purely logical and responding only with data and training misses the fear, grief, and identity challenges that drive most adoption failures.
Burning out early adopters and champions. Your most enthusiastic change agents carry a disproportionate burden -- learning, teaching, providing feedback, and still doing their regular jobs. If they burn out, the transformation loses its most critical asset.

Key Takeaways

Most transformations fail because of the human side, not the technical side. Invest accordingly.
Use Kotter's 8 steps as your macro framework and ADKAR for diagnosing individual adoption challenges.
Create genuine urgency with data, not manufactured panic.
Build a broad coalition that includes technical leaders, cross-functional partners, and respected skeptics.
Generate short-term wins within 60-90 days to build momentum.
Communicate the "why" 10x more than you think is necessary, through multiple channels.
Track adoption with both leading and lagging indicators.
Manage change fatigue by limiting concurrent changes and creating recovery periods.
Plan for a multi-year journey, not a quick fix.
Have the courage to adjust course — or stop entirely — if the transformation isn't working.