Episode #9: How decentralizing comms can help to hedge local resistance 

Learn how to activate local multipliers to turn 'HQ noise' into local ownership and secure global adoption 


The "HQ Trap": Why Centralized Communication Kills Global Adoption 

If you are leading a global IT program—whether it's SAP, Salesforce, or a data platform—you are likely designing, planning, and governing it centrally. That is necessary for technical architecture, but it's fatal for user adoption. When communication remains fully centralized, local markets perceive the rollout as a distant "HQ initiative" rather than their own, creating a vacuum of ownership that leads to shaky go-lives and overloaded hypercare. 

This article analyses one of the most underestimated sources of program failure: the lack of strategic localisation. While most Program Leads view localisation as a translation task or a "nice-to-have," behavioural science shows it's a critical mechanism for risk mitigation. We explore the two psychological drivers behind local adoption—the Messenger Effect and Contextual Relevance—and provide a practical framework for scaling local engagement without overloading your central team. You’ll learn how to replace heavy "cascading toolkits" with agile "mini-briefings" to secure ownership on the ground. 

 
The "HQ Trap" in Global Programs 

Global transformation programs are naturally centralized. You control the budget, the timeline, and the solution design from the core. This centralization ensures the technology works. However, when you apply this same logic to stakeholder engagement, you fall into the "HQ Trap." 

You send the newsletters, publish the SharePoint sites, and host the town halls. You assume that because the message was sent, it was received. But in the local markets, the silence is growing. 

When communication feels like it comes from "Headquarters," it triggers a psychological distance. Local teams lean back. They treat the program as something happening to them, not with them. This lack of ownership isn't a communication failure; it's an operational risk. It manifests as low participation in UAT, ignored training invitations, and a spike in "basic" helpdesk tickets at go-live because users simply didn't engage until the system forced them to. 

 
Why Localisation  is a Risk Mitigation Mechanism 

To fix this, we must stop treating localisation as "translation." Changing English slides to French slides is a linguistic exercise. Changing "HQ's Project" to "Our Opportunity" is a behavioural one. 

Localisation works because of two specific behavioural mechanisms that no central team can replicate. 

  1. The Messenger Effect: Behavioural science confirms that we trust messages based on who delivers them, not just what they say. A slide deck from a Global CIO is "information." The exact same message delivered by a trusted Country Manager is "instruction." Local multipliers outperform the core program team because they hold the existing trust capital of their teams. If you don't leverage this, you're fighting gravity. 

  1. Context Equals Relevance: A global message explains the strategy: "We're standardizing data to improve global reporting." A localized message explains the reality: "This replaces the manual report you hate doing every Friday." 
    HQ can't answer the local questions: "What happens to my legacy tool?", "How does this affect our local compliance?", "Will this slow down our month-end close?". Only local leaders can translate the global "What" into the local "Why." 

Scaling Localisation  Without Overloading the Core 

The objection we hear from every CIO is the same: "We don't have the resources to hand-hold 40 countries." 

This is valid. Your core team can't write custom communications for every market. However, you don't need to do the work for them; you need to enable them to do it efficiently. 

Stop "Cascading," Start "Activating" 

The traditional approach—sending a 50-slide "Change Toolkit" and asking countries to "cascade"—fails because it transfers the burden of work to overloaded local teams. They don't have time to decipher your slides, so they do nothing. 

Instead, shift to Mini-Briefings. 

A Mini-Briefing is small, timely, and actionable. Instead of a massive monthly pack, give your local multipliers one clear task aligned with the rollout calendar. 

  • The Task: "Forward this email to your Heads of Department." 

  • The Context: "Here is why this matters this week." 

  • The Asset: "Here is the slide/email draft—edit the parts in yellow." 

Make Materials "Use-Worthy" 

Local teams are pragmatic. They'll only execute communication if the materials are simple, visually usable, and easy to adapt. If a multiplier has to spend 30 minutes reformatting your slide, they won't send it. If it's ready to go in 5 minutes, they will. Friction kills execution. 

Key Takeaways for IT Leaders 

  • Global aligns, local activates. You can't achieve adoption from the centre. You can only inform. Adoption happens when local leaders translate that information into meaning. 

  • Localisation / Translation. It includes adapting to local legacy systems, business priorities, and cultural communication styles. 

  • Multipliers are your scale engine. You can't run a global rollout without a network of local advocates who understand the cultural codes and power structures you don't see. 

  • The giant "Toolkit" is dead. Stop sending massive zip files. Start sending agile, bite-sized "Mini-Briefings" that respect your multipliers' time – and ensure that important comms are used on-time, on-brand, on-message. 

  • Adoption is the metric. Investing in localisation isn't about "feeling good." It's about reducing go-live risk, minimizing hypercare costs, and protecting the ROI of your IT deployment. 



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.


More podcast episodes from
a Change in Conversation


Previous
Previous

Episode #11: Why recognition is the fuel that will power your team through the ERP marathon 

Next
Next

Episode #8: How to find the sweet spot of visibility for your IT program