I spoke about Enterprise 2.0 at the Collaborative Technologies Conference last week, and had a great experience. The most interesting part of the session (for me) was kicked off by Rod Boothby, who said that his clients were asking him whether they should implement blogs or wikis for internal use.
I initially responded that there was really no need to make this choice. After all, why wouldn’t a company truly interested in Enterprise 2.0 do both? As the room kept talking about the issue, though, I came to see that it was a legitimate decision point, and one that opened up a really interesting question.
The decision between corporate blogs and wikis is most obviously one between individual and group authorship. But it’s also one about policy as enforced by technology. The policy in this case is whether person A has the right to change person B’s contribution. Such a change is impossible with standard blogs, and is the default with standard wikis. If a company implements blogs alone, therefore, it has a different set of collaboration policies than if it implements wikis alone, or if it implements both technologies.
Some wiki enthusiasts I’ve talked to are adamant that the technology should remain a blank slate — a completely freeform collaboration environment. The only ‘rule’ is complete equality: anyone who can see the content can edit the content, any edit can itself be edited by anyone, and any edit can also be undone (or re-done) by anyone. As I’ve discussed before, while this sounds like a recipe for anarchy it’s actually often a path to emergence.
The meritocrat in me adores this aspect of wikis, but as an observer of how organizations actually get work done I wonder if it’s going to be the right answer in the longer term.
Sometimes technologists and/or business leaders impose structure on collaborations out of a reflexive and misguided desire for control. But sometimes they do so because the work being done actually benefits from a bit of structure, even if it’s a lot less formal than a complete ERP-embedded business process such as taking a customer’s order and shipping it from inventory.
Bug tracking is a good example. Coders use pretty sophisticated, and pretty structured, software to keep track of bugs as they crop up, to assign responsibility for them, and to clear them when they’re resolved. And coders have also become pretty heavy wiki users in a lot of companies because wikis are great tools for bringing a lot of minds to bear on a thorny problem (as Eric Raymond said, "given enough eyeballs all bugs are shallow." ).
So should wiki software for coders include bug tracking functionality? If it did, programmers wouldn’t have to use two separate collaboration tools — one to report on bugs and one to collectively solve them.
This might not sound like a big deal and maybe it’s not, but collaboration tools can proliferate quite quickly. I currently use email, IM, a calendaring program, a blogging engine, and a bunch of wikis. It’s not possible for me to search or tag across all of them, there’s no good way to interlink their content, and I’ve had to get familiar with several user interfaces and command sets.
I think of all of these as tools to help me communicate and collaborate, and I don’t perceive any of them as imposing a lot of structure on me. It would be beneficial to me if at least some of them were rolled into one platform. And it would be beneficial for HBS as well, because fewer walled gardens means more emergence.
But this rollup of tools would mean that completely freeform and generic tools — blogs, wikis, email — would be combined with a group calendaring tool that did only a couple things and did them in a pretty structured way. Most people, even diehard advocates of unstructured collaboration, probably wouldn’t have a problem with this. But what if the collaboration environment also included some or all of the following?:
- A way to rate contributors, similar to eBay ratings or Slashdot karma
- The ability to conduct polls or collect votes
- ‘Official’ to-do lists kept and cleared by the project manager, boss, team lead, etc. In other words, organization-level bug tracking.
- Approve-then-publish functionality that gave someone the authority to review collaboratively-generated content, then publish it to the Intranet, Internet, PR department, etc.
None of these sound fascist on their own, and even when combined they don’t feel like they’d take all the life out of Enterprise 2.0. But they would make the online collaboration environment less than totally freeform.
The interesting trick for technology adopters, and for technology vendors who want to sell to them, will be figuring out the appropriate types and amounts of structure to include within platforms for unstructured collaboration. I’m pretty sure the final form will be less than completely freeform, but (I hope) not too much less.