Teams that are geographically distributed and primarily work virtually face many challenges. One of them is sharing knowledge. I am part of an organization which has a team in Denmark responsible for development of the platform we support, while a team in India is responsible for the maintenance. This means that whenever we implement something we new, we have to hand it over to our colleagues in India such that they can handle error reports etc.
We have so far addressed this knowledge sharing in the way we have always done with colleagues on site: Sitting down with each other and working on specific tasks together. This works when the Indians get a chance to come on site. When not, we have to do it via virtual meetings. And this does not work very well. It usually turns out with us going through applications and programs for an hour or two with hardly any questions asked from the participants. And at the end you have no way of knowing if they have understood anything. We have to wait for the error reports to come in before we find out before we often realize that we have to start more or less over again. It is also quite boring for everyone involved. This approach is neither effective, nor efficient. So I decided that it was time to find a better way to handle this knowledge transfer.
Framework for knowledge sharing
The first thing I did was to ask myself: Which experiences and what knowledge do we in the Danish team have to draw on to improve? Well, we know to train end users, and we do it quite well. Within this area we have experience as well as theoretical knowledge. So the first step was to change my mindset from "knowledge sharing" to "training". When training users we routinely define learning objectives and create exercises, and we take regular breaks. We do these things because that is what experts recommend. So I sketched out a framework containing the following
My team decided to test this framework when we implemented a number of improvements in a particular area of the platform we support.
Learning objectives
Learning objectives basically state what the participant can expect to have learned by the end of the module - much can be read about that elsewhere. Defining the learning objectives provided a tool for breaking down the whole area into smaller, more focused modules. With a stronger focus it was also very easy to define the target group for the individual module. Taking the media into consideration, I set up the rule that it must be possible to cover the learning objectives for each module within 30-45 minutes. The first module contained a general introduction of the changes implemented as well as a brief walk though of the exercises. Then followed the individual modules, and in the last session the Indian team presented the answers to the exercises.
Exercises
We didn't create exercises for each module but for the whole topic covered by all the sessions. The difficult part is to create actual exercises, and not simply quiz questions. Quiz questions are good for establishing context and basic concepts but the purpose of the exercises is to encourage our colleagues to take a look at the actual process, code or whatever is being handed over. For example:
-
If you update information in one particular screen, where will that data be available?
-
How many rows with certain characteristics does a specific table contain?
We presented the exercises together with a general introduction in order to emphasize that this was a tool to help them learn, not for checking up on them. Just like when training users. Also, we didn't want the Indian team members to feel that they had been ambushed. We left it up to the Indian themselves to decide how to do the exercises as a team, not requiring responses in writing from each individual team member. They were however asked to appoint a person, who could ensure that the exercises were done, and answer orally on the follow up session. We didn't want to interfere with how they solved the exercises for two reasons, both based in the cultural context.
First of all, we do not have full insight into the way the Indian team works internally, or how tasks are distributed on a day-to-day basis. Therefore, we thought it was better to leave it up to them. I believe this will be an issue when working with people from different cultures so I would make the same choice again, regardless of the cultural background of the team I was working with.
Second of all, there is my own team's cultural context. For us, "test" has a negative connotation, and we couldn't dream of testing our peers - that would be demeaning. So I deliberately talk about "exercises" and not "tests". For that reason we would also feel uncomfortable asking for individual responses for us to rate and correct. Your culture might be different but it would never work for us.
Performing the knowledge transfer
We performed the knowledge transfer sessions themselves in much the same way that we have previously done. That is, based on power-points and a few demos - only shorter and more focused. On the last sessions we handed over the initiative to the Indian team, who presented the result of the exercises. They did not get everything 100% right - also partly due to minor misunderstandings - but that was okay. Then we discussed how to solve the exercise, and repeated a few things. This session worked well as a wrap up of the topic as a whole.
Acknowledging the effort
After completing all the modules with a satisfactory result I considered how to acknowledge the effort of the Indian team. I have noticed how I get e-mails from them when I have done something they appreciate, pointing that out with my manager cc. So I did the same, letting both my manager and their know that it had gone well. If we had done this with a Danish team, this act would have been considered weird, so consider how you want to address this depending on who you work with. Often when working in distributed teams you have several cultures represented, and I believe it is worth a thought.
Evaluation
Both the Danish and the Indian team considered this framework to be an improvement in the way we share knowledge. The Indian team really appreciated the shorter sessions and also liked the exercises. The Danish team thought that the exercises brought more dialogue into the sessions because they helped focus the attention of the participants and forced them to ask questions if they were to complete the exercises. I expected that it would be time consuming to write the exercises, and that the others in the team would think that it was silly. In theory it is a good idea, so I was courageous enough to try it out. Once we sat down and got started it was easier than I thought - everyone was enthusiastic about it and we could have made a lot more exercises.
So the conclusion is that this framework has resulted in a better experience for both the people handing over and the people receiving knowledge, and we will continue to work with this and improve it. However, this framework is designed for situations where you have to hand over something that has been completed and is static. The daily communication and knowledge sharing about ongoing tasks that you work on together remains a challenge.
Author: Line Karkov has a Master of Science in Information Technology from Aarhus University, Denmark. Since 2007 she has been employed as a business analyst in the internal development department of a Northern European group within the banking industry.