I have found in my time as an office worker that communication is the key to success. If you think about it, the majority of our job is transferring information in various ways (phone, email, document uploads, etc.) from ourselves to others. Communication is kind of the silent partner of any business, but not in the Godfather, whatsamattawithyou sort of way.
Here on my team, we specialize in communication and best practices of communication. We have a process for writing emails to people outside of our team, we have a process for developing phone calls to potential partners and students, and we even have processes for documenting and recalling communications done in the past. We always find some room to grow.
Before I started my illustrious career with CAI-U, the team created a best practices guide for everything the team did. While this tome was immensely useful, it was very static. Updates or modifications to the guide took a long time to put in place, took a lot of people’s interaction, and required approval all the way up the line.
That’s where I come in.
Not really. The team had already decided to make the best practices guide electronic before I started, and handed me the project once I got settled in. Still, I feel at least some sense of personal ownership in the outcome.
It was decided to make the best practices guide a wiki. This wasn’t a novel idea, in fact a lot of other companies (Amazon.com, Intel, Microsoft) use wikis to promote and share information exchange. After initial implementation and a few growing pains, we have an immensely powerful, useful tool to get our everyday work done faster and with more accurate outcomes. Here are some of the things I learned:
1. All information is good information:
When we first started using the wiki as a tool, we were scared of ‘losing control’. The thought was that people would enter a world of useless information and the good information would be lost in the quagmire; or that useful information would be accidentally deleted. Truth is that it’s much easier to let people feel free to share whatever information they have and trim down from there. I’m not suggesting that you let team members enter ‘best peanut butter cookie recipe’ as a wiki topic if your business is that of IT, but by promoting the open sharing of information you’ll find a world of data gathering that would be otherwise lost. Plus, at least in the wiki tool we use (this being SharePoint’s wiki ability), removing a page is as easy as a few clicks of the mouse.
2. Give your team “permission” to use the Wiki
When we first started using a Wiki it was hard work to convince the team to use it as both a reference tool and as a place to put their discoveries or information. With any new tool or idea there will be resistance, and that is ok. Just keep reminding team members (and yourself) that the Wiki is a friend.
3. Set style standards
One of the moments I am very thankful for was when Bart (my manager, for those of you who are curious) suggested that we have style standards for posting. While it seemed a bit silly to me at the start, as we developed our Wiki over the course of a year or so, the standards became essential.
Implementing a style sheet was easy; we just added it as a Wiki entry for team members to use when constructing Wiki entries:
Team members are able to just grab this text and paste it into a word document for formatting or use it in the wiki editor itself and type over it. As a result, we can easily print out a section of ten or fifteen entries and have them pretty much look like they belong together. Furthermore our collective eyes are more easily able to find information on a page (since key information is all in the same size/font/color).
4. Wikis are living
Whereas our previous document was static and inflexible, the Wiki that replaced it is amazing agile. As soon as our team learns something valuable, has gained key information, or simply needs to update, it’s done and accounted for in the span of fifteen minutes, often in the meeting where a decision or change was decided on. The wiki has become a default codex that holds all of the knowledge our team has gathered, and will continue to grow as we do.
5. Wikis become enormous
And that’s ok. Your Wiki should become much bigger than the document it replaces (if that’s what it’s doing) or bigger than what you expect. The trick of it is to make sure navigation is clear by using a home page that directs to other hubs of information, and a sidebar that allows a user to travel back to the home page or to other central “chapters” like this:
Giving a roadmap to a huge Wiki not only speeds the finding of information, but also takes the stress out of using such a valuable tool for your team. Nobody is going to use something that can’t be navigated, no matter how good it is.
6. Wikis can be more than just text
I think the coolest thing our team does is put video, outside documents, audio, and other such multimedia data into the wiki. It’s one thing to read about how to use an excel spreadsheet that Bart (sound the trumpets) comes up with, but something else to watch him go through the process and having him describe it in his own voice. You can cut down a lot of time typing up an explanation or you can create a quick, two minute or so video simply demonstrating what you mean to get across.
Also (to be perfectly honest), posting video/audio/images helps break up huge chunks of text, which helps give team members a bit of variety. So while text might be the cake mix of any good Wiki, including other media is most definitely the fudge frosting (and yes, I haven’t had lunch yet).
I’m interested to know any pointers or experiences you and your team has had with using a Wiki, any helpful tips out there?