Intra-company knowledge exchange

November 20, 2009 12:08 AM

How to increase knowledge exchange in a tech company. (i.e. imitate Google)?

I work at a tech. company, and often we have redundant work. For example, someone spent a full day digging through implementing something from one API that another person knew how to do in 10 minutes. The thing is, former didn't know the latter knew about it, and the latter didn't know the former was working on it.

How do you increase the knowledge exchange within a technology company?

Are there books/resources on this?

I know Google has a lot of good strategies in this arena. Their most famous one is an excellent and open cafeteria which simply increases socialization among normally narrow developers.

Less famously, they also have heavenly snack rooms that keeps developers chatty.

Some in our company suggested wikis where people post their knowledge, but I believe that those strategies tend to fail as developers become wiki-shy.

posted by philosophistry to work & money (12 comments total)

If it's just a case of needing to find someone in a hurry who knows something, maybe set up a company chat room. People can use that to post ephemeral messages like, "I need to do X, is there anyone in the company who knows about X?" "Oh, yeah, Bob is an expert in X." "Thanks." (calls Bob) Encourage people to use the chat room for that kind of quick broadcast/reply, not for chatting. It's asynchronous so people can check it at their convenience throughout the day and it will help prevent people's inboxes from being cluttered up with broadcast questions.
posted by Jacqueline at 12:34 AM on November 20, 2009

When I worked at AOL, I was on several AOL IM bots that we used to broadcast information. It was very effective for quick comments or questions and getting people in different timezones to work together. Most of the bots only had about six or seven people on them, so I don't know how well that would scale. But setting up a Jabber/XMPP server might be one place to start, especially if you have people working remotely.
posted by Loudmax at 12:50 AM on November 20, 2009

Internal IRC is perfect for this. Companies I've worked at have had a global channel for random questions, and other channels for specific teams or language topics. It works well.
posted by cmonkey at 1:19 AM on November 20, 2009

Encourage socialization across groups, so people know who's doing what.

At the weekly meeting, save some open-mic time at the end where anyone can talk about the cool / difficult thing they're working on.

One conference I go to has a variant on this called the "Human Search Engine." Audience members queue up to ask questions of the audience. Anyone in the audience who knows the answer can call it out, or say "meet me after this session."

All sorts of obscure stuff gets solved right there. Helps to have a group with broad interests.
posted by zippy at 1:56 AM on November 20, 2009 [2 favorites]

Actually it would be interesting to try an internal version of the stackoverflow software. Anyone can license the system, which is called StackExchange for $129 a month. It might be over kill if you've got only a few users, though. It's also hosted on a shared server, rather then then your own box.
posted by delmoi at 3:43 AM on November 20, 2009 [1 favorite]

I think you're seriously underestimating the size of Google (and how many cafeterias we have :)

You're also making the mistake of looking for technical solutions to something that is fundamentally a social problem. Your engineering organization needs to make it clear to everyone that asking questions is a good thing, rather than a sign of weakness. Whenever anyone stumbles upon something that isn't obviously clear to them, they should talk to someone else about it. Not asking questions make you crappy engineer and a crappy team member.

Once people get that, they'll find ways to communicate that suits them and the environment they're in, and they'll quickly learn what channels to use depending on the issue.

(I strongly prefer a shared forum with a persistent history, because it's asynchronous, and people following the forum will remember discussions even if they didn't care about them the first time they came up, and you get a searchable history that's very useful when someone bumps into something that has happened before, but chat is better than nothing.)
posted by effbot at 4:04 AM on November 20, 2009 [2 favorites]

We do 'brown bag' presentations where people have lunch while hearing a presentation from a particular functional or technical group on their area of expertise. It helps to make 'learning outside your area of expertise' a goal that goes on performance reviews.
posted by mattholomew at 4:11 AM on November 20, 2009

You might be interested in reading about communities of practice. (Wikipedia; Book 1; Book 2).
posted by Houstonian at 4:48 AM on November 20, 2009 [1 favorite]

(I strongly prefer a shared forum with a persistent history, because it's asynchronous, and people following the forum will remember discussions even if they didn't care about them the first time they came up, and you get a searchable history that's very useful when someone bumps into something that has happened before, but chat is better than nothing.)

Like . . . askMe! I've actually seen a few questions about implementing ask.metafilter-like websites in the workplace, and I think it would be great for this.
posted by PhoBWanKenobi at 4:56 AM on November 20, 2009

Believe me, Google has more than its share of lack of communication, too. Even back when it was small. There's plenty of redundant implementation there. Some of it is a virtue; a little internal competition can yield better results.

How big is your company? As effbot says, your problem is social; technology can be an aid to solving it but it's not the solution. You need to encourage a culture of communication. Internal tech talks are one good way to do things, very formal. Encouraging random chats with snacks, meals, or beers is another. I'm skeptical of Wikis and web forums, they tend to be come fossil repositories of irrelevant information.
posted by Nelson at 7:17 AM on November 20, 2009

Some things I've seen that worked (to some degree):

Online text-searchable repository of all code. Ours also includes some databases of emails/conversations/documentation folders, etc. If I have a question about X, I can search the existing code base to find relevant samples, or find things close enough and look to see who coded it, then go ask them about it.

Weekly staff status meetings. Very short, but they let everyone know what everyone else is working on, which often inspires someone to jump in: I've got some code that will solve that for you. We give time at the end to let people discuss specific issues they are having and ask if someone has some code or experience to help.

Regularly scheduled brown bag sessions. Mostly these worked better if more experienced employees presented stuff to lesser-experienced ones in the same functional area. Not so great across areas. Works better if there is a set agenda or an advance list of questions to be discussed. Also draws more attendance if the lunch is provided by the company.

Our department made a formal SME (subject matter expert) List. We came up with a list of things that people might know about, then had everyone rate themselves in each area. Contained both technical skills and functional knowledge about the application. Posted that on the intranet wiki; tried to update it every 6-12 months.

Some things that don't really work, unless you have the right people:

Document repositories/wikis. Nobody I know wants to take the time to write up what they just did and post it. Except me. I love doing that. This works great if you've got people who will take the time to do it, but even when we put this on each person's annual review checklist it still didn't get done very much. There was usually some documentation out there, but often it was old or incomplete - the effort to maintain it was just as hard as getting it created in the first place.

We've tried to have someone take notes during the unstructured brown bag sessions and save those notes, but often the sessions were more haphazard ("let's look at some data and I'll show you what I looked at to fix it") and jumped around so much, the notes weren't very useful.

Not sure if assigning an intern or admin assistant to create/revise documentation would work. Interview the SME, type up what you got out of it. have the SME review it and offer changes. I don't know if this would actually work, but it was one of the most common laments from people who didn't want to document - if they would give me a secretary...
posted by CathyG at 7:57 AM on November 20, 2009 [1 favorite]

Try a social networking tool like Yammer or Chatter (from Salesforce). They're essentailly private Twitter systems (without the length restriction). We use one of these where I work, and it has been remarkable in breaking down barriers between groups. It's like the 'Human Search Engine' mentioned above, but active 24 hours a day. Throw out a question to the group and you can quickly reach people that you'd never normally be able to talk to directly through the usual 'chain of command'.
posted by Gortuk at 3:15 PM on November 20, 2009