My failures with the Getting Things Done system
Of all my strengths as a person, organization isn’t one of them. I often forget important tasks and important details. I frequently get overwhelmed because the details of a great project clutter of my field of view, whether that’s virtually or physically.
A few years ago, I found the “Getting Things Done” philosophy, and after much dilly-dallying, I implemented it. True to my nature, I implemented it physically. “Anything that is to be done should be done right”. Right?
I have to say, it was beautiful–at first. It was really simple to just place things in my inbox, and deal with them later. It was helpful to know exactly what to work on and when. It was useful to not have all the details clutter up my view, all at once. I had this big journal and binder that I would carry around and write stuff in. But soon, that became tedious, it all became tedious. I’d miss reviews, dread weekly reviews and I don’t think I ever did a monthly one. Soon, I procrastinated on the management of the system itself and it began to buckle around me.
I tried to get back on the wagon a few times. I even gave up my binder for a digital system with all its bells and whistles, perhaps it would manage itself. Digital systems came with their own problems, the bells and whistles often led me to try out everything, all at once. That required both a huge buy-in, and a period in which I was unfamiliar with the very tools that were meant to run my life. Every effort ended poorly.
My latest try
One day, recently, I was at my desk, about to do some work. There was a lot to do, and more just kept coming. I remembered just how useful it was to have everything down somewhere, and I decided to draw on that. I made a list.
It was really simple. When there comes a task to work on, I put it on the list, simple. I didn’t do anything complicated. It was a simple org-mode file with a todo list. When a task is done, tick the box beside the list. No automatic anything, no shiny whistle, no golden bells.
I maintained this system for a while. Some other day, I had some work spill-over till the next day. When I got to my desk the next day, I scrolled up on the list and moved those tasks till today, and that was it. It reminded me of the simplicity of working with the bullet journal, another system I had tried out much earlier.
Opining on the bigger picture
Now, this isn’t to say that the Getting Things Done system does not work. I know that it does. I also know that I get distracted easily. I know that long reviews put me off. I know that if the system gets too cumbersome, I will abandon it.
And to be fair, David Allen mentions all of this in his book. I read it before implementing my first GTD system, so why did I still make those very same mistakes?
I didn’t know.
By this, I don’t mean that I hadn’t read the sentences, but that I never really had to engage with them as more than a sentence in a book. I was far more interested in “just getting it set up and moving on” than actually understanding my tools.
I expected that the Getting Things Done system would save me, like a pill, not like a bicycle. I know now that the proper way to use it is to collaborate with it. It is a hammer, not an airplane. Hammers require that you learn technique, and develop arm strength, have a good grip. When you’re wrong, you’ll feel it in the form of a bruise on your thumb, or a bent nail. Airplanes on the other hand, at least in its consumer form, require almost nothing of you. The pilot will get you to your destination. Whether you fall asleep, or stay awake, you will have little to no effect on whether you arrive safely.
To me, this is the difference between consumer software and what for the purposes of this essay I will call, participatory software.
Consumer software, or consumer tools in general, are often made to resemble pills. They are created with the “user” in mind. The image of the user isn’t of a sophisticated individual willing to put weeks to years of work into learning how the tool works. They want something that works now. Speed, ease-of-use and convenience often characterizes this sort of software. As an example of this, we have quick cook, just-add-water, micro-wave dinners as opposed to home-cooked meals, store-bought furniture.
In contrast to this, we have participatory software, software that requires your participation for it to work optimally. It asks specific qualities of you, it demands your attention. In most cases, you get punished for not giving it fully, and rewarded even fuller when you do.Its praises come slowly, after a learning period, after a period of humility. We know that flow experiences come from engaging with environments like this, where you are called upon to use your facilities to their maximum capacity. We know that flow experiences are important components of happiness.
Examples of this are photoshop instead of AI image generation, carpentry instead of store-bought furniture, hand-crafted, home-cooked meals instead of instant noodles. It’s the difference between writing your term-paper and getting a chatbot to spit out an equally correct essay. They may produce the same external artifact, but there’s a lot more traded off that is implicit.
Perhaps, a better name for dichotomy to characterize this would be augmentative vs substitutive tools.
Back to the matter at hand.
I am slowly building a out my own implementation of GTD, with an appreciation of the tenets of the original system. I understand the point of reviews now, I understand the simplicity of lists. I know what works, at least to the extent that it works for me, and I know why. When I need more, I will implement more, and grow alongside my tools.