Driving viral change is more than good communication

Most enterprise social network project use virality as an obvious change management means. First because the very nature of the tool, close to consumer social networks, makes it natural. Second because it uses employees as change agents, which is also a smart way of driving change.

Virality = relevance, proximity, credibility and cost efficiency

Making employees carry any corporate project towards their colleagues hase many upsides. First one is proximity : the message is carried by someone the employee knows. Which leads to credibility : the carrier has no stake in the project so if he advises other to adopt a new tool or new behaviors it’s certainly because he objectively benefited from doing it himself. If he has nothing to win in promoting something it means that he really wants to help me. Relevance then : being among his colleagues every minute of the workday, the employee is able to act at the very moment they are in need. The solution he brings will be seen as relevant and more attention paid to it. Last point, having an army of ambassadors that grows over time is very good for the company since the fact they’re being trusted for such a mission increases their engagement…and lowers deployment costs.

So “ambassadors” programs make a lot of sense and work quite well in change management programs. Among the many myths related to enterprise social networks it may be one of the only that work in nearly every cases. Except in some rare ones…and that’s what we’re going to explore.

Use cases matter more than employees

Find the right ambassadors is not that complicated. In general a large part is already well known, other apply spontaneously or can be identified through an internal survey. Identifying employees who are very active on consumer platforms is also a means but it’s less reliable.

Then they’re engaged, trained, provided with the needed discourse and materials. Sometimes a recognition program is set up to thank and value them. And tis is where things get tricky : even if the purpose is to sell the project, a too strong focus on communication may be more than counterproductive.

Change management implies factual results, not only delivering a message

At this point some may think that, in such a context, ambassadors will carry the message so they need to understand it and be able to clearly explain and deliver it. What is a mistake. Doing so may make tem disengage or even lose any kind of credibility in their colleagues’ eyes by turning them into men with a sandwich board.

Ambassadors don’t sell a message or a project. They sell use cases and value propositions. They don’t spread the good word among their colleagues but help them solve problems and making their work simpler. If they’re asked to say that “the social network is good for you” they may never do it and, if they do, no one will listen to them and they won’t look credible anymore. If they’re asked to say “if you want to do this, do it this way, that’s better for you for such and such reason”. It will work better. By doing so they’re going to deliver value, improve things, help people and even improve their reputation. They won’t be the voice of the company but useful people who help their colleagues getting things done.

Don’t share the message but spread good practices

So the focus should not be on the message but on use cases. The purpose is change management, not message spreading : the first asks act active return, not the second. Employees dont convey messages but share practices, tricks and tips to make their job simpler. What supposes a deep knowledge of what one’s job is, what are the bottlenecks that slow things down. It’s not about what others – managers etc – think they should change and improve but what end users themselves say they struggle to and want to have it changed. As a matter of fact it often happens that the gap between what managers think users need and what users themselves say – when asked – is incredibly large.

It’s like a new kind of Maslow Pyramid applied to day to day work : if basic needs at not meet there are very little chance to embark users towards more advanced uses. This is something anyone must be aware of when working on use cases : start with basic needs and make sure the chosen technology can meet them. A tool that does not make basic things easy won’t be used for advanced ones, even if it’s very good at it. That’s a very common issues : social technologies are often good at advanced uses but fail at being as efficient as old technologies for many day-to-day basic ones.