That title’s not (just) a blogger’s ruse to give me the opportunity to tell you what I think the answer is. I’d really like to know how people who are busy doing interesting things make sure they share what they’ve learned with other people? How do you turn what you’ve learned into something that other people can use? Do you do a little bit regularly? Or save it all up for a big learning retreat? If you’re in a team, do you work by yourselves (‘self-learn and share’) or does someone facilitate learning sessions, and help you publish and promote what you come up with?
Is this the solution to my knowledge-sharing problem?Embed from Getty Images
I have just finished working with GDNet to help them to produce a set of end-of-phase learning publications and am starting work on a Learning and Dissemination Plan for a new four-year programme, so this is a good time for me to reflect on what I have found helps, and to scout about for inspiration from other people.
GDNet was a programme run by a small team, most of whom were based in Cairo. It aimed to increase the uptake of Southern research, mainly through an online database of Southern research and capacity building activities for Southern researchers. GDNet’s last phase of funding from DFID ended on Monday this week (June 30th) and I worked with the team in the last six months to coordinate how they documented and shared what they had learned about being a knowledge-broker and capacity-builder in and for the South. GDNet had a goal of producing and disseminating four short publications about the main areas of GDNet’s work, plus a ‘legacy document‘. We did it, on time (the last publication went online about lunchtime on the last day!) and in my utterly subjective opinion, they’re a pretty nice looking useful bunch of documents.
While I still have some residual knowledge-sharing energy left, I thought I’d reflect on what it is we did that worked and what it is important to remember to do in the future:
1) Make it important. GDNet’s logframe for 2010-2014 for DFID dedicated a whole Output area to sharing lessons learned, and learning from others. Rather than being something that was on the ‘wish list’, learning and dissemination was on a short ‘must be done list’. Anyone who has been involved in the final months of a programme knows that there is so much to do, that documenting institutional knowledge can easily be neglected. Having it built into the programme from the start is a really effective way to make sure it happens.
2) Make it measurable. Because it was an Output area, there were indicators and milestones attached which meant it was reported on and evaluated and the team could track their progress. For the future, I would add more short-term milestones as producing a publication can be a long process. An interim step, such as a blog post of early findings, for example, could help maintain motivation and momentum.
3) Use interviews for source material. Partly as an experiment, partly based on how the MK4D programme generated its lessons, I interviewed members of the GDNet team using Skype (with freeware MP3 Skype Recorder) or my laptop (with Audacity, free, excellent audio recording and editing software) for face-to-face interviews. I sent the questions in advance and suggested they read certain internal documents to refresh their memory beforehand. For two of the publications (on social media, and on capacity building), the authors used the transcripts as the starting point for their articles. Another one, which looked at two perspectives on monitoring and evaluating a Southern-focused knowledge service, two separate interviews were written up as a single feature which I think worked nicely. Tip: don’t use a headset with only one headphone when you listen to a Skype recording – you will only hear one half of the conversation and panic that your recording didn’t work!
4) Let the publication evolve. We started out with a complicated project management Gantt chart and quite fixed ideas of what the publications should cover and how long they should be. In the process of writing and editing, and getting feedback from some ‘Critical Friends’ (other members of the GDNet team, DFID, peers) who asked ‘Why? What? How?’ questions, the publications all ended up different lengths (the right ones?). We also discovered that some of the things GDNet knew about were more interesting to other people than we thought. The Capacity Building publication, for example, ended up twice the original length to include new content, especially details of the monitoring and evaluation of the workshops, which tools GDNet used and how, what worked and didn’t, etc. and the publication is all the better for it.
5) See what worked for other people. Before we started I browsed other people’s legacy documents and learning publications to pick up ideas for tools and publication designs. The Cornwall County Council Public Health Legacy Document, has a nice timeline in its introduction which prompted me to include one for GDNet. When I worked at IDS, I was introduced to the River of Life tool which I suggested the GDNet team use to help them to trace their programme’s journey and identify places where learning had happened.
6) Take lots of photos during the programme. Luckily GDNet had a stack of photos on their Flickr account which gave me a headstart in finding images for the publications. However, I wasn’t able to find all the photos I would have liked to have used. In the new programmes I am involved in, I will make sure we have photos of every member of the team ‘in action’ and look for opportunities to add images that illustrate terms and messages that are likely to come up in learning publications – anything to avoid using clipart!
I’ll end by having a go at answering my own questions, but then I’d love to know what you think.
How do people make time to share what they’ve learned with other people? Make it important, assume it will take longer than you think (it will still be less time than you expect!), make sure you have an audience for what you’re going to share before you start so you have an incentive to publish.
How do you turn what you’ve learned into something that other people can use? Do you do a little bit regularly? Or save it all up for a big learning retreat? If you’re in a team, do you ‘self-learn and share’ or does someone facilitate learning sessions, document it and send it out? I hope we managed that with GDNet, in which case the answer is to give readers enough information so they are not left with lots of questions, signpost to other sources, come up with a template that looks attractive (including a style guide), and get feedback on what you’ve produced while there’s time to improve it.
Do you do a little bit regularly? Or save it all up for a big learning retreat? If you’re in a team, do you ‘self-learn and share’ or does someone facilitate learning sessions, document it and send it out? GDNet had been taking part in reflective activities, participating in networks and disseminating its learning throughout the phase but for this last activity we produced our publications over a six month period with steady, small bursts of effort at the start and then a lot of work at the end. We used a team retreat, individual learning logs, interviews, the ‘River of Life’, analysis of internal documents, collaborative writing using Google Drive and Skype calls. I think it helped having someone coordinate the process, to keep it on-track and come up with a standard design and style for the publications. However, the team already had a culture of individual reflection, thanks to their monitoring and evaluation framework, and were used to blogging their ideas and observations as part of their regular work. This meant that they had no trouble coming up with ‘lessons learned’ when they were interviewed and were keen to get as much of their learning documented and ‘out there’ before the programme ended.