When people say, “We need training,” they’re often expressing something deeper:



  • “I don’t feel confident using this new system.” 
  • “I’m afraid of looking incompetent in front of my peers or my team.” 
  • “No one has really shown me what this change means for my day.” 


If you respond with a single webinar and a PDF, you may tick a box, but you won’t change behavior.

Effective change requires people to understand, care, and feel capable. Coaching and training address the last piece, and, when done well, they support the first two.


This chapter is about designing coaching and training that actually help people adopt change, and about how to think about resistance as a predictable, manageable part of the process.


Training Is Not an Event; It’s a Journey


In multiple roles, I’ve led training and coaching for:

  • Agile and Scrum practices inside manufacturing-centric organizations like GE and Delta Faucet Company.
  • Cloud development and digital services at Schneider Electric. 
  • New governance, portfolio, and OCM frameworks in companies like Lilly and Delta Faucet Company and Start-Ups. 


Across those contexts, a pattern emerged:


One‑off training events create familiarity. Ongoing support builds competence and confidence.


A practical way to think about training is as a journey:


  1. Awareness – People hear that a new tool, process, or methodology is coming. 
  2. Orientation – They get a high‑level overview: what it is, why it’s happening, where it fits. 
  3. Foundation – They receive role‑appropriate training on concepts, tools, and workflows. 
  4. Application – They try it on real work, with guidance and feedback. 
  5. Reinforcement – They receive refresher support, advanced tips, and integration into performance and development plans. 


If you stop at step 3, you leave people at the “I understand it in theory” stage. Adoption lives in steps 4 and 5.


Designing Role‑Based Training


Not everyone needs the same depth of training.


At GE, for example, when we introduced Agile, we had to teach:


  • Senior leaders – how Agile changes planning, reporting, and risk management. 
  • Project managers – how to shift from waterfall to sprint‑based planning and execution. 
  • Developers and testers – how to work in cross‑functional teams, manage backlogs, and run ceremonies. 
  • Business stakeholders – how to participate in reviews, prioritize backlogs, and give feedback. 


If we had given everyone the same generic Agile training, we would have overwhelmed some groups and under‑prepared others.


Instead, we designed:


  • Executive briefings – Focused on principles, governance impact, and how to ask the right questions. 
  • Practitioner workshops – Deeper dives into practices, tools, and day‑to‑day behaviors. 
  • Hands‑on labs and simulations – For teams to experience Agile rituals on realistic scenarios. 


At Schneider Electric, when moving to Azure and DSP, something similar applied:


  • Developers needed how‑to content on creating and managing environments, using Azure services, and following platform patterns. 
  • Product managers needed to understand what’s possible on the platform and how to turn product ideas into digital features. 
  • Business leaders needed to know how cloud impacts time‑to‑market, cost, and risk.


The training we built, videos, demos, workshops, reflected those differences.


For your own change, ask:


  • What roles are in scope (by function and level)? 
  • What decisions or behaviors do we need from each role? 
  • What skills and knowledge do they need to get there? 


Then design content and experiences to match.


Blending Modalities: Live, Self‑Paced, and On‑the‑Job


People learn in different ways and at different paces. Effective training plans use a mix of modalities:


·       Live sessions (in‑person or virtual) 

  • Great for interaction, Q&A, and building energy. 
  • Use for kickoffs, simulations, and deeper dives. 

·       Self‑paced materials

  • Videos, e‑learning, documentation, job aids. 
  • Allow people to revisit content when needed; ideal for global teams and new joiners. 

·       On‑the‑job support

  • Office hours, coaching sessions, help desks, “floor walkers.” 
  • Where people apply new skills to real work with guidance. 


At the Schneider Electric, I recorded short video tutorials for different parts of the Digital Services Platform and Azure environment.


These weren’t Hollywood productions; they were straightforward screen captures with explanations. But they let busy engineers:


  • Watch at their own pace 
  • Pause and replay tricky parts 
  • Share with colleagues and new hires 


Combined with workshops and 1:1 coaching, they became part of a library of learning embedded in the platform.


Building a Coaching Layer


Training imparts knowledge. Coaching helps people apply it in their specific context.


In transformations, good coaching often comes from:


  • PMO and OCM professionals 
  • Experienced practitioners (e.g., Agile coaches, senior architects) 
  • Line managers who have embraced the change and can mentor their teams 


Coaching can be:


  • Formal – Scheduled 1:1s, team coaching sessions, retrospectives guided by a coach. 
  • Informal – Quick check‑ins, shoulder‑to‑shoulder problem‑solving, feedback on artifacts (e.g., project charters, sprint plans). 


In my work, I often used coaching to:


  • Help leaders practice new ways of communicating the change to their teams. 
  • Guide teams through their first few cycles of a new process (e.g., first sprints, first portfolio reviews). 
  • Support people wrestling with identity shifts (e.g., from project manager to product owner). 


When you think about your change, ask:


  • Who can serve as coaches or guides for others? 
  • How will we make their time available and visible? 
  • How will we measure the impact of coaching (e.g., improved confidence, smoother ceremonies, better artifacts)? 


Resistance: Natural, Predictable, and Useful


Early in my career, I didn’t have a formal “resistance plan.” But resistance was everywhere:


  • People questioned new tools (“The old one works fine.”). 
  • Leaders debated new governance (“This slows us down.”). 
  • Teams pushed back on new processes (“We’re already overloaded.”). 


I learned quickly that:


Resistance is not a problem to eliminate; it is information to understand and work with.


In later roles, I used tools like:


  • RACI matrices – To clarify roles, reduce confusion that often shows up as “resistance.” 
  • Stakeholder/Influence Strategy Matrices – Listing stakeholders, their likely resistance level, KPIs, and targeted actions to move them. 
  • Prosci ADKAR assessments – To see whether resistance stemmed from awareness, desire, knowledge, or ability gaps. 


Common sources of resistance:


  • Fear of loss – Status, competence, control, job security. 
  • Overload – Genuine lack of capacity to take on more. 
  • Lack of trust – Based on past broken promises or failed initiatives. 
  • Misalignment – Between stated goals and actual incentives or behaviors. 


Your job is to:


  1. Surface resistance early – through listening, not just by watching for overt pushback. 
  2. Diagnose the type – Is this rational concern, emotional reaction, or systemic constraint? 
  3. Address it appropriately – With information, involvement, support, or, in some cases, structural changes. 


Practical Resistance Strategies


Here are concrete tactics that have worked across contexts:


1. Involve Early Skeptics in Design

  • Bring vocal skeptics into working groups and pilots. 
  • Ask them to help identify risks and shape solutions. 
  • Often, ownership reduces resistance; if not, you at least get honest feedback early.

2. Use Data to Address Misperceptions

  • Where people say “This will never work,” look for small experiments or PoCs that can provide evidence. 
  • Share metrics (e.g., reduced cycle times, improved adoption) transparently. 

3. Acknowledge Real Pain

  • If a change will make some things harder before they get easier, say so. 
  • Recognize extra effort, provide temporary relief where possible, and avoid gaslighting (“This isn’t that big a deal”) when it clearly is. 

4. Adjust Where It Makes Sense

  • Not all resistance is irrational. Sometimes it reveals design flaws. 
  • Be willing to refine processes, tools, or timelines when good arguments surface. 

5. Clarify Non‑Negotiables

  • There are elements of change that are truly optional and others that are not. 
  • Communicate clearly which is which, and why. Ambiguity breeds endless debate. 

6. Align Incentives

  • If people are evaluated and rewarded using old metrics, they will behave in old ways. 
  • Tie some portion of performance management and recognition to desired new behaviors and outcomes. 


When Resistance Becomes Incompatible


Despite best efforts, there are times when individuals or groups remain firmly opposed to a change that the organization has legitimately committed to.


In those cases:

  • For some, resistance softens when they see others succeeding and when new norms are clearly established. 
  • For others, continued intense resistance may signal a mismatch between their preferences and the organization’s direction. 


At that point, two paths remain:

  • Accept and adapt – The person chooses to align with the new way. 
  • Exit or reassignment – The person moves to a different role or organization better suited to their preferences. 


This is uncomfortable, but it can actually strengthen the change. When people see that strategy is real, that the organization is willing to stand behind it consistently, they take it more seriously.


As a change leader, it’s not your role to “fire people.” But it is your role to:

  • Surface chronic misalignment to sponsors. 
  • Provide clear, honest information and support to individuals. 
  • Ensure the system does not endlessly bend around a few holdouts at the expense of everyone else.


Training, coaching, and resistance management are how change becomes lived reality rather than a PowerPoint concept. They are the bridge from “we’ve decided” to “we can actually do this.”

In the next chapter, we’ll zoom back out to the A.B.E.L. Model and show how to design a full change program around its four phases, Assess & Align, Blueprint & Build, Execute & Enable, and Learn, Leverage & Lead, including how to choose and apply the right tools at the right time.


If this chapter resonates, credit belongs to the people who coached me, corrected me, and believed in the work before it was proven.