- “What will you do with that car if you actually catch it?”
— what the cat asked the dog (from the Chicago Reader, circa 1989)
The groundswell of interest in “cool tools” brings a wave of users and a burst of feed reader activity – for a few weeks. Before long, however, the organization will get some rush orders, a month-end close, a project deadline, and/or a few vacations on the team … and the same old excuses begin to weasel their way into the conversations. Folks begin to realize that collaboration and participation is more than reading (I actually have to type something into this thing?). Management styles are tested, and we find out if KM can be pushed on or pulled from the group. The questions start on a familiar note …
The classic pushback against documentation; we see no immediate value added. When I’m programming or implementing a system, I’m making stuff happen; when I’m documenting, I’m only creating files that no one reads (and some ambient white noise for my cube neighbors). Of course, if there’s only one person in the department that knows how the system works, and if they happen to be out on vacation when a problem arises, it’s all hands on deck and a general scramble to figure out how things work. Imagine your consternation when you find out it’s a five-minute fix … if only they had written something down …
There’s also the career flexibility issue; if you’re the only one that knows how something works, you’ll never be able to move to the next interesting technology – stuck maintaining the Unknown System. Unfortunately, a plea to the value of Future Flexibility doesn’t help when you’re dealing with someone who likes to maintain control over the Predictable Present. Sooner or later, the benefit of getting rid of their inflexibility far outweighs the cost of reengineering anything … it’s just delayed pain.
Another classic question (who is supposed to write this stuff? Not Me!), with a contemporary twist … the collaborative tools allow us to quickly broaden our audience/author pool, including folks outside of IT. In fact, this is a significant difference from fads gone by – non-IT folks are getting exposed to collaborative documents on publicly available, open environments like Wikipedia and Google; it’s getting easier to talk to a growing number of people about interacting in a collaborative environment; the team isn’t limited to the techies any more!
A much more important question – which platform should we use to capture this knowledge? When do you use a blog versus a discussion forum? Will I wiki, or should I SharePoint? Choosing IM over eMail is easy, but when should I tweet instead?
If you’re working on this question, it’s actually a good sign – folks have enough hands-on to understand the good and the bad about a variety of collaboration media. Experience is your best guide here; wiki’s are great for fast entry and immediate distribution, but (IMHO) it’s difficult to maintain a table of contents, index, or any multi-chapter / multipage chunk of knowledge. At home, I’m building the fifth generation of my home software development environment, and I’ve already passed over my personal wiki tool as unsatisfactory. Too many processes and interlocking technologies surrounding the servers, development environments, and push-to-production processes. It’s much easier to create an actual Administrator’s Guide (sample); a formal document with table of contents, chapters, diagrams, even page headers and footers. If I bothered to print it out, it’ll look great – but I don’t care about the paper. I like the structure that a book gives me – this is broad collection of information about a set of technologies and processes required to do one basic thing.
Each of the different Web 2.0 / KM tools has different strengths and weaknesses – flexible info structures, formatting efficiencies, ease of distribution, and support for collaboration / version control. The light will come on when you understand your biggest problem is collecting the knowledge; presentation, distribution, search, and sharing are covered nicely by the various intranet technologies, but the magic is in the making.
Doom and Gloom – and a Silver Lining
Disruptive technologies come and go, there are no silver bullets, and there’s always a problem somewhere. If the environment is user friendly, it won’t scale. If users accept the concept, they won’t have the time to create content. If you can get all of these budding authors to write prose that is readable, you’ll struggle with making it findable.
But hey – we’re trying to pull out of this “trough of disillusionment” – so focus on the things that Web 2.0 does well …
… and focus your attention on the “next version” (2.1) – practical questions of why? who? which?