In an earlier post I indicated that wiki ‘adoption’ refers to the stages through which users typically progress before committing to a new technology, with different adopter ‘types’ (e.g. innovators, early and late adopters) progressing through the stages at different times and speeds. Perhaps an even simpler (although less scientific) way of categorising users lies in the distinction between those who are technical (e.g. technologically familiar or curious) or non-technical, with ‘technical-users’ more readily adopting wikis and associated concepts of teamwork, knowledge capture and sharing, and learning therefrom. ‘Technical users’ tend to be ‘innovators’ and ‘early adopters’ often comprising people from technical companies and engineers. In fact, my survey of 102 companies corroborates this generalisation, with the greatest proportion (37.26%) of participants coming from the IT sector followed by the professional services sector, and 22.55% being IT engineers and 15.69 being consultants.
The survey results indicated that high levels of self-learning (69.93% of responses) have been supported by peer-to-peer learning (18.18%) with very little targeted/tailored training (1.40%) or issue of best practice/usage guidelines (10.49%). Popular mechanisms used to supplement self-motivated usage and ‘unlearning’ of older inefficient yet familiar habits include information being placed on to the wiki, people being involved in projects using a wiki and emailing links to the wiki. Those mechanisms moved users rapidly through the first adoption stages of becoming aware of the wiki, to understanding through trial/experimentation with the wiki.
The Wiki Adoption Spiral depicts how ‘technical-users’ move through adoption stages and spread wiki usage virally to later adopters. It reflects that:
- adoption stages for ‘technical users’ (constituting the first adopter categories) are shorter and converge as they proceed quickly through initial (awareness, understanding and trial) stages, creating their own ‘transition mechanisms’ involving self-learning and experimentation with wiki use.
- adoption categories and processes are fluid, as different users can be drawn into the process without early categories having completed the ‘typical’ cycle. For example, due to organic growth other categories maybe made aware of the wiki prior to its ‘adoption’ (e.g. through involvement in projects wikis), and commence their adoption process.
- progress through stages can be halted (i.e. no growth through abandonment or rejection) if there is no perceived ‘need’ to use the wiki and/or barriers are not overcome.
Whilst early adopters more readily enter the adoption process because they are more technically competent/inquisitive, the implication from the above points is that top-down support /facilitation is equally important for developing good ‘wiki’ practices within the initial adopter group as for later adopters. Such facilitation involves generation of a shared understanding about collaboration goals, wiki purpose, responsibilities and ‘gardening’ practices. The experience/knowledge of those adopters can then be coupled with other transition mechanisms (e.g. more ‘technical training’, involvement in projects using a wiki and information being made available on the wiki) to accelerate the diffusion process to other adopter categories.
The high level of ‘learning by doing’ and peer-to-peer support illustrates an opportunity for users to participate in a collaborative learning experience, which provides an ideal platform for encouraging communication and collaborative behaviours in general (e.g. helping transfer knowledge/ideas throughout the company, working across organizational boundaries and learning from past experience/best practices of others).
Although reliance on email and familiarity of other tools may illustrate a reluctance to ‘unlearn’ habitual less effective work practices, there needs to be a balance between directive wiki usage and support for different communication styles as people become accustomed to using wikis and the different capabilities they can provide. That also requires responsiveness to feedback and anlyses of ways in which existing tools can be integrated with wikis to best support people in their work.