Collaboration in Research - Part 3: Communication Tools

Effective-Communication-Skills.jpg

Ella Cerón wrote an interesting article for GQ magazine on how to break up with someone in the digital age - there’s a lot to consider when you’re managing your life in a number of different platforms. Working teams have similar problems; there are so many possible platforms, that teamwork can easily get dispersed into many different channels.

Imagine that a team had not considered which platform they were going to use to communicate. Ideas, tasks, and data could easily be spread across email (even multiple email addresses), Google chats, Facebook Messenger, text messages, and voice-mail messages.

With just a little forethought, however, this problem can be wrangled for the team. It’s a great idea for a research team to spend just a little time selecting a platform to communicate in, and then channel all communication within that channel.

Slack

 http://bit.ly/2EA7hzF

http://bit.ly/2EA7hzF

Slack is a freemium service that allows teams to create channels for communication. Even though it’s fremium, I’ve not yet encountered a situation where I needed to use the Standard or Plus features. Slack gives users the ability to create a workspace with multiple channels for communication. One can use Slack in a web-browser, but there are also free apps for MacOS and Windows, and the iOS version is a delight to use as well.

Slack teams can post discussion in any number of user-created channels, and direct-message one another in the platform as well. One of my favorite use-cases for Slack is to share files with a team; it’s a very different experience from sharing attachments from member to member. If you’re new to Slack, Click HERE for a really helpful guide for beginners.

Pros: Slack is the ultimate tool for getting team communication into one common stream, sharing files, and archiving discussions. It also integrates VERY well with the internet-of-things services like IFTTT and Zapier. My staff almost never sends emails or texts anymore. They use Slack for everything; including a channel to share funny stories about what’s happening with their children and grandchildren! Slack is great whenever the team is comprised of 3+ members. If the team is two members, email may be more efficient.

Cons: If you’ve a team member who is resistant to learning new things, this approach can be a real challenge. I have, on several occasions, tried to get a team together on Slack, only to find that some members were always going to default to email. If you cannot enforce its use, adoption can sometimes be a challenge.

Other team communication apps similar to Slack are HipChat, Monday.com, Travitor, and WhenIWork, but I’ve not used any of these solutions personally.

Wrike is another option that I’ve explored personally, but not tried with a team yet. Wrike is unique from Slack in that it provides a platform for managing the project/tasks and communication. If I ever find a use-case for Wrike, I’ll probably give it the old college-try.

Google

 http://bit.ly/2FdO3kr

http://bit.ly/2FdO3kr

If your team’s files and data are in Google drive, and/or you’re using Google apps to organize and write, you could do worse than using Google chat and Google hangouts. I worked with a team doing qualitative research where many of us were in different locations. Google hangouts was a great platform for us to meet virtually (a better solution than Skype for a group of people), and we kept much of our communication within the Google space.

Pros: If you’re using Google apps to manage the files and documents, the chat features are actually quite good. Also, Google Hangouts is a wonderful meeting tool for groups of 2-6 people. In my experience, groups larger than 6 on a Google hangout are cumbersome and messy. In cases where the institution already uses Google, this can be a very low-barrier to entry.

Cons: Chats can easily fall into silos, so some members may not see what other members are discussing. To that end, the team may still need email to communicate to more than one person. This results in fewer guiderails to keep communication out of other lines. Also, everyone needs a google account. That’s not a big deal if your university or research center uses Google, but it starts to get messy in instances where the institution uses and Enterprise or other email system.

LMS

 http://bit.ly/2FbY8hS

http://bit.ly/2FbY8hS

If your research team all work in the same university, there is likely a free and robust system available to your free of charge. I am currently working with a group that manages the research project through Canvas. Blackboard and Moodle would also be options (note, I didn’t say good options - I despise Blackboard). If a team is going to use this approach, I recommend setting the members up as teachers; that way, everyone can upload files, create threads in the discussion, and manipulate permissions.

Pros: If you’re working for a university, the platform may already be free and available to you. LMS platforms are, usually, pretty versatile and allow for different course structures. Moreover, the LMS may be useful to manage the organization of files, data, and text. I can even envision using the “assignment” feature to create tasks that specific members need to do: though I haven’t tried that approach with a team yet. If your faculty are already using the LMS for teaching, they’re in the system and familiar with it, so the barrier to entry could be very low.

Cons: Well, there’s the issue of not having access to an LMS. I’ll be honest; to date, I’ve not found a downside to the LMS approach. So far, as much as I love Slack, the LMS approach (we’re using Canvas) has been even better! One downside might be if some of your team members are not a part of your university, you may not be able to bring them into an LMS.

Email

 http://bit.ly/2EBHVl0

http://bit.ly/2EBHVl0

So email gets a deservedly bad-rap from productivity geeks these days. That said, I’ve been in several situations where one or more members will say, “Awe heck, let’s just use email.” To be honest, sometimes members of the team don’t overtly suggest defaulting to email, they just decide to shoot an email to the team instead of posting on Slack.

It is possible to use email wisely. If none of the suggested solutions are going to work for the team, it might be valuable to establish some guiding rules for using email to manage a research team. (Note: the person who is least likely to adopt a new communication channel is also unlikely to take suggestions on how to email better; I’m just sayin’)

  1. Use a subject-line convention: One team I worked with used “DEVMATH” in every subject line related to the project. This was really valuable for nerds like me who wanted to automate those emails into a specific folder.
  2. Use “Reply All” for all communication: I may not be interested in the discussion between Larry and Bob at the moment: but I may become interested later on. “Reply All” is a HUGE headache when using a list-serve; but it’s not so bad for a research team.
  3. Use for smaller groups: When there are only two or three members of a team, this approach makes a great deal of sense. When they are larger, things get out of control real fast.
  4. Avoid attachments: Try very hard to convince your team to keep docs in a cloud location and point to the URL; attachments make things very messy (even when others try to make clever revision-conventions to the filename; I’m talking to you, Sharon!).

Pros: This is the lowest barrier to entry. If you’ve a small group of researchers, and you can effectively train the group to use some keyword in the subject line of emails, you can automate your own email to keep things organized.

Cons: The biggest challenge in this approach is a) using a tag in the subject line, and b) avoiding attachments. The folks who are least likely to adopt some other channel for communication are also the most likely to violate the rules of email for the team.

Considerations

I think it’s really important that the person responsible for communication be permitted to choose the mode of communication. That said, there are several points that one should consider in making the choice:

  1. What is the team size? If the size is large (let’s say, four or more members), something like the LMS or Slack approach is almost imperative. If the team size is two, email will likely be very efficient.
  2. Where are data and files being stored? If data are stored in the messaging system, Slack or an LMS is a great solution. If they are stored in a cloud (Dropbox, Google, iCloud), then email or a Google doc may be just fine.
  3. How likely are members to adopt a new tech? If I were sure that all members would understand the genius of Slack, that would be my choice. I’ve just learned that some folks see this as one more communication channel they’ve got to add to their workflows, and so they just don’t adopt new forms (even when they’re better).

Next time: we’ll look at some strategies for organizing files. By this point, you may be able to guess at some of my suggestions; the means of organizing is interdependent with choices about planning and communication.

Title Image Credit: http://bit.ly/2FcfbAi

Posted on February 18, 2018 .