Alan Porter writes a great blog post – one I wish I’d written! – over on Ars Technica examining some of the perceived barriers to wiki adoption that he has come across. He says:
As I continue to research and write my upcoming book on wikis, I keep hearing one word over and over again. That word is “BUT” (complete with all-caps), as in, “I would like to use a wiki, BUT…” or “We tried using a wiki, BUT…”
What follows is usually an excuse for why the speaker feels that a wiki isn’t a worthwhile tool for collaboration in his or her environment. I use the word “excuse” deliberately, because rarely does anyone articulate an actual business reason, such as a lack of need. When I ask deeper questions, I invariably find that the objection isn’t to the wiki technology itself, but instead to the concept of collaborative authoring and a perceived loss of control over the content.
Porter’s post is an excellent view into the cultural and technical barriers people erect in order to isolate themselves from change. Cultural excuses include:
- We tried one once and no one used it
- The cost/benefit ratio is too high
- I’m too busy doing actual work to try anything new
- It’s overwhelming, and I don’t know where to start
- If my management doesn’t care, why should I?
- It won’t be accurate
- I prefer meetings
Technical excuses include:
- I need to learn a mark-up language
- Search doesn’t work
- It’s a black hole
- It isn’t like (name your favorite application here)
- It’s a security nightmare
Porter debunks each myth with great care, and then poses a set of questions that everyone should ask themselves before they embark on a wiki project.
The whole post reminds me of the Why Don’t You/Yes, But… Game from Transactional Analysis where one person offers the other help, but that help is rejected every time with an excuse. I have certainly observed managers (even quite senior ones) playing Why Don’t You/Yes, But… around social technology, particularly wikis and blogs. Let me write you a sample script:
Manager: We need to improve collaboration and capture knowledge.
Consultant: Why don’t you use a wiki?
M: Yes, but it’ll take us 18 months to get it through IT.
C: Why don’t you use a hosted wiki?
M: Yes, but then our data won’t be secure.
C: Why don’t you create a regular back-up schedule?
M: Yes, but that’s too difficult.
C: Why don’t you go with a vendor that backs up for you?
M: Yes, but that’s too expensive.
C: Why don’t you install open source software on an under-the-desk server, Trojan Mouse style?
M: Yes, but if IT ever find out, they’ll kill me.
As Wikipedia says, “”Why Don’t You, Yes But” can proceed indefinitely, with any number of players in the [Manager] role, until [the Consultant’s] imagination is exhausted, and she can think of no other solutions. At this point, [the Manager] “wins” by having stumped [the Consultant].”
Every time I have found myself embroiled in this game, the project has stalled, often before anything has happened. It’s so easy to think of reasons why something won’t work and much harder to think of ways to make sure it does. And when I say Manager in the above example, I don’t just mean middle managers; I have played this game with CxOs, people you would think could just say, “Make it so”, people who are supposed to be the ones setting their company’s technology agenda.
We have to recognise that many companies behave like dysfunctional mega-personalities, with each member of the collective reinforcing each other’s bad behaviour. We can’t always use logic and evidence to deal with people playing these games, but instead must draw from other sources of inspiration such as psychology in order to understand how to move things forward. And that’s easier said than done!