I'm curious about what strategies, approaches and/or methods people (successfully) use in academia for motivating colleagues to adopt innovative research collaboration mechanisms, workflows and/or tools. Please share your experience or point to proven range of approaches.

The following is in lieu of background information. Currently I'm leading a university project for developing a software platform for scientific research and e-collaboration in a particular scientific domain. Earlier I have installed, configured and publicized another software platform with a goal of increasing research productivity and make scientific collaboration and reproducibility easier within our group and beyond. Unfortunately, after initial decent interest of some people, most of them (and the rest) went back to "doing business as usual". I understand that researchers are busy and are under a lot of pressure to meet/exceed expectations and due to career advancement demands. I don't want to shove innovation down people's throats, but, at the same time, I'm quite frustrated that people do not see (or don't want to see, or don't care) significant potential benefits of some new ways in doing research and/or scientific software development in academia.

Considering the high visibility of my current project, I started thinking about / trying to come up with novel strategies and approaches to motivating colleagues in academia toward adopting innovative methods/tools (i.e., Agile) through emphasizing their potential benefits and/or lost opportunity in research productivity and other aspects, when such innovative methods/tools are not used.

  • 15
    Why do you believe that "another software platform" improves productivity? And why your "new ways in doing research" are better than any other method that other people use? I do not doubt neither your motivation, skills or your good will, but why do you believe that you know better than your colleagues? – Alexandros Jan 22 '16 at 11:43
  • 12
    You have to be very very very careful. Statements like "I tend to see the bigger picture" and "I'm quite frustrated that people do not see (or don't want to see, or don't care) significant potential benefits" are guaranteed to backfire. – Maarten Buis Jan 22 '16 at 13:21
  • 1
    If you haven't already heard of it, you may be interested in a topic called Change Management. When you get down to it, you are trying to practice psychological persuasion - and academics are rather well known for being...resistant to being told what to do, generally. These topics have spawned entire fields of research, and dozens of job titles, and I feel that ultimately this is simply too broad to be answerable in the Stack Exchange Q&A format. – BrianH Jan 22 '16 at 15:15
  • 4
    Learning new tools takes a lot of time and effort that could also be used for research. This can be a bad trade-off, especially for junior academics. The promised future benefits may simply fail to materialize, if they're unable to secure a permanent position due to reduced research productivity meanwhile. – Jouni Sirén Jan 22 '16 at 16:51
  • 3
    @BlueRaja-DannyPflughoeft I'd bet $50 that, in fact, the main reason people don't want to use it is that they don't feel that it solves any actual problem that they have. – David Richerby Jan 23 '16 at 1:32

I'm quite frustrated that people do not see (or don't want to see, or don't care) significant potential benefits of some new ways in doing research and/or scientific software development in academia.

Have you considered that those benefits may simply not be there, at least not to the extent that you hoped for them? One PhD student building a scientific prototype for a conference is not the same as building a product, and many ideas, concepts, and processes that are great for building a collaborative product on Facebook scale may simply be dead weight or even counter-productive for a PhD student in his daily development work. Frankly speaking, if people actually tried your new way of doing things but then went back to "the old way", this is at least some serious indication that there may actually be merit to the old way beyond pure inertia. People typically don't revert to an inferior way of working on purpose after trying something new and better. Have you actually talked to people why they went back?

Anyway, if you wanted to sell your agile ideas to me, the core question to answer would be:

What are concrete, plausible scenarios how your ideas would help me personally?

Stay away from lofty but abstract concepts such as code quality, reproducibility, code reuse, etc. Explain how each researcher individually can profit. What sort of embarrassing bugs and mistakes can be prevented? In what sense can each researcher individually save time? What new papers can be written that we could not easily write the old way?

This requires you to understand extremely well how your colleagues are currently working and what their current pain points are. If whatever way they currently build software is efficient and reasonably bug-free for them, I highly question you will be able to convince them to do e.g., TDD "because that's what industry does". If they are usually able to reproduce their experiments well enough, you won't be able to convince them to set up Docker containers for everything in the future, just because Docker is the current hot shit.

If you actually have access to them, explain cases of "lost opportunity in research productivity and other aspects, when such innovative methods/tools are not used". The important part here is that those cases are (a) real, or at least plausible based on the experience of your colleagues, and (b) damaging to me personally. For instance, it will be hard to convince PhD students to invest time setting up a code based / infrastructure purely for the sake o the next generation of students.

(and, of course, stay far away from ever implying that my scepticism for your ideas is because you see the bigger picture and I don't)

| improve this answer | |
  • Excellent answer (+1). Thank you for your advice - you mention important points, most of which I'm aware of, though, and already trying to implement. Most people didn't quite get my question's emphasis on distinction between the not very good adoption for the smaller (infrastructural) project and my efforts to learn lessons from that and embed them into my plans (strategy, approaches) for the much larger (and much more scientific) ongoing development project. I have no intention to ever imply that someone cannot see the bigger picture - my point is that many people are just too busy to do so. – Aleksandr Blekh Jan 22 '16 at 22:02

The best way to illustrate the value of new tools is to effectively use them yourself. If you are an active researcher and you are twice as efficient as your peers, then your peers might ask you how you manage such a torrid pace.

It sounds like you are not an actual user of your own tools. Moreover, it sounds like researchers demonstrated a willingness to try your tools and were not impressed. I would advise concentrating your energies on figuring out why these researchers chose to go back to "business as usual". You are most likely to succeed if you start from the premise that they know how to do their jobs effectively.

| improve this answer | |
  • Very good point (+1). Unfortunately, you've got the wrong impression, as using approaches and tools I'm advocating for, is exactly what I have been doing, am doing and plan on continuing to do so (to a certain degree). However, I'm seeking supplemental strategies, approaches, methods and tools to help me with my efforts. "... and were not impressed" - no, they were and are too busy (plus other reasons) to change their research routines to adopt new approaches and tools. Plus, some tools are not ready yet - they are in development, so I can't blame people for not using what's not available yet. – Aleksandr Blekh Jan 22 '16 at 20:54

I'm a former consultant, and having people like what you provide is key to a consultant's life (doesn't mean I'm right, and it's quite a long while ago for me). It sounds as if you're looking at the wrong end of the chain of steps of how a new product is ideally rolled out - reception, and feedback by users of the finished product. On top of what other answers have stated, you appear to have skipped the 0th stage.

When you are tasked to implement a new tool, you are likely given broad ideas of what the tool is to achieve. But you'll always run up against people being used to old tools, and both liking them and loathing them for some of their aspects. To ensure buy-in, or at least make it more likely, you should push for an interview stage before you start with any work on the tool. Get a solid understanding of the current situation by spending time with the old tool, then prepare a questionnaire for (some of) its users. Tell them that you have been tasked to create a new tool, and strive to make it as useful for them as possible. For this, ask, among others, about

  1. What is essential to you in any such tool?

  2. What would you like to see again which you currently have, with as little change as possible?

  3. Which aspects of the current tool do you loath?

  4. Which additional features would you welcome?

  5. (assuming you are already considering options, solicit feedback on them)

  6. Is there any cross-integration with other tools this tool should have?

There are obviously many more question to ask, but a lot depend on the project at hand.

I would then also ask for one of the later users as a during-project contact with who you share progress to get some in-development feedback. And after roll-out, a training session, and going from desk to desk to help people get set up, will help.

While you can never guarantee that a tool will be willingly adopted, adoption will be much less likely if its users do not feel that they have been involved in its development.

| improve this answer | |
  • 1
    Excellent answer and good points (+1). I'm already interviewing people (as part of requirements elicitation process), so, at least that, I hope I'm doing right :-). My concerns and efforts in regard to future adoption are due to my desire to plan and embed relevant strategies and approaches into ongoing development process (and interviews are part of it). Interestingly, a set of my interview questions includes most of those you've mentioned. However, I hope to be able to improve it, though. – Aleksandr Blekh Jan 22 '16 at 21:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.