A lot of what I’m working on lately involves the best process to accomplish something, which can mean a lot of step by step logic. Often when working on such docs I end up having to repeatedly reorganize them as I realize during the writing that I hadn’t entirely thought out what came before what (the structure of this sentence is a living example of my not having an entirely linear mind).

I’m not a strict outliner for shorter-than-book documents, but I found a kind of middle ground that helps me organize my thoughts without feeling bound into a rigid outline format: rough flowcharting. Somehow it feels more fluid to me than outlining even though I suspect most outlining tools have most of the same features as the charting tools I use. Maybe it’s a visual thinker thing.

In the world of Macs, Omnigraffle is a great tool to just rapidly throw together a step by step chart. I probably underutilize it and there are some features I haven’t figured out–for someone who writes I am ironically also someone who fiddles first and looks at docs when I give up, most of the time–but the ability to just make a series of linked boxes with step explanations, move them around and relink if I need to, etc., seriously comes in handy. Even better, when I’m done, I can clean up the chart and make a more official-looking flowchart out of it to include with the document.

In my wanderings about the Web, I encountered Luis Suarez’s thoughts on an article discussing IBM’s rethinking of knowledge management. In part, the Knowledge Sharing issue makes me think of internal corporate wikis, where people tend to put things up according to the mythical beast named, “When I have the time,” and whose pages can often become out of date, forgotten, and not maintained. However, at times I have thought that part of this problem is the nature of the wiki itself.

As someone who’s spent a good portion of her life mastering word processors and being able to use them to get things to look exactly as she wants them, I tend to find wikis to be a rather cumbersome and frustrating experience. I’m a technical person by nature, so it’s not that I don’t understand how to use them, but by definition wikis seem to be very bare bones and don’t even have some of the useful formatting features that even most blog-posting software has. Trying to get a non-technical person to utilize a wiki can be a frustrating experience, which tends to in a lot of ways sabotage the wiki’s usefulness if you want everyone to add to it.

Perhaps we’re entering the next step of evolution of the wiki, where it steps up from a raw format-coding platform to something more usable for the broader population and less self-facing (where much of what’s on a wiki is links to other locations on the wiki). IBM’s approach sounds much more blended, taking features from various social networking mechanisms and putting them together to make them more powerful and useful than they are separately. Hopefully more useful as well.

Ultimately, this Knowledge Sharing approach can only work well if it’s well-integrated into the daily work process to encourage adding to it, and its components share amongst themselves so that when you’re looking for something that you’re sure someone in the company knows, you can find it no matter where you start looking from. I suppose a certain level, then, of “knowledge management” would have to remain, though it might morph more into knowledge organization, a specialist who focuses on finding the best tools, guiding their integration, and watching how people use them and seeing how to enhance them.

Just a ramble inspired by an interesting set of posts. Ultimately, anything that increases communication effectiveness is IMO a good thing.

Part of my focus as Knowledge Manager at Splunk is capturing best practices, particularly the best practices around using Splunk. Gathering this information is a lot like researching a story, getting me to draw on:

• My own knowledge of how to use Splunk (hey, I’m not a guru but I have been using it for over a year now)
• Our sales engineers who encounter what customers want to do in the field
• Folks in support who hear a lot about what aspects of Splunk might be confusing, along with what folks are trying to do with it
• Our developers, who can give me those sweet little tips and tricks that I can share to help people do things more efficiently
• The folks in professional services, who definitely encounter what customers are doing in the field.
• Doc writers, who spend a lot of time explaining the nitty gritty of things and can often have some pretty interesting tips.
• And really anyone else in the company who might have something interesting to share.

If you get the feeling that it really means talking to everyone at Splunk, it practically does. Knowledge Management, after all, basically involves pulling all of our internal expertise out and putting it into a central form where it’s useful to us and to our users.

The fun part of this, to me, is that it’s resulting in a huge pile of really interesting documents. (Yes, I said fun.) Most of these are technical how-tos and best practices writeups as I look into not only how to do things, but the best/most efficient ways to do things. I look forward to publicly sharing the first set of these sometime in the next month. In the meantime, if you have any thoughts, tips, tricks, or questions, feel free to toss them my way or share them on our forums.

Update 22 April 2008: As of Leopard 10.5, you can use the dot_clean utility to get rid of these files!

When building Splunk applications, I’m often working on a Mac. There are files that begin with ._ that are resource files, which contain extended attribute information about the files for the OS. This is great and all but I don’t want to include these files when I package up an application and upload it to SplunkBase.

If you don’t have deep OSX knowledge, then keeping these files out of your tarball is harder than it looks. One of our OSX gurus pointed me toward the answer, and I was so excited (yes, I am a geek) that I just had to share.

To build a tarball in Leopard that doesn’t contain the ._ files, use:

COPYFILE_DISABLE=true tar cvzf filename.tar.gz dirtotar

In Tiger, use:

COPY_EXTENDED_ATTRIBUTES_DISABLE=true tar czvf filename.tar.gz dirtotar

This is definitely going in my .bashrc so I don’t have to fuss with it again:

export COPYFILE_DISABLE=true

Knowledge management is one of those strange terms that sounds like it was made up to make someone’s job sound more important than it is. However, the task of the knowledge manager is no small one: “capture” the knowledge within a company, whether across the board or in a vertical section such as human resources or technology usage. This process is multi-step, as you have to get a feeling for what there is to learn, who to go to in order to learn it, and then get it all down in ways that people can find and make use of.

In my case, I capture best practices in using the Splunk product to accomplish key tasks. Since I’m surrounded by experts in various aspects of using Splunk at work, this task involves a bit of mind-melding so I can learn and understand cool things that other Splunkers have discovered and then put them down in a way our users can follow. I’m sure that many users out there who have come up with some pretty interesting ways to efficiently utilize Splunk for their own purposes. If you’re one of them, I’d love to hear what you’re up to!