Intermediate

Navigating Stakeholders and Change Management

How to win internal champions, disarm skeptics, handle the four types of resistance, and communicate AI limitations without derailing the engagement.

✍️ AI School Editorial Team · Lilly Tech Systems 📅 Published Jul 2, 2026 · Reviewed Jul 2, 2026

The People Problem

Technical AI problems are solvable with enough time and the right stack. People problems can end an engagement that is technically succeeding. An FDAE who builds an excellent system but loses the trust of the daily users, or fails to keep the executive sponsor informed, or underestimates the anxiety of people whose job the AI will change - that FDAE leaves behind a system that will not be maintained and a customer who will not renew.

Stakeholder management is not a soft skill bolt-on to FDAE work. It is the discipline that determines whether the technical work survives contact with the organization. You need to know who the players are, what each of them needs, and how to keep all of them moving in the same direction while you build.

The Cast of Characters

Every enterprise FDAE engagement has a predictable set of stakeholder types, each with distinct motivations and concerns:

RoleWhat they wantWhat they fearHow to keep them aligned
Executive sponsorA visible win that justifies the investmentWasted budget, reputational risk if it fails publiclyWeekly status email: what worked, what’s next, what you need from them
Daily userLess of the painful work; job preservedBeing replaced, or having their expertise devaluedInclude them in every prototype review; credit their domain knowledge explicitly
IT / securityA system they can maintain and that does not create riskA shadow IT project that bypasses their controlsInvolve them early in discovery; treat their constraints as design inputs
Middle managementTheir team to be productive; their own position to be safeTheir team’s headcount being reduced based on the pilotFrame AI as amplifying their team, not replacing it; give them data on time saved
Internal AI skepticTo be proven right that this will not work, or to protect the organization from a bad decisionLooking like an obstacle if the project succeedsInvite early feedback and address technical objections specifically; convert skeptics into co-owners

Building the Internal Champion

Every engagement needs an internal champion - a person inside the customer organization who is invested in the success of the project and will advocate for it when you are not in the room. The champion is usually not the executive sponsor (who is too far from the work) and not the daily user (who does not have enough organizational influence). The champion is typically a team lead, a director, or a senior individual contributor who has credibility with both sides.

You do not find the champion - you make them. The process:

1
Identify the person who cares most about the problem. In discovery, pay attention to who asks the most specific questions, who brings up the pain point unprompted, and who stays engaged after the meeting ends. That person has already decided the problem is worth solving.
2
Give them early wins they can take credit for. When the first prototype produces a useful output, send it to the champion first with a note that credits their domain knowledge for shaping the design. They share it internally. The system’s success becomes their success.
3
Keep them informed between demos. A daily or twice-weekly check-in - even a two-sentence message - keeps the champion engaged and gives them current talking points when colleagues ask how the project is going. Silence between demos breeds doubt.
4
Teach them to explain the system, not just use it. A champion who can answer “how does it work?” with a coherent answer at the right level of abstraction can defend the project in meetings you are not in. Brief them before each stakeholder presentation, not just after.

Handling the Four Types of Resistance

Resistance to AI projects in enterprise environments usually falls into one of four categories, each requiring a different response:

⚠️
Job displacement anxiety: “This is going to replace me.” This is the most emotionally charged resistance and the most common. Do not deny it with vague reassurances. Acknowledge it directly: “That’s a real concern, and I want to be honest with you. What this system does is [specific task]. What it cannot do is [everything else you do].” Then show them specifically how the tool makes their existing job better, not redundant.
⚠️
Technical skepticism: “AI cannot do this reliably.” This is often the most useful form of resistance. Take it seriously and engage with it specifically. Ask the skeptic to provide examples where they expect the system to fail. Run the system on those examples in the meeting. If it fails, you have found a real limitation. If it succeeds, you have converted a skeptic into an early validator.
⚠️
Process ownership resistance: “We already have a process for this.” Someone whose process the AI is changing may resist not because the AI is bad but because the change threatens their ownership of a workflow. The fix is to position the AI as a tool within their existing process, not a replacement of it. Ask them to define where the AI fits into their workflow, rather than presenting a workflow that displaces theirs.
⚠️
Compliance and risk caution: “We cannot use this without legal sign-off.” This is legitimate, not obstructive. Do not try to work around it. Identify the specific concern (data handling, model outputs as official records, liability for errors), route it to the correct person in the customer organization, and design the system to be defensible. An AI system with an explicit human-review step for consequential outputs addresses most compliance objections.

Communicating Limitations Without Derailing the Engagement

AI systems have real limitations. Communicating those limitations is an ethical requirement and, paradoxically, the best way to maintain credibility with skeptical stakeholders. The mistake is either hiding limitations (which destroys trust when they surface) or over-disclosing them in ways that kill confidence in a system that would genuinely help.

The right approach: be specific and constructive. Not “sometimes it makes mistakes” - that applies to everything. Instead: “For inputs that are longer than 4,000 words, the system’s accuracy on the third section drops by about 15%. We handle that by [mitigation]. If you see that pattern, [recovery step].” Specific limitations with specific mitigations are credible. Vague disclaimers are not.

Managing Disappointment

Sometimes a prototype does not work as well as expected. Sometimes a scope change mid-engagement means the most valuable thing you could build is not the thing the sponsor announced to their team. Sometimes the timeline slips. Managing disappointment well is what separates FDAEs who get repeat engagements from those who do not.

The core principle: surface bad news early, with a specific plan. “We found that [X] is not working as expected because [specific reason]. We are [specific action] and expect [specific outcome] by [specific date].” A stakeholder who hears this on day three can adjust. A stakeholder who hears it on day thirteen, at the demo, cannot. Early honesty preserves the relationship. Late honesty burns it.

📚
See also: Once the stakeholder relationship is stable and the system is ready, the final phase of the engagement is delivering something the customer can operate without you. Lesson 7: Deployment, Monitoring, and Knowledge Transfer covers the production deployment checklist and the self-sufficiency test.

Ready to Go Deeper?

Live instructor-led courses from our partners. Affiliate disclosure.