In the Country of the Blind, the One-Eyed Man Is an Alien

Workflows and Collaborators

2e6.jpg

Whenever I find a product or a workflow that allows me greater concentration, I find reverting back to the old ways especially painful. A great example of this is my TextExpander: I can’t type on someone else’s computer, because I have so many snippets that have worked into my writing (I have even caught myself writing a snippet when writing something in long-hand). Adjusting to the workflows of others can be especially daunting, especially when they tend to do things in ways that are tragically inefficient. I had this experience with my dissertation.

The Problem

I guess my readers have observed that I am a big fan of Scrivener. I don’t know of a better writing tool. And while many use Scrivener for creative writing, I have discovered that it essential for academic writing. Almost everything I write starts out in Scrivener, unless it starts in Ulysses. If I have to open a MSWord document, I feel a tiny pang of disappointment and malaise.

So you can imagine my horror at having to write my dissertation in Word. My committee members wanted to track changes and see revisions throughout the process. I deeply appreciated all of the feedback (and they gave me LOTS to be appreciative of), but I couldn’t functionally use Scrivener for my dissertation and maintain a lot of the tracking that was being done. If you’ve seen the APA template for Scrivener, it is SO awesome. I had edited the compile menu for my institution’s unique requirements, but I rarely had to do any formatting work. There are ways to collaborate with others not using Scrivener; but in the end, I just decided to use Word and keep moving.

This happens in other situations as well. I’m on a research team where everyone wants to do everything on a Google doc. I spent hours trying to convince a colleague to use Trello, only to discover that I’d spent more time in the persuasion than the work would actually take. I created an OmniPlan project for a huge disability compliance project, only to find that the rest of the team just wanted to use a spreadsheet. I’m not the most powerful power-user, but among some that I am fated to work with, I am often advocating for tools and methods that present insurmountable barriers to those I’m working with.

The Solution

I have found that there are several questions that need to be explored in doing collaborative work, and particularly in terms of what tools or methods will be employed in the collaboration. While some of these questions may seem obvious, I’ve discovered that I actually have to be intentional about asking them.

  1. Does the choice of tool/method slow me down, or the entire team? I am learning that I tend to assume that if I am slowed, the entire team is slowed; call it the illusion of validity cognitive bias. It is entirely possible that the net-effect of using spreadsheets to track the progress of a project is faster for the team, even if it takes more time for me individually.
  2. Does the choice of tool/method really result in different outcomes? Is a presentation in Powerpoint any less effective than a presentation in Google Slides or Keynote? Shouldn’t I get similar statistics from Stata, R, SPSS, and Excel? Does Dedoose or NVivo really provide any better observations of qualitative data than notecards spread out on the floor? If the tool or method does result in different outcomes, then I am more comfortable in advocating for the right tool - but I think it’s a question that must be answered.
  3. What is the ROI of training/investment regarding a tool or method? If, as a team, it takes 20 person-hours of training to use a tool that saves 2 person-hours, is that a useful tradeoff? Sometimes the benefit is not in hours saved, but in accuracy. In the example of the disability compliance project, the stakes of missing a deadline with the Office of Civil Rights are potentially quite high. I decided to fight for a system that would allow us to see deadlines and contingencies throughout the reporting process. In other instances, I find that low stakes or minimal return on investments of time, resources, or finances in training an ad hoc team to use the right tool may justify a hearty shoulder-shrug.
  4. What is my real investment in this tool/method? In the example of my dissertation, I so very much looked forward to the elegance, efficiency, and delight of my beloved writing tool. It has served me so well in all of my other writing; why should I not use it in my magnum opus??? I had to come to terms with the realization that I probably could go through the collaborative process with my committee in Word just fine - I just didn’t want to. It boiled down to an emotional investment. I might be willing to fight for an emotional investment; but I at least want to deliberate about the fight before throwing down the gauntlet.

When You DO Decide to Fight

I think it’s fair to assert that sometimes my tools/methods are better than those that others. I may have given more time, energy, and development in my approach. Others may have defaulted to the familiar, or chosen tools and methods that lead to poorer outcomes. In situations where I’ve decided to the adoption of my tools and methods, I’m learning that I need to evaluate my own mindset. Here are some tips…

  1. Be Prepared to Train! This is deeper than the obvious “Show them how to do it.” I had a staff-member who wasn’t keeping her part of a project updated in Trello. As it happens, she had lost the password, and the password recovery emails were going to her spam folder. So the training became “how to find emails in the Google spam folder.” One would assume that practitioners in higher education would think about how we train one another, but I am constantly discovering ways in which I fail to think about how learning happens for colleagues.
  2. Be Prepared to be Patient! Maybe it’s just me; but I act like “Nick Burns, Your Company’s Computer Guy” more often than I’d care to admit, even if it’s in my own head. You know what? I’ve been working on my task-management system since September of 1992. I spent hours learning how to use OmniPlan on Lynda.com. I don’t remember my password for Trello either: it’s just that Dashlane remembers it for me.
  3. Be Prepared to Be Responsible! If I assert my own tool or method with a team, it’s probably only fair to assume that I should be responsible for that approach. For example, when I did decide that our compliance team was using OmniPlan, I had to assume that I would be the one building the project with that tool. If Larry wants to use his dang spreadsheet to manage the project, I’m sure we can argue whether Larry should be in charge of building the spreadsheet. But I’m learning that when I advocate for “a better way,” that likely means that I’ll be the one responsible for that choice.
  4. Be Prepared to Learn from Others! It may not appear obvious to this point in the post, but there is an assumption that underlies the entire theme: that I know best how things ought to be done, that I am the one-eyed man among the blind. My assistant started using Trello because I asked her to; but I realized soon after that I needed her to train me on all of the ninja things she’s learned to do with it. Remember when I mentioned the research team wanting to use Google Docs? Turns out, it was a GREAT way to do that project.

I’ll write more about some collaboration tools and methods that I think can be very effective for research and teaching; but I think that it is imperative to ask important questions about the value of those tools before assuming that there is a “better way.” And in those instances where a fella believes he has the better tool, he’d better check himSelf before he wrecks himSelf.

Image Credit: http://bit.ly/2nT6z9t

Posted on February 9, 2018 and filed under General, Writing, Task Management.