Tuesday, 17 January 2017
Monday, 9 January 2017
Last week I took part in the Cambridge Libraries Conference 2017 where I sat on a panel discussing failure. This is something we don't discuss enough as a profession, probably because it's always a little embarrassing to admit that you've failed at something, but I think it's an important topic to cover.
It's inevitable that you will fail at something at some point in your career, whether this be a job application, project or an interview. If you don't then I would seriously begin to question what has been going on behind the scenes! With this in mind it's only sensible to prepare for it so you can deal with it when it comes. This is particularly true if you are dealing with professional failure. People have long memories and if you handle things badly it could reflect poorly on you for some time and damage future chances.
I was tasked with talking about failure in job interviews. Given my struggles to get a full time job I thought I was quite qualified to take part! I've applied for multiple jobs across Cambridge libraries over the last few years (including jobs that I was already doing on a temporary or part time basis). For one role I applied seven times before I was finally successful! I learnt a lot about applications, interviews and rejections over the course of this process. Below are some of the points I raised and I hope the tips will be helpful.
- It's normal and completely acceptable to feel rubbish if you don't get the job you apply for. If you're not a bit upset then this tells you something about how much you really wanted the job. It's important to acknowledge these feelings and self-medicate with chocolate/wine/Netflix as appropriate. What you mustn't do is allow this part to drag on too long and take over.
- Think about it this way - failure is a by-product of innovation and trying new things. This is something that I heard at IFLA and it's stuck with me. New professionals and those who are really active in the profession are likely to fail more as they get involved in more things and there is nothing wrong with this - it's just about experimenting and finding things out. What your mother told you was true - how do you know you don't like something until you've tried it?
- When you get rejected for a job it's a good idea to ask for feedback. It takes guts as no one really likes having their failures discussed face to face but it's worth doing as you can find out how to improve for the next time. You might even find out that you were the second choice for the role. Whether that makes you feel better or worse is open to interpretation...
- Turn failure into a learning opportunity. If you get the feedback that you lack a particular skill then you know what to work on for next time. Was your interview or application bad? Then try to develop these skills. A lot of this is just trial and error and you will get to grips with it over time. Try getting hold of the job specification for your dream role and develop the skills they are looking for. That way when it comes along you will be prepared.
- Learn to move on. Sometimes no matter what you do there is someone more qualified who will get the job. Does this hurt - yes. Can you do much about it - no. So move on. One of my biggest professional regrets is not moving on from that role I applied for seven times sooner. I got so fixated on trying to prove to myself and others that I could get the job that I ignored other opportunities trying to get a job that I was almost done with it as soon as I got it. It all worked out well in the end but sometimes I think I could have saved myself a lot of heartache.
This is just one experience and point of view of failure. If anyone has any other experiences they would like to share then please let me know in the comments section. If nothing else we can all have a group hug and commiserate together!
Thursday, 5 January 2017
Today I'm taking part in the annual Cambridge Libraries Conference - Are You a Library Superhero? As well as taking part in a panel discussion on professional failures (more to follow in another blogpost) I'm presenting a poster about the Research Support Ambassador Programme. This initiative is aimed at improving the scholarly communication literacy of library staff and equipping them with the skills needed to work in the 21st century academic library.
A copy of the poster can be found below:
A copy of the poster can be found below:
Hopefully there will be more publicity for the Programme in the near future but for now the poster provides general information. I had great fun leading the Programme last year and almost as much fun making a comic book poster to fit in with the superhero theme of the conference. I'm really looking forward to seeing where we can take the Programme in 2017!
Wednesday, 4 January 2017
A large part of my role involves managing the Research Support Ambassador Programme at Cambridge University. This Programme encourages interested staff to learn more about the research process and receive specialist training to enable them to provide a high standard of research support to library users. In addition to taking classes Ambassadors have the chance to work on a group project in order to produce training materials which can be used by librarians across Cambridge.
In 2016 one of the three Ambassador project groups (Eleanor Barker, Joyce Heckman and Kirsten Lamb) worked on a project to produce a presentation and teaching activity that could be used to explain metadata and came up with the brilliant idea to use Lego. The following guest post contains contributions from Kirsten Lamb (a Research Ambassador) on creating the activity and Rosie Higman (Research Data Advisor) on how it has been used in practice.
As part of the Research Ambassadors programme 2016, Joyce Heckman, Kirsten Lamb and Eleanor Barker came up with a presentation and an activity to help teach researchers about metadata. For the activity portion they settled on the idea of describing the characteristics of an object to illustrate the difference between data and metadata. Since both are (often) abstract, making the “data” a physical object and writing “metadata” to describe it seemed like a good way to simplify the idea, and the simpler the object the easier to delve into the idea that there are many different ways to describe the same thing.
The humble Lego brick popped into their heads first, thanks to Lego Serious Play sessions forging the connection between abstract concepts and the brightly coloured plastic bricks. The other useful thing about a brick is that it can represent different things to different disciplines. In social science it might be an interview or a single answer from an interview, questionnaire, etc. In biological science it may be an experimental result. In maths it may be a single number in a complex series. In history it may be a photograph of an event or the GDP of Denmark in 1829.
Once you have established the conceit that a Lego brick represents one unit of data, you can explore other characteristics and types of metadata. After participants have described the brick in as many ways as possible, the group came up with an activity intended to emphasise the benefit of creating meaningful metadata, both to allow others to understand and reuse your data and to ensure that you can find the data you’re looking for in future. In this activity, participants would try to describe a Lego model, deconstruct it, then get another participant to try to reconstruct the model from their description alone. Meaningful metadata becomes essential when you want to share your data with other researchers. Even finding the data relies upon useful descriptions.
Using Lego in Practice
Having received this excellent idea from the Research Ambassadors the Research Data team (Marta Teperek and Rosie Higman) were faced with the task of deciding if this could be integrated into our training. At the moment there does not seem to be sufficient interest (or awareness) to run an entire workshop on metadata, so instead I looked at where it might fit into our existing ‘Introduction to Research Data Management’ workshop. This workshop runs for 2-3 hours on a regular basis for PhD students and postdoctoral researchers in different departments, covering everything from file backup strategies to funders’ requirements to share research data.
Whilst file names and organisation are included in the introductory workshop there is not a specific section on metadata, so for the first attempt we placed the exercise at the end of the section on organising physical samples. As the workshop was already quite busy I realised we could not complete the entire activity in the time available, and so decided just to do the second half (making, describing and reconstructing models) as this would have the most impact on researchers. In particular, I felt it would be valuable for researchers, who are increasingly being asked to share their research data alongside their publications, to see how hard it is to re-use someone else’s data without meaningful metadata.
We have now run this exercise in several workshops and it is consistently popular with participants across the disciplines. The models built have varied from sausage dogs to abstract towers, and most groups struggle to recreate their colleagues’ models, emphasising the importance of good metadata. As with all our activities and workshops we are refining the Lego metadata activity on the basis of participant feedback and our own observations. In order to save on the amount of Lego we needed we ran the exercise with researchers working in pairs or small groups, this worked well in terms of allowing them to network but it was clear after the first workshop that I had not allowed enough time for the activity. Participants became very enthusiastic about their models and so spent a long time discussing it with their partner and then, after swapping descriptions, debating how the other pair’s model should be reconstructed. To get around this problem I lengthened the time allocated for the exercise, reduced the number of Lego bricks each group had to 6 and started using a bell to let participants know when they were running out of time.
After running the activity a couple of times it seemed like it might be in the wrong point in the workshop; we had not yet introduced the idea of data sharing so researchers were sometimes initially confused by discussing having researchers around the world use their data. This turned into a good opportunity as the section on data sharing is quite long, and did not have any interactive elements, so we moved the Lego exercise to the end of this section when researchers have been introduced to the principles of sharing and when we are about to discuss repositories. The new position of the activity has been more effective, with researchers able to see how hard it is to use data which is not properly described. The only difficulty we have now is making sure that researchers do not get distracted by the Lego for the rest of the workshop!