In June I wrote a piece (see Work Processing and the decline of the ‘Wordish’ document) about what I called ‘work processing’, where I explored some ideas about the use of new productivity apps, like Dropbox Paper, Notion.io, or Quip, and looking at how these tools that support sharing, co-editing, and commenting of digital ‘docs’ can form the groundwork for something altogether different from what we used to call ‘word processing’. In reality, these tools are increasingly being used to manage and share information related to coordinating work. Along with the social communications built-into these tools — like commenting, @mentions, and co-editing — inclusion of checklists has led to these solutions acting as content-centric work management tools, or ‘work processing’ tools.
About Work Management
Work management is a term that has become widely used (one that I’ve advocated for some time) which represents the current state-of-the-practice in task management. Task management tools formerly were limited to a list of tasks: tasks with core attributes like due dates, descriptions, notes, attachments, and perhaps subtasks. These were amplified in more recent years with social sharing and communication, so that tasks could be assigned to other people, and comments could used to support basic communicate with team members (’team task management’). Nowadays, the most competitive tools incorporate social communications, like chat, @mentions, and messaging: these I consider work management tools, like Asana, Trello, and many others. I recently published a Gigaom report on this subject, 2016 Work Management Baseline Narrative.
About Work Processing
Using something like Dropbox Paper as a way to share work-related information is quite different than using a work management tool. Instead of putting lists of tasks at the center of the stage, relatively unstructured content — written text, images, tables, videos, audio, and other forms of content — takes the central role in information sharing, while tasks are indicated by checklists.
Metaphorically, work management is based on the human tendency toward making lists, while work processing relies on our natural urge to tell stories.
Metaphorically, work management is based on the human tendency toward making lists, while work processing relies on our natural urge to tell stories. Or, less romantically, work processing is more like writing in a journal, where occasionally you might add a list of things to do, but where the prose is where the most important information is found.
Using Dropbox Paper as a Work Processing Journal
For several weeks, I have used Dropbox Paper as a work processing journal. This experiment has not involved others, so the social dimension has been limited, but I’ve used Paper with teams in a few projects before, so I can talk to how that might work.
At the start, let me say that Dropbox Paper would be way more effective as a work processing solution if checklists were more task-like, and not just one of various sorts of lists, like bulleted or numbered lists. While checklist items can be used to indicate a task, and the checkbox can be checked to indicate being completed, if checklist items only had a bit more of a task model — with due dates, assignment, and so on — I would be more likely to promote Paper as a foundation for work processing.
Adopting the journaling model is straightforward. For each week, I create a new Paper document titled ‘week <Monday’s date>’, like ‘week 2016–08–29′. I define a Paper section to each day of the week, like 2016–08–29, or 2016–08–31. Then, for each day, I write notes and create tasks in one of the three timeframes:
- looking ahead, or prospectively;
- in real time, when I working on something alone or with others, as during meetings or on calls; or
- looking back, or retrospectively.
Here’s a screen capture (edited) of such a week journal:
Note the section markers in the left margin, where a click takes the viewer to the appropriate section, in this case, the five days of the workweek.
I haven’t displayed Paper comments: any piece of the doc can be selected and a right margin comment can be attached.
Collaborators can be @mentioned anywhere, which leads to them being notified. This requires them to be sharing the doc.
I started to used #tags in the document, although they aren’t supported yet, but it works for searching already, externally or internally.
I also create individual docs for calls and meetings, since they are better shared in that granularity, but I will often retrospectively copy some lines and/or tasks from such a call/meeting document back into the week journal, since it serves more as the system of record than individual call/meeting docs.
Where Dropbox Paper Falls Short in Work Processing
I’ve mentioned the problems with using checklist items as tasks, already, as the major issue with using Dropbox Paper in this way.
Other aspects of the experiment worked surprisingly well for me. I thought I’d miss a rich task model — due dates, notifications, etc. — more than I did. What I learned is that I relied on propinquity: the week journal doc was basically open all day, and as I was adding more information to the various sections I would reacquaint myself with things I need to be working on for Friday, or next week, as I entered new content. And I felt like I had a better big picture sense of what I was working on each day and for the week, than when I just relied on a work management list of tasks.
It would also be great — since Paper supports the idea of doc sections — if sharing could be linked to the section level of a doc, and not just the doc as a whole. Then I could create a section in a journal doc for a single meeting, for example, and invite those attending to share just that section.
However, the core problem I’ve encountered is the dimension of time. Journaling and task management aren’t organized around semantic nesting of docs in folders or the semantic structuring of content within docs, which is the organizing principal of Dropbox Paper (and other tools like it). Journaling and task management should naturally be based on time — hours, days, weeks, and months — not semantic nesting. Yes, I created a form of doc based on a weekly journal, but it’s not native to Paper, just a poor approximation.
In my next post in this series, I will be writing about an alternative to content-centric work processing, one that starts with the calendar as its foundation. Coming next in the Work Processing series: Beyond the Calendar, to Work Journaling.
Originally published at www.stoweboyd.com.