What is the problem you are here to solve?

This short(ish) post is a follow-up to my last post on GTD and the higher levels of altitude David Allen speaks about.

What I have learned, through journaling, is that there is a common background melody to my life. Whatever I am involved in, and if you look at my LinkedIn profile you can see I have been involved in quite a number of activities, both professional and personal, I find that melody back.

Now, the interesting thing is that I never even considered the existence of this melody, this common theme to all my endeavours, until I started journaling. There was an occasional glimpse of that theme, but my consistent failure to identify it has actually led to quite a few instances where I was actively working against that theme, thinking I was doing a good thing.

Self-reflection, while it should never be taken too far, is a great means to identify that very soft but always present melody. That melody which some call your inner voice and some find in meditation practice, something I consistently fail at, is at the core of who you are and provides you, day in and day out, with an answer to the question: "What problem are you here to solve?"

A word of warning. You may be surprised about what you can hear yourself saying when you really listen. It may actually be an answer you were not expecting. It may certainly not be about following your bliss, about achieving riches and becoming famous. It may even not be about being 'happy' Then again, happy is a fleeting emotion and may well be seriously overstated.

However, what I have found and believe to be true is that ultimately identifying your melody, what makes you tick, your inner voice, and then going on that voice to try and live consistently with that voice will lead to achievement, and meaning.

Enjoy your search and your travels. I do. You see a reflection of it whenever I write a blog post.

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.