[Home]WikiAdoption

MeatballWiki | RecentChanges | Random Page | Indices | Categories
"... Anyone can edit anything ..." -- from WikisForBusinessIT, draft 1

I think this statement has done a lot of harm in the past and I urge not to use it in this form in the future. It's the same as "yes, if you go into the street, anyone can shoot you". Both statements are technically correct but don't describe the normal case. We have developed cultures that reject both types of behaviour.

So maybe it should read: "Wiki users have learned which texts are meant to be changed and which are not. If you sign a contribution, no-one will touch it and in case of changes (except typo corrections) it's the job of regulars to protect the text and undo the change. But such cases are extremely rare. On the other hand, if you make e. g. a book list about topic X, wiki users will understand this as an invitation to extend the list. If you create a page, wiki users will add their opinions. Wiki culture means to understand each other and cooperate in a senseful way. It takes newcomers a while to understand and make good use of these freedoms and conventions but it's easier than most people think."

-- HelmutLeitner

"yes, if you go into the street, anyone can shoot you" Brilliant metaphor, Helmut. Whenever I explained a wiki to someone with anyone can edit anything, I had to hurry up to tell him/her that you can also protect a wiki with rights management or something like that. Anyone can edit anything scares many people, perhaps exactly the ones who are thinking about what shocking and brutal things can happen to them when they go into the street... -- BerndSchiffer

If we should meet someday, you could do anything to me, hit me, shout at me, run me down. But typically you would say "Hello" and shake hands. That's the difference between what we can do and what we have learned to do to get along and what we call culture. Wiki is about to develop a culture to be able to make best use of its freedom. Respecting signed contributions is part of this. -- HelmutLeitner

Of course we here all understand the concept. The thing to decide here is, how to explain it to somebody else without scaring them. More specifically, should we make a change to chapter 3? My feeling is it's OK. You kinda have to launch in with the shocking 'Anyone can edit' statement, in order to make sure they get the idea. This chapter presents the statement quite well. Perhaps we could add a sentence explaining that undoing becomes quite rare when a wiki community forms a kind of culture in which certain types of editing are acceptable, while other types are not, and everyone starts to feel responsibile for their actions, like in real life. -- HarryWood - 7th Mar 2005

It _is_ scary, whether you like it or not. It takes about a nanosecond for the average manager to realise from that presentation that a wiki represents a huge loss of control for them. If you pitch access controls, and audit trails, and work flows, you can excite the managers again (though of course you burn the KSP of a wiki, which is it's very egalitarianism). You have to target your audience. The above presentation will work well for a small group of peers who need to throw ideas around - for example, a dev group. It does _not_ work for the financial controller, or even some project leads. All they see is anarchy. -- CrawfordCurrie

Indeed. Throwing around vague philosophical prose about the socio-cultural-political ramifications of open editing and the evils of how managers all want this iron-fisted total control over what is produced, read, and said, doesn't really endear you to anyone. If I want to open a doc for editing by my group, that's my choice. If I want such edits to require my approval, that's my prerogative as well. I want a place to put policies and procedures in, and I don't want to hear about some exciting empowering revolution of authorship. Not only have I heard it all before, I'm not interested in getting in line for this one. Most managers are not iron-fisted tyrants, do not have pointy hair, and aren't twittering little birds that scare easily and you don't want to excite too much. They have needs to fulfill, and preferences of their own, and like everyone else, they don't like to be patronized. -- ChuckAdams

I think that OnlineCommunity and CommunityOnline are two completely different situations and we have to keep them apart. They have different problems and chances and need different arguments and configurations. Wikis are not created equal. "anyone can edit anything" may be inspiring for OnlineCommunity enthusiasts, but it's a horror for CommunityOnline people. No-one needs to justify that he wants to use wiki for his own advantage, everyone does so. Using a good wiki engine you have pretty complete control of who does what. registration, rc, diff and history are the essentials for managers. It's still as free as you want it and much more accessable than a CMS. A CMS is like a tank - completely save but no-one likes to spend time in it. A Blog is like a bike - nice, but it won't take you far. A forum is like a bus - slow, crowded and on a fixed route. A wiki is like a car: fast, comfortable, people like it and it gives them a feeling - perhaps an illusion - of freedom and democracy. Managers need to understand that new efficient forms of communication need more subtle forms of control, maybe relaxation of control - but go slow. If one wants the benefits of wiki one has to understand these systems and adapt somehow. WikiPedia is a project that makes them think. "A wiki can work wonders together with the right visions" - any manager will believe in his visions. ... That's perhaps the line of arguments that imho promises success with business. -- HelmutLeitner

Having rethought this, I think my approach was wrong. This is too technological determinist--so let's use SocialConstructivism?. The reality is we cannot change work styles with a wiki. A work style is something that comes from TheIndividual. Technology can only limit AnIndividual who does not agree with it or enable TheIndividual whose SuperordinateGoal aligns with the technology's affordances.

A wiki requires a team that already as MutualTrust? (SocialTrust??), a CommonContext, a SuperordinateGoal, shared power (DevolvePower), and a willingness to TakeResponsibility?. Those are the social values that the technology affords. In some cases a wiki can create or help instill those values through the PygmalionEffect, but this requires reinforcement through other means, particularly to highlight that these are the desired CommunityExpectations as well as to provide PositiveReinforcement? when those expectations are fulfilled (and avoid NegativeReinforcement?).

The typical successful adoption path for a wiki in a company is that some team has matured to a point where it is choking due to the lack of communications media or because their existing media is hampered by organizational controls that are meaningless in this high-functioning team (e.g. access controls). Then one EarlyAdopter? finds out about wikis and introduces one to the team, who then try it out, and it usually works out well.

Alternatively, the wiki is introduced by management as part of an overall organizational strategy to DevolvePower to employees, who then foster the high functioning environment through typical emotionally mature management techniques.

The converse case, control structures, either in code or simply in policy documents are a sign of the respective converse: a distrustful, low functioning requirement. One only needs rules if one doesn't trust the other party to the rule to behave, or one cannot tolerate mistakes. The more control structures erected, the lower the trust. The lower the trust, the more control structures are needed. I would hardly claim that this case is wrong; often control structures are needed, since many people, well, suck.

The typical failure adoption path for a wiki in a company is the TechnologicalDeterminism stance that installing the wiki will magically change the company structure. Either this is done by an AntiAuthoritarian who is attempting to neutron bomb the company's organizational structure--which leads to chaos and disaster--or by a short-sighted manager who wants to 'unleash' innovation from his or her subordinates, only to discover his subordinates are crazy, anger, mean, bitter, or otherwise put under thumb for a reason.

Wikis are not a magic bullet, but they are sold that way (such as in AnotherPlace). On the other hand, typical information systems designed by ComputerScience methodologies from industrial bureaucracy hamper the movement towards a NetworkOrganization? that we increasingly see today (and a movement that ComputerScience does not know how to cope with). -- SunirShah

Your remarks about the successful adoption path are cogent and borne out by my experience. I have not yet encountered the TechnologicalDeterminism stance in an adopter, though like you I have seen people try to sell their wikis on that basis. The most successful adoptions I have seen are those that simply streamline the existing practices of a team. As you imply, the KSP for wikis is that they are incredibly flexible; they do not impose any specific methodology on the end user. You have to get away from the scary "wikis are going to change the way you do things" pitch and align more to the "wikis can support whatever _you_ do". The NetworkOrganisation? can grow from there. Chuck, I think we are reading off the same page, just different sides. -- CrawfordCurrie

Many of the successful projects I know about started with a group of people or a leader with a goal. Many of the unsuccessful projects started with the idea of experimenting with a tool. "Hey, let's try a wiki" -- as opposed to "lets create an intranet that can be updated faster and get contribution from more more people", or "let's work together on a strategic plan", or "let's gather customer support documentation." -- AdinaLevin

I just joined a large IT project in a very large IT department, and it's knowledge management chaos here! Documents flying here there and everywhere in emails, important information getting lost in meeting minutes, docs getting out-of-date, and new people (me) assuming they are up-to-date, etc... Of course my thoughts immediately turn to wikis. I'm just itching to try and introduce this, but I am a very small cog in a very large machine.
I really like the WikisForBusinessIT article as it is, except that it is not so good for linking to because the final section is just placeholder. I'm going to change this now. But otherwise I think it's well balanced and explains the concepts well, so I plan to email a link to this, to my manager, and also to the corporate intranet suggestions box. But this will not be enough. People are too busy to pay any attention. I also need to set up a wiki, move some project documentation content into it, as a demonstration, and to kick things off.
But... maybe I should hold back. Am I being the "AntiAuthoritarian who is attempting to neutron bomb the company's organizational structure"? Any advice on how to push this organisation along a 'successful adoption path'? -- HarryWood
Update: It turned out some people already had a TwikiWiki? set up. I got them to create a new 'web' for our project, and then I set-up some demonstration content, but my manager told me to stop using the wiki because "there had been no decision" on what knowledge management system we would be using, and for the time being we will be collaborating using word documents on a shared network drive. The other thing he said was that after creating the documents, towards the end of the project, we could put them into a knowledge management system (missing the point completely!) ...*sigh* oh well. I did a bit of SeedPosting and then left the wiki to stagnate (as instructed). Just recently I noticed that a few people elsewhere in the organisation started chipping in some content. So maybe I've planted a seed after all. -- HarryWood

There is much talk here about control, but still I have some thoughts to add. Control can be excercised with differenet mechanisms each with different characteristic and any company or team or society needs to decide what mechanisms are the most efficient in particular situation. Traditional CMS coded the control in the software, but this is the most rigid way of excercising control and it does not work in many circumstances. There are other ways - you can write policy documents, you can establish best practices or other formal or informal rules, and all of those ways are much more flexible, you can change them whenever you need a change while changing the software is much more difficult. It is important that it is much more feasible to establisch some cultural rules or formal etiquette when the group of participants is closes as is the case of company employees - thus wikis are in fact much better suited for being a intra-company medium than Internet wide site. In a company you can easily discipline trolls using the standard management tools - you don't need any additional software mechanisms for that. -- ZbigniewLukasiak

Here's some interesting [comments about intranet wikis]. There's a good balance of comments, from people who have tried to set up wikis on their intranet, including some people who utterly hated it. -- HarryWood

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: