Systematizing the interactions between productivity tools
Many productivity systems come ready-packaged with tools and promises and dullness. What might be left out, though, is the their evolutionary history — why they exist in the first place, in their current form, in their current place. This curiosity led me to consider the evolution of my own productivity system.
Let’s start here: I’m a web developer on a small team. Programmers, especially those on smaller teams with less-specialized roles, must do more than write code. They perform business analysis, offer customer service, write documentation, and more.
Keeping track of these demands presents a challenge. In the past, I drifted between Trellos, Asanas, and Google Keeps, consistently abandoning each when they failed to fit my workflow or requirements. Recently, though, my approach changed. Over the past few months, I’ve noticed my organizational system adapt to the wide range of responsibilities in useful ways.
Rather than searching for the best tool to track all my responsibilities, a notable shift in my perspective has been to observe the interactions between the tools that track them. Specifically, I’ve perceived that my system has evolved to handle three distinct issues:
- Planning my day
- Capturing tasks
- Organizing tasks
Each productivity tool aims, it seems, to solve these three problems and be the single source of truth for one’s responsibilities. Todoist promises, for example, to organize your life by integrating with Google Calendar and showing you what you need to do today. It’s great — except when I need to capture a task in a meeting without a device or my collaborator does not use Todoist. In practice, this attempt to solve each aforementioned problem with one tool surely cannot work because each of those three problems is arguably unique.
The optimal solution to each problem, then, is also unique — not to mention idiosyncratic (because, humans). When planning my day, for instance, I prefer a non-digital environment. Pen and paper invite fewer distractions and allow me to think more clearly about priorities. For organizing tasks, however, a digital environment makes more sense. Software affords easy organization, collaboration, and categorization. Finally, capturing tasks requires constant availability and fast insertion — no matter where I am, no matter my connectivity, I need to capture new tasks fast. It’s hard to imagine any one tool that could solve each of these problems well.
This examination also ignores the fact that most of us must — or, at least, are expected to — use multiple tools: a calendar, Trello boards, git issues, Jira, Asana, email, etc.
So the underlying problem, for me, became how to orchestrate the interactions that connect these tools. In other words, the interesting problem to be solved was not the micro problem of choosing between Asana and Todoist but the macro problem of how to organize the flow of tasks and priorities so that I could use either Asana or Todoist and still be effective.
Planning my day I plan my daily by time-boxing my day into discrete chunks. Inspired largely by Cal Newport, this process forces me to consider what is most important and most likely to be completed in any particular day.
Each time-box is filled with commitments and tasks from my calendar and various task repositories (Asana, emails, Git issues, a professional development spreadsheet), etc.
The act of choosing tasks from these various tools forces a brief period of reflection and prioritization — what is most important or essential to be completed today? What tasks are blocking the completion of others?
This daily prioritization allows macro-perspective even when I’m deep within a particular project.
As I move through my day, new demands arise. Meetings, hallway conversations, questions over email or chat, and support tickets all spawn new tasks. To capture these tasks, I keep a list on the opposite page of my daily plan. I call this page The Queue.
Bullet Journaling and GTD inspired this practice. Although much less formal than either of those systems, it achieves the requirement of fast-insertion and constant availability. Everything gets captured, big or small, no matter the immediate relevance, on-the-spot.
At the end of the day, I do a brief dequeue session.
First, I note incomplete time-boxed tasks and consider why they are incomplete — overly-ambitious expectations, insufficient decomposition of the task, etc. If the failure stems from insufficient decomposition, I will go to the appropriate task repository and break down that task further into more manageable chunks. “Fix caching bug on website”, for instance, might be too vague and large to fix in a one-hour time slot, but “Reproduce caching bug on my local machine to speed up testing” may be manageable.
Next, I work through The Queue. For each task, I enter it into the relevant task repository, whether that be an issue in git, a todo in Asana, or a row in a Google Spreadsheet.
I wholly expect that this system will continue to evolve over time. For the moment, though, it solves the three issues of capturing tasks, organizing them, and using them to plan my daily work.