How do you start Knowledge Transfer? [closed]

Question

Do you use a formal event to get people talking in your IT department? Like a monthly meetup in a social place, a internal wiki/chat space or just a regular "information market" with some presentations about technology or projects made by your staff for your staff? Do you invite Sales people to participate or is it a closed event for programmers only?

How do you get people to participate in these events? Do you allow them to spent work time on knowledge transfer? Or do you understand it as an integral part of the work time?

I wonder how to monitor the progress of knowledge transfer itself. How do you spot critical one-person spots of failure in your projects? There are several methods to avoid it, like staff swapping or the "fifo" attempt on bug fixing.

Note: Ok, this is a very very noisy question and I hope to fix it after a few comments. Sorry for the mixup.

edit: My personal experience is that there is a very high barrier for people to start contributing. It looks like they won't put in the (minimal) extra time to edit our wiki, or spend the hour in the afternoon to talk about technology topics with the developing staff. It's like people don't like our wiki, our document management system or the meeting. Maybe it's because it's all free-to-use and not forced by the management. But I don't like to force people into it - but is it the right way?

One example: Our wiki holds pages about projects, telling who worked on it to get a first contact in case of questions. But nobody besides a colleague and me is creating this pages...

Cogwheel

I'd like you to clarify the context of your question, e.g., what is your personal experience with regards to inefficient knowledge transfer? Maybe that can help us answer you. :) – Celenacelene

Answer 1

Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?

The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.

This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge-base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.

Coburn

The first paragaraph is the most-heard issue here too. It's like people won't talk about the knowledge because they feel frightened by "loosing" it. This is definitly the most mind-changing thing you are faced when you try to establish knowledge transfer... – Cogwheel

My way to change the current way is to talk a lot about the wiki and the way you can just write your notes down and search for them later... I think it's true that you have to constantly remind people about the benefits. – Cogwheel

Answer 2

I think all of the above. But you're forgetting the most important way.

The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.

Robet

Answer 3

I think it depends on the knowledge you are trying to transfer. I've found the following:

Technical Knowledge: "How to guide" with screenshots and a short demo - similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.

Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.

Soft Skills (people skills): social meetings/outings/informal events etc.

Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.

Mauro

Filet

Answer 4

At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co-worker.

Flourishing

Answer 5

One word: Lunch

Barbabas

Not applicable in a project based environment with flexible work hours and small teams. You won't ever meet someone who's not in your team when you're having lunch here... the kitchen isn't for rumours here. :-( – Cogwheel

Answer 6

You should encourage people about things that you want them to do. You should "feed the animal". Look at stackoverflow; what do you think about badges? Why do you think this wonderful things exist? Thanks to ego, there is nothing you can't get it done. Give them badges, real badges, wearable badges. They will wear with happiness, they will do with happiness.

Btw, yes, I am a boss :)

Secretariat

Answer 7

Although i am still a student, when i did work experience 12 months ago, the all IT departments from within the corporation (I was 'working' for large corporation which own several mines in the area) would have a daily telephone conference, where each employee would say what they had been doing etc, and then talk about something new they had discovered and any other interesting tid-bits.

Carriole

ugh - that sounds like a real time sinkhole – Statvolt

Actually, I found it quite productive. They wouldn't really go for longer than 15 mins – Carriole

Answer 8

Couple ways I have seen so far:

• Wiki is suitable for internal knowledge, for example environment, project specific topics.

• Open doors policy

• Encourage asking questions.

• Voluntary presentations. Find out who have special knowledge and make it easy and attractive to set up a short presentation about it.

• Project post mortem documents. A wrap up meeting moderated by someone outside project team held after project is finished or terminated.

• Compulsory presentations.

  • Project presentation when they go live. Technologies used etc.
  • In case someone is sent to conference, he should have a presentation about new technology he saw.

Explosion