Objections to wikis in companies
I was searching through my notes this morning and found a response I’d given to a consulting company about their approach to supporting/using wikis within schools. The original note was an email I’d written where I’d taken their team’s key points and concerns as topic headings.
I re-read it, and realised pretty much all of it was directly analogous to using wikis in organisations (at least those companies where employees are primarily knowledge-workers).
Re-reading and editing notes helps me remember, So I’ve done a quick but of editing, a search/replace of ‘teachers’ to ‘employees’ and thought I’d share it here.
1) "Wiki's take too much time to manage. I haven't got time to update pages"
Having seen quite a few employee's workloads up close, in various organisations, any wiki implementation would need to be highly sensitive to the contribution time required/expected from employees.
One of my key counterpoints to this objection is that wiki content updating shouldn't be seen as additional work, but as a replacement for other 'content' production - email is the best example.
Think how much time an employee spends in Outlook. What if they just shifted their writing style a little for a wider group than the cc list and wrote the email straight into a wiki page, where the original recipients receive the notification? And what if those recipients, instead of replying by email, used comments and updated the original wiki page? No extra time would have been spent, but that previously closed conversation in email has now become a useful piece of information, available to others.
Additionally, if the wiki was used as a delivery mechanism for some project work, this integration with an employee’s existing workflow would ease the employee’s acceptance and use of the wiki?
2) "...Take a quick look behind Wikipedia in the community pages, and you can see a vast and complex governance framework in place. It's not completely true that anyone can edit everything."
Absolutely. But Wikipedia's structure has developed, ostensibly to combat commercial and political 'spam' and other page abuse, because the wikipedia community want to maintain open access to content wherever possible. Wikipedia is also a huge, globally distributed, high-volume content environment; a highly structured framework of editors and approvers is needed.
Companies are operating behind their own 'firewall' with company regulations and behavioural norms governing behaviour, particularly content creation (creating 'content' from synthesised knowledge in compliance with various existing frameworks is what knowledge workers d0) - it's unlikely they'll need a secondary level of organisational control over content creation.
3) "...Within a company, people will probably want to exert greater editorial control..."
Based on what insight? I think this is a dangerous assumption. I had to tackle the same knee-jerk desire for control in implementing corporate wikis - those that were open, i.e. easy to read and edit, with no control and 'approval' generated far more content and viewing than the competing solutions that led with a role-based authentication as their primary interaction paradigm.
I'd counsel that one should avoid assumptions about control. Instead, see how people react and contribute. It may be entirely appropriate to implement editorial approval, but I think that should be decision based on whether the emergent behavioural norms dictated it. This 'control' would be as a last resort, not a starting policy for wiki use.
4) "What about control over the user community, how do make people clean up content and keep things up to date?"
However, I think it's a terrible idea to force employees to perform content cleanup of content. The editorial role should be celebrated and given as a defined responsibility/reward.
Another, deeper approach; the potential for creating 'virtual prefects' - but with a more positive role (perhaps with an explanation/discussion of how editors work); to maintain responsibility for growing, nurturing and maintaining content areas - similar to wikipedia's editors and social standing within their peer group).
Editors and wiki guardians are the lifeblood of a decent, living wiki; no activity in the system should be construed as negative or punishment.
5) "Wikis require a critical mass of users (relative to content scope) to be effective, otherwise the content looks thin, and people don't go there..."
I disagree. Studies suggest that content/readership in any group environment is skewed heavily toward a small number of enthusiasts that will contribute the majority of content. There is an opposing study that argues in Wikipedia's case, a broader collection of contributions are made by a larger number of infrequent contributors coupled with a tiny amount of 'janitors' who maintain and format the vast majority of Wikipedia's content.
However, In my experience of running wikis over a year 'inside a firewall'; i.e. a trusted social environment, where there is almost no contentious information and contributors either know eachother or are aware of team/departmental membership, the classic Pareto effect comes into play.
I estimate that over 90% of content is created by ~10% of users - that's based on looking carefully at edit/creation in ratio to content views.
But that ratio is, in my mind, perfectly acceptable in the context of a business; people gain benefit from reading content, even if they don't actively contribute (yet). The real challenge in these 'known' environments is to get collaborative edits; where people know each other, or are in a shared social space, they don't seem inclined to edit/add to 'other people's pages'
6) "The philosophy and high level concepts within companies, (such as defined responsibilities, defined framework, the existence of governance structures, policies, the community of practice etc) demonstrate a framework of use. Such a framework of use is needed for Wikis, and something that more and more businesses will need guidance on..."
I disagree; the structural approach outlined above presents a real danger, in that it creates a particular culture of use, skewed toward the initial structure and policy that was dictated.
Far better to design the environment to be flexible; let a culture of participation grow organically through encouragement and continual refinement.
Motorola is a good example of this organic, 'discovery' model of organisational use of social software (wikis in particular). Motorola has a hugely successful wiki ecosystem, with little, if any, 'control' and rapid, but completely organic growth/usage that reflects 'real people's needs'.
The organic metaphor is a good one, as the level of content they have 'grown' (3,200 wikis, 17tb of searchable data) requires farming:
"We don't have a wiki police group," Redshaw said. "We just think it's the way the business runs. All a business is, is human beings talking to each other, trying to get stuff done." "People start using the capabilities as they become available," said Singh. "They are not advertised, but widely used." Despite the laissez-faire approach, all is not anarchy at Motorola. Managing the platform's usage are 250 "knowledge champions" who take responsibility for different subject areas in the Open Text collaboration infrastructure. The group meets biweekly to set governing processes.
(Quoted in eWeek)
To get a really detailed insight into Motorola's wiki ethos (if you've got an hour), listen to Toby Redshaw of Motorola.
