A journaling workflow for better GTD higher altitude focus

The challenge of journaling

For those of you who ever tried their hand at journaling, you probably found out it is hard, especially after a while. It takes time and it takes effort. It requires commitment. Not unlike blogging or any other writing activity. And like GTD, it's a wagon you can very easily fall off. So why bother?

The relevance of journaling

Journaling is a wonderful practice if you want to get to know yourself. By taking the time to understand what drives you, you may discover you are not what everyone else ever told you you were. If you get to that very realization, by the way, you are already further in your quest for self-understanding than most people will ever get. Knowing that you don't know "you" is a very sobering realization. It should also put you on the road to finding a trustworthy way of meeting yourself.

Now, and that's the good part, you are the only "you" around, and thus you are ideally placed to determine what "you" are about. No one else can get to know you better than you. Pretty much because you are going to be the one who will be spending the most time with you. And that's quite a lot of you's in a single paragraph.

A whole new you

In order to get to know yourself, you need to take the time to listen to yourself. To listen to yourself, you could try meditation. Again, not an easy practice. Journaling is another excellent way to get to know yourself. And you may actually surprise you. Isn't it wonderful that there is someone so close to you you now can get to know?

But remember I said journaling was not easy? There are ways to make it easier.

Day One as the first step

For me, the first step was to start using good journaling software. Now, in a pitch, a text editor will do, but I really like the Day One application. It provides you with multiple ways of getting your information into the system.

Now, most of what you will read below is thanks to the following excellent post by Sven Fechner (SimplicityBliss) in which he refers to this post by Rob Trew. Bear with me while I explain how I use what they built:

My journaling set-up

Let me take you through my setup. I use Day One in combination with two “customizations”. The first is about getting what I have done that day into the Day One application. As my GTD system is built on OmniFocus, I needed a way to get completed OmniFocus tasks into Day One. Combining Hazel, Day One's CLI (Command Line Interface) and Rob Trew's excellent shell script which loads an overview of my done Omnifocus tasks into Day One. Read Sven's blog post and Rob's detailed explaination on how to set it up.

My journaling workflow

Now, based on this script, I get a markdown formatted entry in Day One for every done task I checked off in OmniFocus during the day. And every evening, usually on the train back home, I go through this list of completed tasks and I add some information on the relevance and my personal appreciation of the task. This is very important: it is not about the task, but about how I felt about it. To be complex about it, it's meta reflection time. And a train ride is often the best moment for meta reflection. But the workflow does not end there.

Each evening, or sometimes early the next morning, I launch a textexpander snippet in Day One. The snippet is based on this Lifehack article by Paul Sloane. The article provides you with a set of five questions to ask yourself each day. What I do is I try to go through these questions and answer them totally honestly. Honest answers to these questions allow you to get to know your deep drivers.

The relevance of journaling for GTD: better understanding of 50K and 40K levels through better understanding yourself

What really pays is to revisit what you have written during your weekly review. It may take some time, but it allows you to get to a point where you really better understand yourself and why you do the things you do. Understanding your own motivation to me is an important road into defining what really matters to you, and refocusing yourself.

And after all, if GTD has any value, it should not only make us more effective, but it should help us achieve what is truly close to us.

Outcomes and the problem you are trying to solve

A project is defined, in part, by its outcomes. They describe us what it looks like at our intended project destination, in terms of where we are but also in terms of what we have learned, gained, developed. By defining good outcomes, we actually develop a great way to regularly check whether we are still on course. You typically do this at regular intervals, for example when you are performing a (weekly) review.

But sometimes formulating these outcomes is difficult, not to say almost impossible. I want to take a quick look at this type of situation, what may be a cause and how we can attempt to solve it.

What defines a good outcome?

A good outcome should be SMART. If your outcome is specific, measurable, attainable, realistic and time bound, it becomes adequately concrete to be followed up. There is a reference, an adequately concrete basis for developing a baseline. I've written about this before here.

what can go wrong? A concrete example

Now, theoretically I'm very much aware of what a good outcome should be. I mean, I've even adapted some text expander snippets for that exact purpose. However, the following happened to me only a couple of days ago.

In the course of my weekly review I bumped into the following inbox item (duly captured in my GTD process) "learn python". The source of this idea was an interesting post on MacStories by Federico Viticci on Pythonista for iOS. I'm a real pushover for this kind of excellent articles.

I knew this was not a simple next action. After all, you cannot 'do' learn python. So, it's a project. A project has both a defined 'why' and an outcome. The why was easy. Because I am curious about python. Okay, now the outcome. What does it look like when I get to the other side? Mmm ... Well, I know python. But what does that mean? Knowing is not adequately concrete. I cannot measure knowledge of python unless I define an objective benchmark. But I don't know enough about python to be able to define such a bench mark. ...

It turns out I never really considered what relevance python has or can have for me. I actually did not have enough information on python to assess its use for me. I simply did not have enough basis yet to motivate my (significant) investment in learning this language.

So I converted the project into "research relevance of programming languages for BTC, casmo and personal activities." In Covey speak, I did not have the end in mind. My project now has a number of steps aimed at identifying languages, understanding what I can do with them and matching or approximating this to a need I have or may have in the future.

Now, The answer may be that I have no need for learning a programming language. Perhaps I need to focus on bettering my CSS skills first. But at least I will not be off squandering my time on a no doubt interesting topic that will not contribute to my development or efficiency.

Don't get me wrong. I may still find arguments to learn python, even if it will not yield direct and measurable benefits. But, and that is a highly relevant difference, it will be a considered choice. That choice may mean I need to give up a number of other projects. But it will be considered.

what happened?

I failed to properly formulate a smart outcome for a project. While I was very motivated to learn python, I did not have a good enough reason for committing to it yet. There was no project, only enthusiasm about a potentially interesting subject matter I could get lost in.

While sometimes it may be your subconscious resistance to work that is pushing you in that direction, this was just an inadequately considered idea. Which is why doing the necessary research is a smart sub project to execute.

what has this taught me?

Well, first it taught me there are quite a few potential projects in my inbox or equivalent that are significant time sinks that I have yet to define a good outcome for. As long as the outcome is not clear, as long as they don't qualify as a real problem or issue I am trying to solve, I do not engage with them other than doing some research to clarify my thinking about the end I have in mind.

It also taught that that the SMART framework, heavy as it may be, has a marked advantage: if you fail the SMART test, you have an outcome issue. You are not clear enough. So you need to go back and think it over, again.

For those of you interested in the outcome of this specific issue, you may be interested to know that post my research I decided not to study python yet, and 'learn AppleScript first, as it allows me to automate more on my Mac. This will more directly impact my productivity.