I’ne never been that comfortable with the concept of adoption when applied to enterprise tools. More precisely when the point point was “driving adoption”.
Of course adoption is necessary. And, like every necessary thing, businesses can not afford not to drive it. Nothing but pure logic…but it can’t prevent me from feeling its sounds odd. I was slowly getting used to these words when Paula Thornton brought it back to my attention.
Let’s start with the meaning of words.
Driving : giving oneself the means that are necessary to achieve someting and the appropriate indications to pilot actions.
Adoption : action of making something one’s own in a voluntary way. Supposes the benefit, sense and implications are understood.
If both are necessary, I still can’t put them together in the same sentence. The reason is obvious : if adoption implies spontaneity and a choice that’s not made under duress, driving means make people do something unnatural because if it were natural people would adopt without any external intervention. Some may say that driving only means “create a breeded ground” but I don’t think that’s how companies see things : it would mean they don’t have any hold on the result and, as a result, they only try to make their best so things can happen instead of considering they have an obligation to produce results, what is not conceivable for most businesses. So driving adoptions means making people do unnatural things and such an approach explains how things are so difficult, why people don’t adopt or adopt reluctantly.
Is it a dead end ? Not at all. If both adoption and driving are necessary, we have to be cautions not to mistake what has to be driven and the final result.
Let’s start from the beginning.
Adopt what ? New tools, new practices. One by one ? Both at the same time ? That’s the chicken and egg situation and, at the end, this doesn’t matter here.
Pilot what ? The adoption ! Actually not. And this is where resides the mistake that kills many projects.
If adoption must be a personal and deliberate act, conditioned by sense, real and understandble benefits, that’s not adoption that has to be driven but sense and benefits.
The truth is that, deliberately or not, adoption was used as a substitute for sense and alignment. So sense and alignment have to be driven, because there are ways to have a hold over them provided one has the will and the courage to make the appropriate efforts.
How to do ?
– Focus on people’s real problems, which are often linked to daily operations. This implies a social routine is implemented, not in replacement for processes and workflows but around them.
– avoid having conflictual strategies. In other words, the “social software project” should not drive people in directions that are opposite to the way they are measured and rewarded.
Sense and alignment can be driven provided since we’re talking about concrete things to implement, to correct, things we have a hold on, that will make people adopt for the one and only reason that everything will be obvious, logical. In the worse case, things may have to be explained, made clear, but it won’t be about convincing people what is often the case when one attempt to drive adoption. In the first case, we rely on facts, in the second on words.
As David Pritchett commented Paula’s post, quoting M. Kanazawa : “People don’t hate change. They’re hating the way you want to change them”.
Driving adoption is like building the enterprise starting from the “2.0” although the 2.0 for businesses has to be built starting from the enterprise.
The best way not to exhaust oneself pushing people to do unnatural things is toÂ deal with the nature of what they do. Adoption can’t be driven. But it can be induced by driving sense and alignment.