Penny Edwards blogs atWikiConsulting.com

Over the last few weeks there’s been some interesting exchanges around mandating the use of social tools (in particular blogs) within an organisation as ‘reflective’ tools for sharing and learning (see Abraham, Leberecht, Leyden and Cornelius). Those exchanges dovetail nicely with another weighty debate around tailoring the functionality of tools like ‘Facebook’ and ‘Twitter’ to suit the enterprise context, and more particularly, whether their use should be given a top-down or other informal nudge to ensure contributions are sufficiently work-related. The former is now moving through a spectrum of mandating -> encouraging contributions and the latter is focusing on channeling or containing them.

Moving away from a ‘they just must‘ perspective, we can instead observe how people are communicating and with whom, and why in other instances they are not. We also have the opportunity to consider how to channel ‘twittering’ behaviour to help us work in a more fun, informed and effective way.

The working paper “Communication (and Coordination?) in a Modern, Complex Organisation” by Adam M Kleinbaum, Toby E Stuart and Michael L Tushman (Harvard Business School, First Look, 29 July 2008 ) provides some extraordinary insight into the structure of communications in a modern organization. In other words, who is communicating, how often and with whom? To answer the following question, the study analysed millions of electronic mail messages, calendar meetings and teleconferences for thousands of employees in a geographically dispersed, multiunit enterprise:

What is the role of observable … boundaries (i.e. business unit, office location, gender and tenure in the firm) between individuals in structuring communications inside the firm?

The salient findings include:

• The extraordinarily high similarity and parallel relationship between email and face-to-face/social networks within the firm.

• The striking relationship between e-mail activity and hierarchical level; the average executive (members of the top four salary bands) in the sample sent and received more than twice as many e-mails as the average middle manager who, in turn, sent and received more than twice as many as the average rank-and-file employee.

• That women, mid- to high- level executives, and members of the executive management, sales and marketing functions are most likely to cross the company’s social structure gaps and participate in cross-group communications.

What we don’t know is whether (and if so the extent to which) other communication/collaboration technologies were available within the firm. Of course the authors warn against generalisations based on results from a single organisation, but given well-known issues associated with email overuse, abstinence from traditional ‘above-the-flow‘ KM/collaboration, and the need for buy-in from management, I think the study supports some principles which can guide behaviour in other instances.

If social tools are thrown into the mix, any adoption strategy should look to the participation of the groups identified above, who are key information/social networking nodes and would be invaluable to any social software pilot. But engaging the high-level executives (in particular) could be a very large mountain to climb. Whilst that group has a considerable amount to gain from ‘above-the-flow’ activities and slight changes to behaviour (like micro-blogging instead of emailing), they usually have well established preferences for face-to-face, email or phone communications, and need to cope with a variety of political/power dynamics. And as for a “they just must” approach with this group: forget it!

Simply articulating the value to be obtained from experience will clearly not be enough, even if people are being given the time to take up the opportunity. Instead, barriers to the participation, reflection and learning processes need to be lowered. Amongst other ways, that can be achieved by giving people the means to capture their thoughts on a platform in a more informal conversational way - whilst they are working (i.e. more ‘in-the-flow’ of daily operations). Whether that be through micro-blogging, sticky notes or commenting, status updates or wall-postings, the process should reflect people’s preferences for technology and communication style. As we are seeing, that means enabling ‘twitter-ing’ quick-fire style exchanges during people’s work, which can be rapidly embellished and/or responded to by others.

And rather than defining the scope of the tools (like “please use this for client and not social purposes”), use tags, aggregators and RSS to manage/channel the flow of content. Having started the debate, McAfee on further reflection notes “… norms and policies might not be the only ways to make a tool like Twitter work well for enterprise purposes”. The idea is to “tag” the tweet, perhaps by prefacing it with characters (like @FM) corresponding to a client or contract. In that way, it would be possible to categorize and organise the flow of information.

In fact, that may be one use case for PagesPlus (which Paolo Valdemarin from Evectors very kindly demostrated to everybody at Headshift yesterday morning!). Since the core of PagesPlus is an aggregator, it can digest any form of RSS/Atom and use tags to organize everything it aggregates. Because the aggregator supports tag schemas not only can it distinguish between a topic-tag and a category-tag, but it also allows you to create your own schemas to address specific needs. With the WYSIWYG application allowing users to easily create content at the front end, it would be a small step to continually auto-save the content and for the system to recommend to the user tags based on an analysis of the text being typed (and other tags applied in the past). That content could be pushed out to the categories and pages corresponding to the tags, and to the users who are subscribing to feeds from those categories.

Essentially, designing the tools around people’s preferred styles of communication and collaboration will help to support behaviour rather than control or mandate it - a poor counterpart. People may then filter content and functionality depending on their style and preferences, and then hook other people and content into the process by creating actions and feeds out of their activity. All up, that approach should help to get people on board and keep them there.

In the same way the famously contrasting perceptions of the nature of organizational communities has animated a great debate in organization theory during the past few decades, so too perhaps will the issues discussed here continue to test knowledge workers. Kleinbaum et al cite the study of Hannan and Freeman (1977), which posed the classic question, why are there so many organizational forms, and DiMaggio and Powell’s (1983) rejoinder, why are there are so few. Likewise, I wonder about the levels of diversity of communication and collaboration actually being facilitated in organisations, and why there aren’t more.

There are a number of ways in which new collaboration technology may be introduced into an organisation, including:

1. An ‘inside-out’ approach which focuses first on the business needs and capabilities to be developed, then on identifying the technologies which can support those needs/capabilities (McAfee approach - “Mastering the Three Worlds of Information Technology” Harvard Business Review (2006)).
2. Continuous scanning for innovations/new technology and matching promising innovations with relevant problems (Rogers’ approach - Diffusion of Innovations (1995) Free Press, New York).
3. Operating a ‘me-too’ approach as a result of ambiguous goals and a volatile/uncertain environment, whereby the implementation of new technology is influenced by/modelled on what other organisations are implementing or the current technology adoption trends in the market (Mimetic Isomorphic approach - DiMaggio and Powell The Iron Cage Revisited American Sociological Review (1983)).

In an effort to determine which approach businesses favour and the consequence of the approach in terms of wiki adoption, I asked survey respondents to identify the drivers behind their wiki implementations and how they are actually using their wikis, to gauge if there was a correlation between the two. The key business ‘needs’ identified spanned three broad areas of supporting collaborative work practices (27.88% of responses), increasing the effectiveness/efficiency of existing tools (22.68%), and improing the ability to locate or retain information/knowledge (23.05%). Few responses indicated (or admitted?) that the wiki had been implemented simply because it represents something of a new trend in collaboration technology.

In terms of what the wiki is actually being used for in the workplace, responses indicated their primary use as knowledge bases (22.53%), for ideas generation (16.21%) and project collaboration (16.21%). With the primary need being to support collaborative work practices, higher actual uses for ideas sharing and project collaboration might have been expected instead of the wiki’s predominant use as a knowledge base. Of course, it could be inferred that the primary need is being satisfied through a variety of wiki uses, of which the knowledge base currently predominates, with actual uses for ideas sharing and project collaboration increasing as people discover other uses the for the wiki.

What’s intersting about this however, is that wikis are being employed mainly for internal purposes, and not for marketing and collaboration with clients (a mere 3.85% of responses indicating use for this purpose). On the one hand, given the relative newness of many wikis (remember that 47% of the 102 wiki implementations survey were under a year old) the responses may suggest that wikis and capabilities regarding their use/management are still being developed internally before being extended outside the organisation. Alternatively, given the importance of collaborations with customers, it may suggest that businesses are not in fact applying the wiki to key needs, which requires the development of capabilities so as to be better able to deliver what it is the customer wants. Integral to that is the ability communicate quickly and effectively with customers.

During the interviews I conducted, I asked Suw Charman what ‘needs’ were driving the implementations (e.g. inefficiency/ineffectiveness of existing tools, inability to locate/retain information and/or knowledge, better support for collaborative work practices, etc). She noted that “there is a difference between what businesses need and what they think they need”. She went on to indicate that due to their popular public uses (e.g. Wikipedia) businesses implement wikis to help employees find and access past/current information, instead of thinking about issues surrounding efficient work, and better collaborative, practices. Consequently, “they tend to look at the problem the wrong way around … since it is not about sharing knowledge and the introduction of a new technology per se, but about getting work done quickly and easily”. Her comments reflect the practicalities of the Rogers’ approach and the imitative selection processes that create a form of ‘pressure’ as a result of the Mimetic Isomorphic approach, which approaches may not in fact focus on the collaborative behaviours/capabilities which need to be developed and engender requisite/appropriate managerial support to do so.

In light of the reported barriers to wikis’ use (e.g. time to contribute/maintain content, reliance on email, lack of managerial support, culture, lack of clear purpose for the wiki and wiki not being integrated with other tools) it seems that reliance on the Rogers’ approach or the Mimetic Isomorphism approach is resulting in a lack of commitment to the change process integral to the adoption of this style of collaborative technology, undue reliance on voluntary adoption and insufficient support during the adoption process, and loss of opportunity to recognise why such tools like wikis are being introduced to the business and their potential to help resolve issues with existing knowledge management/work practices and develop collaborative capabilities both internally and externally. In other words, a more holistic ‘inside-out’ approach.

Having survey 102 companies, and interviewed 10 companies and 9 consultants, I compiled the following recommendations regarding the management of wikis in business:

1. For new implementations, consider the needs to be addressed/capabilities to be developed, how people currently work and changes that maybe necessary to routines/behaviours, as well as the nature of the culture, structure and other organisational subsystems, which initially will have to be worked within whilst gradual change is encouraged. For existing implementations, evaluate their impact (if any) on the foregoing factors, and who is (and is not) using wikis and why (including issues users have in respect of wikis and their work processes).

2. View the implementation as a change process and allow for planned emergence during adoption and growth/maintenance, and encourage evaluation throughout.

3. Involve a broad cross-section of people in the definition of flexible (collaboration) goals, and the consideration of how the wiki should be designed and people’s behaviour altered to (better) meet identified needs. Use those goals to guide and evaluate how well the needs are being met.

4. Consider the tasks being undertaken and the level of user competence when deciding whether some flexible structures/templates would help to avoid the wiki appearing chaotic and content being hard-to-find, as people learn how to create their own structure/maintain content.

5. Identify key ‘technical’ users (with needs corresponding to those identified) who can form pilot groups, or who can expand wiki usage to other areas/projects. Encourage experimentation to discover how the wiki can be used to best suit their needs and uncover issues with its design, integration with existing tools and/or impact on other subsystems.

6. Don’t rely solely on the self-motivation of the initial adopter groups. Develop and support good practices from the outset by supplementing self-learning with targeted training and best practice guidelines to help users understand the goals and wiki practices necessary to facilitate more effective/efficient work.

7. Recognise that later adopters may need greater support helping them understand how to use the wiki and work more collaboratively. Engage existing users in this process to grow the wiki organically. Focus on and demonstrate the uses/benefits of wikis’ use for everyday work (with knowledge collection being a by-product of wiki usage rather than an end in itself).

8. Allow people time to develop their skills with the wiki and gradually move them away from use of inefficient tools by constantly and subtly promoting its use (e.g. through moving tasks/information onto the wiki, sending people links/referring people to wiki pages and involving people in projects using wikis). However, support different communication styles and recognise that using a wiki may not be suitable in certain circumstances.

9. Encourage user delegation, and rotation of, a wiki gardening role to people within their respective communities of practice, whilst developing more dispersed habitual gardening practices amongst users.

10. Be alert to how people are using the wiki and seek feedback continuously to learn how people can best be supported in their work. Ensure that any measures used during the evaluation process are aligned with the needs which are driving the implementation. Assess/refine the implementation goals, process and wiki itself even if that means relying on soft data.