How do your busiest people transfer their knowledge? [closed]

Question

We have recently polled our company wide wiki users and found out that there are two large groups of users:

• people with lots of knowledge but (who claim they have) no time to document
• people with time but (who claim they have) not enough knowledge worth documenting

Each group covered almost 50% of the users!

How do your companies handle this? That is, how do you encourage your busiest / most knowledgeable people to share their knowledge?

Answer 1

One thing I'd try would be to try this:

1. Pair up people in the first group with people in the second,
2. Information is exchanged within the pairs from the first group people to the second group people.
3. The people in the second group document their new found knowledge,
4. The documents are then verified by the people in the first group.
5. If there are errors, then go back to step 2.

Answer 2

How do you know the "people with lots of knowledge" have any knowledge at all, if they haven't demonstrated the knowledge by recording or presenting it? Get them to 'walk the walk' by showing that they know what they're talking about. This could be in the form of a presentation to the group, attended (and documented) by the people who claim to have the time to do so but not the knowledge.

Results:

• The people who say they know stuff can show off how much they know stuff.
• The people who say they have time to document things have something to document.
• The knowledge retained by the 'knowers' has been recorded.
• The people who didn't know enough now know something more.

Answer 3

For those without time, make the people responsible for their time allocate them time to document.

For those with time, just interview them repeatedly until you are certain 1) you have all they know or 2) they really didn't know anything. In the latter case, it might be time for management to consider what they are doing on the team.

Answer 4

The people from first group have two important things: knowledge and expertise. These should not be confused.

It is possible to transfer knowledge through wikis, specifications, source code comments etc.

It is not possible however, to transfer expertise that easily. That comes with hands-on experience. Of course that can be greatly improved by nominating people from first group as mentors for newbies (and oblige them to reserve time for that). Also you can have mixed pairs or mixed agile teams working closely together.

Answer 5

But I thought in this age of Agile that there was no need to document. Isn't the source code self documenting enough that everyone can master the application by glancing through a few source code files?

Seriously, you have what we call kingdom builders in your group. If they claim to not have time to document it's because they are protecting their turf. Plain and simple. The problem with documenting, in the eyes of kingdom builders, is that it makes them expendable. That is their fear, that's why they refuse to document. If they were truly your best and brightest then they would be relishing the opportunity to pass off the maintenance grunt work so they can work on bigger and brighter things.

Anyways, documenting your work is an expected part of any developers job and if they claim they don't have time then they aren't doing their job.

Also, if other developers can't figure out what your smart developers have done, then I would really question the quality of the work that your smart developers are doing.

Answer 6

If you are simply looking to transfer knowledge about coding techniques and best practices, one solution is code reviews. Have your ace problem solvers and anyone directly involved in a certain area of code review changes in chunks, making sure to give feedback to the author of the change. You'll find that your best people will give away a lot of their secrets trying to improve code they might be stuck maintaining or fixing a bug in some day. If you build code reviews into your schedule then everyone will have time for them.

It is also beneficial to have the guys who don't know code so well review the experts' code. Sure they won't provide feedback that is as valuable, but they will learn by reading.

Test code should be reviewed during the code review as well.

If you are looking to transfer domain knowledge about the use of the software you are writing, you may want to implement a design review. Somehow make sure some of your good people who know the domain are around to hear what your other programmers are doing. However you want to do that is up to you, and it can be done in short sessions for short iterations if you like. It will help catch misunderstandings, potentially.

Answer 7

It's certainly possible that the problem is that the people that declare themselves "too busy" are just interested in protecting their turf. But it is also be possible that these folks are under pressure to deliver code and that management hasn't prioritized the effort that it would take to put together documentation. If the sorts of things that you're hoping for people to document are going to take days of effort to pull together a document that describes a complex workflow both from a business standpoint down through the technical architecture, that's something that management is going to have to prioritize as a task for the developers (and accept that writing up documentation is going to delay other development tasks).

Answer 8

In the small group I work with we have started to keep a local wiki (using tiddly wiki) to store all of our learning's from our R&D into an area of a project.

So far this has proven to be a good way to disseminate knowledge.

Answer 9

A good technical writer on your team can be real boost for these types of things. I've had one before on a team and he was very valuable. I think he made maintenance of our project for teams afterward much easier with all the documentation he wrote. He wasn't a programmer, but he knew enough technically to put our ideas, architecture, etc. to paper.

Answer 10

This is my approach:

• you assign the task of documenting to a fresh developer,
• he tries to figure all the stuff out on his own,
• he asks knowledgeable people questions about the system,
• he writes documentation as he learns.

It has three important advantages:

• Knowledgeable people save time, as it consumes waaaay less time to explain something to another developer than to write it down in detail.
• Fresh developer has no assumptions about the system and he is more likely do describe every aspect of the system he discovers. Knowledgeable people tend to skip minor details, because they are so obvious...
• At the end you have one more knowledgeable person around.

And just one, but quite significant problem:

• Documenting systems that way takes more time than usual.

Answer 11

It's both a technical / psychological subject.

Many developers aren't use it to do any documentation, and sometimes doesn't know the apps. or techniques (U.M.L.), and some people are just introvert or non-social.

Note: It doesn't apply just to "geeks", I have met a lot of administrative people who has the "You should not be taught, You have to learn it for yourself, attitude".

Not enough time ? Make the time. Either left one or two hours in the morning for doing technical for those who know. Have schedule to organize time, and leave some free time.

Remember technical people, that teaching / sharing information with "junior" / new employees IS NOT WASTING TIME. It's investing, and eventually, those students will remove job from those who know.