Episode #5: Why understanding your stakeholder is the key to fixing tech resistance
Spot hidden concerns before they escalate into visible resistance
How to Avoid Stakeholder Blind Spots That Fuel Tech Resistance
Too many tech programs run into trouble not because the system is weak, but because influential stakeholders were never truly seen, heard, or understood. When concerns surface late, resistance spreads fast, and the program suddenly carries noise it could have avoided. In this episode, we unpack why traditional stakeholder analysis misses critical signals—and how a deeper, structured approach prevents surprises and protects adoption.
A solid stakeholder analysis is not a box-ticking exercise. It’s a risk-prevention discipline. And when IT teams apply it early, they reduce noise, protect their program’s reputation, and accelerate adoption across markets and functions.
Many ERP and platform programs underestimate the complexity of the human side of tech change. This leads to missing non-obvious stakeholders and ignoring the emotional impact of the change—two issues that often create late-stage resistance. This blog outlines a modern, practical three-step approach to stakeholder analysis based on behavioural science. It helps IT leaders see hidden concerns early, prioritise where their attention truly matters, and prevent issues long before they escalate. The outcome is fewer surprises, clearer alignment, and stronger adoption at and after go-live.
The Expanding Risk Surface of Tech Change
Modern tech programs – SAP S/4HANA, Salesforce, ServiceNow, custom platforms – touch more people than the project plan ever captures. The ecosystem widens every year. A workflow update in Finance changes how Production reports data. A new approval flow reshapes how Sales interacts with Operations. A dashboard rollout shifts decision-making authority across regions.
Yet many programs still rely on overly simplistic stakeholder matrices filled with the “usual suspects”: End Users, Key Users, Project Team.
The result? Noise where it was least expected.
You see this when a country lead pushes back days before UAT because he wasn’t fully informed about the resource requirements. When Works Council objections arrive late because they weren’t briefed early enough. When external vendors keep sending wrong information because new data requirements reached them too late.
These aren’t communication failures. They’re diagnostic failures.
A modern stakeholder analysis helps you see this risk surface clearly. It forces the team to ask: “Whose reality are we actually changing?” That question, answered early and with rigour, can prevent months of noise and safeguard adoption.
Why Traditional Stakeholder Analysis Fails
Most failures come from two predictable gaps: an incomplete view of the ecosystem, and a shallow understanding of emotional impact.
Programs focus on direct users, ignoring everyone indirectly affected. They rely on technical change-impact assessments that describe system logic instead of human reality. And they underestimate resistance that comes not from the process changes themselves, but from what people feel they lose: competence, autonomy, status, or safety.
Behavioural science is clear: humans feel losses far more strongly than gains. When people believe they are losing competence, influence, or control, rational explanations do nothing. Silence grows. Pushback increases. Adoption slows.
These signals rarely appear in standard project templates. They show up in late reactions, low support, toxic comments, and hidden clues that IT leaders only notice if they look for them. That requires a more structured, deeper approach.
Mapping the Full Stakeholder Ecosystem
A strong analysis starts with expanding the universe of stakeholders far beyond the classic list. Think in concentric circles: those directly impacted, those indirectly impacted, and those with the authority to slow, block, or accelerate progress.
This includes:
• regional leaders whose teams supply data
• works councils with procedural power
• external vendors whose workflows shift
• field teams that enter production-level data
None of these groups may be “heavy users”—but each can generate noise, delays, or reputational risk if missed. This wider lens ensures no one is surprised later.
Prioritising Influence and Impact With a Human Lens
Once you’ve identified the ecosystem, the next step is prioritisation. Influence is not only formal authority; it’s attitude. A stakeholder with medium formal power but high scepticism can be more influential than a supportive senior sponsor. Impact is not only technical; it’s operational and emotional.
Here is where many programs fall into the trap of over-communicating irrelevant technical details if they don’t know enough about their audience groups. A senior leader doesn’t need to know every new system step. They need to know where their teams need to invest time, what might slow operations, and where resistance is likely.
Profiling the Stakeholders That Truly Matter
Priority stakeholders—those with high influence and high impact—require deeper profiling. This goes beyond listing process changes. It means understanding both the rational and emotional implications of the change.
Rational impacts include changes to workflows, responsibilities, tools, skills, and workload. Emotional impacts include perceived loss of competence, autonomy, control, status, or job security. These concerns often stay hidden unless surfaced deliberately.
A thoughtful profile helps you anticipate questions, resistance points, and areas where early engagement prevents noise. It also shapes the communication and engagement interventions that matter most.
What IT Leaders Should Remember
Hidden concerns are predictable—if analysed early
Influence is shaped by attitude, not just hierarchy
Technical change impacts must be translated, not copied
Emotional impacts drive more resistance than process changes
A structured stakeholder approach reduces surprises and protects program credibility
About your host
Arne Kötting founded COSYN after years of seeing organisations struggle with the human side of tech change. He built the Change Playbook to codify what actually works based on 20 years of watching these patterns.
The Change Playbook is designed for IT program teams to confidently manage the human side of tech change in-house, without expensive consulting dependencies.
His conversational style cuts through complexity to reveal the fundamental principles that make tech change communication work - principles you can apply 1:1 to your own transformation challenges.
Get in touch
More podcast episodes from
a Change in Conversation
