How to share problem solving knowledge in a multiteam group?

Question

I've been working in multiteam groups for as long as I've been a web developer, and in my experience, a team can be a lonely soldier or several people; generally a company will have multiple teams working on different projects and once the project is out in the wild, any team can perform maintenance on it.

This is a simple example since I'm not talking only about project related knowledge, but "craft related" knowledge, but it should give you an idea of how I'm used to working:

Since we work on modularised teams, sometimes I feel like the teams are too tightly focused in their projects. I've seen cases where after an hour of discussion, the question was asked aloud and someone on a totally unrelated project suggested a much simpler solution.

The problem is difficult to solve because people tend not to be available all the time, and sometimes the person with the knowledge can't afford the time to go through a problem with the asker, but could do it themselves easily.

I've thought about software based solutions, something along the lines of SE, but I'd like to know other programmers opinions on the subject.

EDIT

I don't know if this is a problem that a wiki can solve, because I feel that wikis don't encourage the user to actually ask questions, but rather to write articles, and sometimes we don't know the knowledge we need before needing it.

Answer 1

I worked for a fast-growing startup company that went from under 100 to 500+ people in two and a half years, where the issue of knowledge sharing quickly became a problem. The company built a strategy that worked reasonably well, and included three key components:

• Documentation
• Standardization
• Internal Training

Each team was responsible for releasing documentation along with the updates to their component. Release of the code without documentation was considered incomplete. The quality of the documentation was evaluated independently by the "target audience" (i.e. the other team inside the company that used the component). Errors or omissions in the documentation were entered in the bug tracking system, and treated as first-class defects.

There was also a requirement to mention documentation when answering e-mail questions about your component. If you could not locate a piece of documentation that answers the question, the policy expected you to write one, or modify an existing document to answer the question. This practice helped us keep our internal documentation at a respectable level of quality.

The company also created a coding standards committee, which met periodically, and published updates to company-wide coding standards. These standards paid a lot of attention to using the libraries built in the company, and laid out a framework for implementing new libraries in architecturally consistent ways.

Finally, each team was responsible for publishing a set of training course materials for the rest of the company. Team leads of the teams with wide internal exposure also ran internal training courses once or twice per quarter, so if you wanted to get trained on an internal component, you could learn it hands-on straight from the source.

Ultimately, knowledge sharing is a process issue, not a technical issue. Technology can definitely help, but the process remains the primary mean of addressing the problem.

"Selling" the process can be difficult, especially to stakeholders who will need to do more work. Fortunately, knowledge sharing has a significant benefit: it increases your mobility inside the company, which is especially good when the company is growing fast. This means that you can be promoted to a team lead on a much shorter notice, or move to a different project that happens to be of more interest to you.

Answer 2

As programmers we sometimes erroneously look for technical solutions to what is fundamentally a people problem. There are always going to be inefficiencies in a large group. The best solution I'm aware of is the good old fashioned "grapevine." I ask the person I feel is best suited to answer a particular question. If he doesn't know the answer, he refers me to his "guru" on that topic, and so on. I don't think I've ever had a chain longer than three people, and nearly always it's one or two. If you have no idea who to ask, send out a group email.

The wiki comes in as a sort of FAQ. When someone gets the same question multiple times, they write a wiki article so they can refer people to it. Eventually people will start searching the wiki before they ask a question, and people will start writing wiki articles in anticipation of frequent questions. In a large enough group, chances are good that someone else either has had the same question, or your question is specific enough to require one-on-one help anyway.

Answer 3

A wiki can definitely be helpful, but it takes time to write articles that will be useful to others. In my experience, there are two ways that content gets added:

1. Someone with knowledge about a particular module or feature writes some content that they think would be useful to others.

   It's often difficult for the higher-level developer or engineer to find time in their schedule to dedicate to writing documentation, and since many don't enjoy writing documentation, they may put it off until they forget about it.

2. Someone who has required help or had to do some serious research to solve a problem documents how they solved it.

   This type of article can be very useful, in part because the user of a module might (even if they read some existing documentation) have identified some gotchas for their particular use case. They can also work very well as a sort of guide to future users, even if the use case isn't exactly the same.

I feel that an employer should encourage - and build in time to write - both types of articles, because by doing so you end up relying less on the knowledge of certain individuals.

Answer 4

We use RedMine, which integrates issue tracking, tickets, wiki and more into a nice project management web application. Though there are others of the kind of course.