This is from guest author Camille Goksever. She is an amenable risk taker and an entrepreneur at heart. She has run the gamet from working for Fortune 500 companies to Start-Ups, and from owning her own restaurant in the San Francisco Bay Area to a wine exporting business in Istanbul, Turkey. Wikis were a central focus in her businesses, and continue to be in her second life as an independent Wiki consultant for Chevron. With seven more lives to go, she’s anxious to ingrain social computing as a better way of doing business.

Camille will be speaking about her work at Chevron at the WikiFest Symposium, part of WikiSym 2008 in September.

When Chevron’s Richmond Refinery decided to implement a wiki for their Design Engineering team I was giddy. Not only because I was going to be the lucky one to undertake this endeavor, but because I knew that the refinery had no idea what they were getting into (bring on the culture shock!). I had used wikis in my previous businesses, so I knew how wikidly powerful this technology was. People at the refinery had never heard of, nor seen, a wiki. (Well, other than Wikipedia, but does that really count?) From the get go, I knew this would be a unique experience for all involved.

I’ve managed software deployment projects, but never a wiki, so I had plenty of homework to do. I read, and read, and read some more. Many paths led me to Stewart Mader.  Wikipatterns, the book and the website, became an indispensable resource.  I attended talks and seminars about wikis.  I spoke with people I knew at other big companies about their wikis. I became wikified for the enterprise.

Pulling the first core team members together was relatively easy. I sent a select few people a meeting invite entitled, “Wanna do a Wiki?”, and they came beating down my cube wall. Well…okay, not exactly. It was more like the big boss said, “You’re lucky. You’ve been selected to participate in a special project…so show up for this meeting.” The response was, “Great! Yay! I can’t wait.” <groan>

Needless to say, getting going was slow. People weren’t engaged. For some it was their workload that inhibited them, and for others, quite honestly, I think it was their age. I’m sure most of you know…age does things to you. In addition to losing flexibility in your joints, you lose flexibility in your ways.

Of the thirteen team members, only six to eight of them were pulling the wiki weight. The early meetings dealt with brainstorming engaging topics, such as refinery engineering guidelines. We would then organize those topics into a logical hierarchy. Security was a hot button. If we wanted to “lock” pages, could we do it? The idea of anyone editing a website at anytime was a jarring concept for some on the team. The young guns argued for complete openness – or no locking of pages. The more senior refinery folk liked the command and control way – or “lock ‘em up”. I’m a young gun (so I like to think), thus the latter was a wiki anti-pattern to me. “It’s just not the wiki way,” became my mantra about command and control.

Once we had our topics nicely organized, the genuine building of the wiki began. (Or what Stewart affectionately likes to refer to as: The Barn Raising Sessions.) To be completely honest, the first two sessions I felt like I was hauling a pack of elephants through the desert using a tricycle. People would slowly show up to the meeting, then slowly log onto the computer, then slowly pull up the wiki…then <pause>. Then they would chit chat with someone for awhile. Then they would slowly go to their area of expertise, then <pause>. Then….*peck*…<pause>….*peck* *peck*….<longer pause>….*peck*…until…a…sentence…was….finally……complete. Then they would strike up another conversation. And on it went like this.

The elephants, I found, tended to be the more senior folk and were weary of new tools.  Many of them weren’t shy about letting me know this ‘wiki thing’ is likely to end up in the tool graveyard, where many new and trendy technical solutions ended up over the years.  “How is this wiki thing any different?”, one fellow asked.  I was caught off guard.  “Well”, I said, “those other tools didn’t allow you to freely express yourself to share the valuable knowledge you carry around in your head.”  I’m assuming that sold him, because he added a decent section on Drafting Procedures during that session.

I don’t think all the elephants suffered from new-tool-phobia.  A decent percentage of them suffered from work overload, and the wiki was yet another task in their crazy day.  I felt bad, so I volunteered my services to wikify any documents they felt were important to share. 

Granted not everyone was an elephant. We did have a few Mozarts - team members who had full compositions in their head note-perfect. When they sat down to type…it was music to my ears. They were fast and furious. I was proud of them.  And oddly enough, collaboration was more natural for the Mozart type. They sought input and welcomed edits. They inherently understood that it was the wisdom of the crowd that would turn their original scores into masterpieces.  Experiencing this first-hand made me realize the profound positive impact wikis can have on organizations, especially those mired with tradition, such as Chevron.

But my challenge was…how do I train elephants to play like Mozart?

To be continued…

Related Posts:

• Wanna See My Wiki? The Chevron Story Continues
• “Every single thing that we came out with that was really great, I’d never once done that thing in my life.”
• JotSpot introduces three new wiki applications: To-Do List, Group Directory, and Forum
• Why more meetings should be like a Macworld keynote, and how a wiki can help
• News Corporation, Dow Jones and wiki use in corporate boardrooms?