Thanks for the clarifications.

I will admit I used strong language but it was based on some frustration. Let me tell you about our experience with wikis

We use a wiki within our company, but the first people to adopt it were HR and Marketing — they needed a tool to help them get organized in specific plans. From their success, Engineering and ITCOMM have automatically shifted to the tools. I would say our adoption has been smooth.

The road we took was to first identify areas of inefficiency in our work, and find tools that explicitly allowed us to gain in those areas without adding additional overheads and inefficiency. That is a straightforward approach that most operations consultants would take.

Now the important thing is that this is an implementation of a continual improvement process — the goal given to everyone is to improve their ops, and they themselves find a model that works for them. That is one of the reasons Wikis work for us, because they gave everyone a bottoms-up approach to modifying the wiki around their specific workflows.

In the end, they have vested interest in getting together to use the Wiki. What’s more, all we have had to do is constantly explore new ways of adjusting work models around wikis with the goal of improving the functions’ throughput.

So for us, people either “get it”, or “dont get it”, and if not, we just start doing Thought Experiments and workflow efficiency analysis with them.

For ITCOMM and Engineering, the shift is usually more straightforward — often because most good engineers are also well organized in my observation.

OK, so all that background aside, I will also admit that we still face some snags on our adoption roadmap — there are people who do not contribute as often, or do not follow the teams’ conventions or structure.

So I went to wikipatterns quite like you are hoping — to find answers to our adoption challenges.

To be honest, I spent 2 hours on it and all it did was give me a migrane. Even back in the hayday when I was designing satellite base-stations I didn’t see anything so technical as those patterns.

So obvious question is — why should I have to resort to drawing out a map of fairies and trolls or character profiles on a whiteboard before I can start getting enough clues to understand how to fix adoption issues?

If I am trying to find a human solution to a human problem, why start with patterns and character profiles to begin with?

I argue that in most of my consulting career I have not yet seen any technical people that have an influence in the day-to-day workflows of other functions. The only thing they can perhaps to do is Internal Marketing of Wikis (i.e. raise awareness).

However, the adoption decision for each department — in fact, each person — is based on understanding the benefit to me from using it.

So I argue that you should definitely look to your adoption patterns with a “sales oriented focus”. Call it post-deployment sales of the benefits of wikis to internal teams.

I also argue that even technical people will have a hard time actually adapting the Patterns to their specific situation. Even if there has been some good work done in identifying “Patterns” of behaviour, they should only be consumed by academic interests such as the study of social behaviour in the enterprise. I have my doubts that these patterns — atleast as they are — can be much useful.

There is no doubt that we need a “best practices for adoption” guide for wikis, but this is just the wrong approach. As I went there, if your customers are going to that website as a means of finding after-sales support, then they might just end up thinking “This company has no idea what my problems are”.

I am glad to know that you guys are working on a “marketing” version, but all I am arguing is that we need a “human” version first.

Don’t sell me on wikis, just help me understand them in language that I relate to… You are, after all, the person that introduced me (the average consumer) to it.

Customers have been asking for _ever_ for us to come up with some kind of “best practices” document for wiki adoption. We get a lot of feedback from people saying “I get wikis. I convinced my company to buy Confluence, my team use the wiki, but I can’t seem to get anyone else to play”.

Meanwhile, we had a bunch of material sitting around stagnating that Mike Cannon-Brookes gathered during his “Patterns of Wiki Adoption” session at RecentChangesCamp 2006. It seems dumb to sit on all that useful material because it may not be ‘commercially friendly’.

A common pattern of adoption that we see of Confluence is that it gets installed by technical people, and then spreads virally to the rest of the company. Providing those technical people with a tool that _speaks to them_, and that gives them good techniques to set up a wiki that both they want to use, and that everyone else will want to use, isn’t such a bad idea.

You use all sorts of strong language in this post: “force it down people’s throats”, “forcing people to constrain themselves”, “force them to think one certain way” that we’re simply not doing. We’re offering people in a situation we know is common a box of tools that might help them.

Wikipatterns isn’t a sales tool for Confluence. I doubt we’ll ever point anyone who’s not sure whether they want a wiki or not to wikipatterns. We are, in parallel, coming up with marketing materials for those folks showing the various ways in which a wiki can help different kinds of teams or companies. Wikipatterns was just ready first.