org

contents

• overview
• task management
  • inboxes
    • processing the inbox
  • lists
    • next actions
    • recurring actions
    • ideas
    • dependencies (“waiting for”)
  • tags
  • processing
    • daily review
    • weekly review
    • quarterly review
    • annual review
• priority management
  • Impact-Effort Matrix
  • Eisenhower Matrix
• storage & reference
  • top level
  • second level
  • third level
  • reading
  • photos & music

overview

There are three components to my system: task management, priority management, and storage. This is where I keep a record of how I run my system, for myself and others who might be interested.

task management

I’ve used Getting Things Done (GTD), this strangely cultish method by David Allen, since about the time it came out in 2001. That’s a long time now, basically since high school. It has become quite a habit for me, and I would highly recommend anyone start this habit sooner rather than later - you’ll get it wrong a number of times and eventually settle on the fixtures and features of the method which resonate with you. For me, the durable bits have been:

• Inboxes
• Next Actions
• Recurring Actions
• Dependencies (“waiting for”)
• Tags
• Ideas
• Processing (Review)

Things I have not been able to get sticking in the last 20-something years of doing this:

• Strategic work (why am I here, what do I care about, what do I do?). I am terrible at the existential stuff. This is true in life as well as GTD.
• Tasks to Calendar (blocking time for minor tasks). I do this well for large tasks and projects, but small stuff snowplows sometimes, and I’m working on it.

If you’re just starting this journey yourself, it’s a great idea to get the original book, and to check out others’ summaries of their processes, like this one and the excellent GTD For Hackers. Keep in mind that when you read any account of such a method, you probably won’t implement things exactly as others have done. I suspect very few people read “Getting Things Done” and simply do all of it - you’ll figure out what 30% of the method works for you, and do that. You might hack the other 70% into something more bespoke for your own life and workflow.

Whatever you do, consistency and refinement is important, progress not perfection.

inboxes

Inboxes are the single most important part of the whole method. An inbox can be anything, but it’s always a dumping ground, functionally. My most-used inboxes are

• the physical one on my desk at home (for physical things like papers and small objects)
• the physical one on my desk at work
• the digital one in my task application (I use Todoist)
• a notebook I carry with me in my pack
• a notebook I keep on my desk at home / at work

This is occasionally supplemented by any number of ephemeral or contingent inboxes. Maybe you’re traveling and all you have is a napkin. Maybe you’re in some random office you don’t keep stocked with your usual stuff and you grab a piece of paper from the printer and fill it with notes. Whatever.

The important thing is that you build a practice of processing these inboxes. Get stuff out of your head and into these inboxes so that you can stop thinking about that stuff, and do it with the assurance that you have a process by which you will process it into appropriate places later.

processing the inbox

I do this with everything that ends up in an inbox of mine:

On a regular basis, and this has a different meaning for you than it does for me, you need to process your inboxes. I process all my inboxes at least weekly. Each item in the inbox should be subjected to the above flowchart, no exceptions.

Processing can take anywhere from a few minutes to an hour or so. If it’s taking more time than an hour, you’re probably doing it wrong, or you’ve got a huge backlog. I go into detail about how I do my processing in the “processing” section below, but suffice it to say that what we’ve covered so far is:

thing(head, object, instruction, artifact) >
 inbox >
 processing workflow >
 next action / idea / recurring action / storage

lists

The lists, functionally, are super important. Their names less so, but I have selected names which remind me of their functions.

next actions

Next Actions is a list of tasks which are ready to be done. This means that they are already decomposed into a single, specific thing which needs to be done and which is unencumbered by other dependencies. If you need a phone number to call someone to make an appointment for something, put it in the action to avoid such a dependency. Friction kills forward motion. As an example:

"Make an appointment with dentist"

is less good than,

"Schedule a regular cleaning with the dentist"

is less good than,

"Call 212-293-3847 and schedule regular cleaning with Joe Dentist"

This might sound silly and pedantic, but trust me, you’ll learn fast that having the information you need at hand to do the thing you need your future self to do will make that thing more likely to get done. I don’t have a universal standard to apply here other than to say that if you think you need a piece of information to accomplish that action in the future, you should put it in the action itself. If that seems daunting or pointless, it’s possible the action is not in fact a Next Action, but needs to be further decomposed into smaller steps which can be accomplished separately or are dependent on serial execution (serial dependency).

Most things on Next Actions need a date on which you’ll do them, or by which you’ll do them, whichever works for you. It’s ok if some things don’t have dates associated with them, so long as you have validated that they are in fact actionable, and you have some plan or cadence on which you’ll pick one of them up and do it, like a block of time for getting these things done.

recurring actions

Recurring Actions are subject to the same criteria as Next Actions, except they occur at regular intervals. You might need to clean out your old public key identities annually, for example, or write your friend for their birthday on the day each year, or do your GTD processing weekly. The point is simple, but subtle: separate your recurring actions list from your Next Actions list to avoid clutter. Even though they’re similar, it’s way too easy to lose important one-time tasks in a sea of recurring ones you’ll inevitably build over time.

Obviously, since recurring actions need a period on which they will recur, everything in here needs a date for completion or it doesn’t make sense for this list.

ideas

Ideas, in my world, are not subject to as stringent a criteria as actions. Some of them could be actions, but are not actionable yet. Some of them are whole projects, or large amounts of effort which will definitely require decomposition in the future before I can act on them. It’s ok, just get them into your Ideas list, and tag them appropriately (more on tags later) and you’ll revisit them when appropriate.

A few examples of things I keep on my Ideas list:

• Books people have told me to read (and who recommended them, so I can follow up)
• Things I want to make/build in the future
• Gift ideas for people, even vague ones which might not be fully developed yet into something makeable / buyable
• Places I want to visit, and how I found out about them

This is easily the most diverse category of processed items outside my “reference / storage” category. What distinguishes Ideas from mere storage, however, is the possiblity that they’ll be actionable in the future. If something is truly not going to promote action, ever, then it should be archived off into storage, or deleted.

Nothing in Ideas needs to have a date. Some things might, but it certainly isn’t required. Ideas are part of a review process for potential promotion to Actions, so they are fine to be left undated when appropriate.

dependencies (“waiting for”)

This is a list of things that would be Next Actions, except that you delegated them to others, or need others to do them, and you’re waiting on that to happen. Everything in here needs a date on which you’ll follow up with the entity intended to be doing the action.

You delegate more than you think you do, even if you don’t have a traditional relationship of delegation with someone, as might a person in a corporate org structure. That insurance quote you’re waiting on? The book you must read which gets published on February 11 next year? The dates you’re waiting on from your mother so you can plan a visit to see her? All these things are effectively delegations or dependencies which should be tracked here.

tags

Tags allow me to sort the jumble of things in the various lists into contexts. Contexts for me include:

• Names of people I deal with a lot, whether personal or work related.
• Names of my various jobs.
• Categories (book, movie, make, 1:1, phone, gtd(administration), etc)

I use these tags to build filters and views as appropriate. If I want to see what I need to talk to “Joe” about on our next 1:1 meeting, I might filter for both “Joe” and “1:1”, and keep that as a view which I recall any time we have a 1:1 meeting.

If I need to see what phone calls I need to make or schedule, I might simply call up the “phone” tag.

If I need to see everything I’m doing for work at “Acme”, I might call up that tag.

The line between a “project” and a “tag” can be blurry, but generally I try to get away with tags until I clearly need a project, such as when I need to collaborate on something with others, or keep information explicitly separate from other information, such as two customer projects which cannot be commingled. Tags are usually more powerful than projects, without the compartmentalization issues which projects have.

processing

The processing habit is what allows all of this to work. With assured processing, you will rest easy knowing that things you commit to your inboxes, and thence to various lists, will not be lost. If you do not build a processing habit, this whole thing just becomes a pile-up of things you know you should do but which will get lost, along with the whole point of having a system for, uh, getting things done.

If you feel or sense that your processing habit is not well or regularly implemented, you’ll lose faith in your inbox system, which will cause a feedback into your offloading habit. You’ll start trying to remember stuff lest you drop it, and that’ll inevitably cascade into forgetting stuff, and dropping it anyway.

Anyone with any reasonable amount of things they’re responsible for cannot mentally track them all. Get stuff out of your head (the inbox habit) and process it so you are assured of the integrity of your system, and feel good committing important things to its functioning.

daily review

Every day, I do the following, all of which are very basic:

• Clean out my email inbox, processing emails according to my inbox workflow.
• Review the Next Actions which are scheduled for the day, and defer them or reschedule them if they are not able to be done.
• Check off the things I’ve done, to keep status updated.
• If I took notes or created especially nonstandard inboxes (random slips of paper, artifacts in my bag, pockets, etc), get those processed according to my inbox workflow.

weekly review

Weekly review is more complicated, and takes about an hour for me, normally at the end of a Friday as I’m closing out my week:

• Clear off my desk, process anything that should be an inbox item.
• Empty my todoist inbox, in case anything fell through the cracks (“Inbox” is the default project Todoist commits something to when it has no other direction, so sometimes things end up in there by default or mistake.)
• Review all Next Actions to ensure things are completed which were completed, and to reschedule, reshuffle, or elaborate on other tasks in there before next week starts.
• Review Delegations (“Waiting for”) list to be sure nothing is falling through the cracks, particularly to be sure everything has a date on which you will follow up about that thing.
• Review Projects under way. Where you have projects in lists or systems outside your main actions/delegations/recurring/ideas, make sure to prune, elaborate, and update those weekly. Often for me, these are in a project management system, but they also might be projects broken out from the main lists because of the clutter they would otherwise produce.
• Review current-week calendar: use it as a prompt for tasks, projects, or things you didn’t commit to your system in the moment, but should.
• Review next-week calendar: use it as a prompt for tasks, projects, or things you need to commit to your system before next week occurs. Also reorder and deconflict next week while you’re at it, since you’re probably quadruple booked for something.
• Update any status dashboards, particularly the ones you owe folks you work with. This might not be relevant to you, but it’s a good time to do it if you must.
• Review your Ideas list. Promote things to Actions where appropriate, or elaborate on things which have new details.

quarterly review

Quarterly, I only do a few things, but they are more time consuming when they need to be done:

• Rethink any Projects which should be demoted to tags, or tags which should be promoted to projects.
• Clean up old stuff to storage where it’s no longer needed.
• Make sure any integrations between systems (such as calendar integrations with your task management app, or availability integrations with the links you send our for scheduling) are working and properly configured.

annual review

I’m terrible at this, but I do make a stab at doing the stuff I consider “existential”. What do you do? What do you want to be doing? What even are you? Honestly, it usually devolves into an extra-big rethink of my org structure annually, and I can’t claim to have had any profound insight into my being, but maybe you’ll have more luck. The GTD Methodology formally treats this with more detail and weight if you’re interested in trying yourself, it’s called “Focus Horizons” there.

For my part, I spend about half a day per year just carefully thinking through my system and updating stuff like this page with how I’ll modify it or what I need to do better. My system is too tactical to get wrapped up in the big stuff.

priority management

This one isn’t complicated, but it’s a handy tool when deconflicting the stuff you think you need to do (the whole body of your tasks) with the reality of time, and how much you can accomplish. Some people like to use OODA loops (I don’t), some people like to use matrices (I do). What you use isn’t important, just make sure you have a good way to apply some criteria with which you’re familiar to the tasks you’ll soon have in excrutiating detail from the above processes.

Here I’ve outlined the two systems I personally use. They are both 2x2 matrices, don’t be too confused, there’s nothing to this. Heck, you don’t even need to actually fill out the matrix with tasks, unless that’s your jam. I personally just use these frameworks as ways to think about any given task I’m presented.

Impact-Effort Matrix

There are four boxes in this 2x2 matrix, high/low impact, and high/low effort. I rank things to be done according to this criteria:

1. (do first) High Impact, Low Effort: Quick Wins. These are the tasks or projects that you should tackle first. They offer the highest return on investment for your effort.
2. (do second) High Impact, High Effort: Major Projects. These items are important but require significant time and resources. Plan and execute them after the quick wins.
3. (do third) Low Impact, Low Effort: Fill-ins. These can be done when you have spare time. They won’t make a big difference but are easy to complete.
4. (do last, defer) Low Impact, High Effort: Thankless Tasks. These tasks require a lot of effort but don’t provide much return. Avoid or minimise these tasks whenever possible.

Eisenhower Matrix

Similar to the Impact-Effort Matrix, this is a 2x2, but ranking importance (instead of impact) and urgency (instead of effort). It also includes delegation and deletion concepts, which can be helpful if what you need is a filter more than an order of operation.

1. (do soon) Important and urgent: do it. These are the tasks that you want to do as soon as possible. Crises, pressing problems and other things where not acting now has negative consequences.
2. (schedule) Important but not urgent: schedule it. Find a time for these tasks and do them then. This quadrant is typically where deep work happens – tasks that contribute to your projects or long-term goals.
3. (delegate) Urgent but not important: delegate it. If you can, find someone who can do these tasks for you. If you can’t delegate it, schedule it but always try to do the important-but-not-urgent tasks first. These are often administrative tasks or things that have deadlines but aren’t critical.
4. (delete) Not urgent and not important: don’t do it. These tasks aren’t worth your time and you shouldn’t do them at all. Avoidance activities, busy work and entertainment goes into this quadrant.

storage & reference

This is where the output of tasks goes, where documents I generate, code I produce, photos I store, and reference materials I want to keep hang out. Nothing in here is necessarily actionable, that’s why it’s reference or for storage.

The biggest challenge for me has been to find a method which is extensible to an almost arbitrary scope while remaining accessible to my recollection of where things should be. I have implemented a system inspired by [https://johnnydecimal.com/](Johnny Decimal)

Rules:

• not more than three levels deep for folders
• not more than subcategories per second or third level taxonomy
• rules were meant to be broken sometimes, as when photos are simply better stored by date, and when reading is better stored by the Dewey Decimal Categories.

Like the Library of Babel, this results in a taxonomy which is very large, but not infinite, so you can at least orient yourself a bit.

top level

I have a full-time job, a side-gig or two, and, naturally, a personal life. As such, I’ve implemented projects as the first layer of my taxonomy.

000 - [Reserved for Management]

001 - Emerson

500 - Consulting, Company Management

501 to 899 - Consulting, per-customer

900 - [Reserved]

901 to 999 - Full-time Employment,

second level

Areas are the second layer of my taxonomy. There are never more than ten areas per project.

001.00 to 001.09 - [Reserved for Management]

001.10 to 001.19 - Finance

001.20 to 001.29 - Residence

001.30 to 001.39 -

001.40 to 001.49

third level

Categories are the third layer of my taxonomy. There are never more than ten categories per area.

001.10 to 001.19 - Finance

001.10.10 - Financial Plan

001.10.11 - Tax Returns

001.20 to 001.29 - Residence

001.20.

reading

I shorten the Dewey Decimal Categories by one place, since I don’t need anything more granular than the main high-level categories. “100”, Philosophy & Psychology, becomes “10” and 400, “Language”, becomes “40”.

00 – Computer science, information and general works

10 – Philosophy and psychology

20 – Religion

30 – Social sciences

40 – Language

50 – Pure Science

60 – Technology

70 – Arts and recreation

80 – Literature

90 – History and geography

photos & music

Photos & Music (generally referred to as media) are somewhat exempt from this, since I’ve found no better way to store them than by-date.

home | github | mastodon | keyoxide