My GTD free week

G

gnugrep

0
I've been using GTD for about 6 months now. It has really helped me get better organized and I feel like I'm getting more things done than in the past. But last week I was given one very important project. I'm a computer programmer and I had to basically write a program from scratch in a week. Normally I work on several different things at once and my deadlines aren't usually this tight. I was told to work on nothing else, this application was the highest priority and I could defer everything else until after that week. The amazing thing is this really happened, a couple of times people asked me to do something else, but I told them it would have to wait until next week and they were cool with it.

So I began Monday by mapping out my project in a word file as I normally do. My every intention was to follow the usual GTD system of creating a project and pulling out next actions to put on my lists. After spending about 2 hours planning out the project, I then immediately plunged into writing code. I didn't stop until Thursday evening when the app was done, one day early! I realized at a certain point that I wasn't doing the GTD thing. I didn't write down a single next action. Most of the thoughts or changes I made to the original project plan pretty much stayed in my head, I didn't bother writing it down anywhere. I felt any additional overhead was too much. I did look at my project file from time to time to make sure I wasn't missing anything, but for the most part, everything just flowed, one task after another without a break except for eating, sleeping, etc. The one GTD thing I did was check my tickler every morning to make sure there was nothing super urgent that I couldn't put off until the following week (there wasn't).

It was a little strange working outside of my organizational framework for a whole week, but I found that writing down tasks and keeping track of things that way created too much overhead and I couldn't miss my deadline. It was also nice to get into a flow like that and concentrate on one thing for a week. By the end of it I felt like I was in a zone that I don't normally operate in. Working on small pieces of several different large projects don't really allow this kind of flow.

I'm not sure what to make of this. I went back to using GTD this week, but I'm wondering if it is worth always following all the steps.
 
Did GTD make this week easier?

I look forward to hearing more of your thoughts about this once you've had a chance to digest the experience a little.

One thing I'd like to know: Do you think the fact that you usually follow the GTD process made it easier for you to commit yourself to a single non-stop project for a whole week?

This is where I find a lot of benefit from GTD, especially since I stopped just pretending to do GTD and got into the habit of a total weekly review. Since I know that the bills will be paid and the milk will be bought and the emails will be dealt with and so on, when I need to throw myself completely into a project for a while I can really do that, without having all those other things nag me for attention.

In the end I don't know that I'd even say that you "stopped doing GTD" for the week. The GTD process is a tool, and it sounds to me as if you used it when you needed it, but didn't let the tool get in your way. If your "next action" flows directly from the last action and is going to be done immediately, who needs to stop and write it down? Stopping the flow to write an action just for the sake of writing it down seems like compulsive weirdness rather then thoughtful tool using. Getting non-immediate things off your mind so you can stay in the flow or get back into the flow is what GTD is about.

-T.
 
gnugrep said:
I'm not sure what to make of this. I went back to using GTD this week, but I'm wondering if it is worth always following all the steps.
Click to expand...
I think that what you did to complete this project is still consistent with GTD. The book's brief discussion about "Doing" talks about doing predefined work (the stuff on your NA lists) versus doing work as it shows up. At every moment, we theoretically want to be doing the highest priority action for a particular context, given our available time and energy, right? Sometimes the work that shows up is more important than anything already on our lists. We don't have to write it down to remember it later; we just have to do it right then. You were doing work as it showed up, and you already knew what was showing up was higher priority than everything else on your list.

But maintaining your GTD lists still helps you, because first of all, you knew there wasn't anything that would blow up because you had forgotten about it for a week (from checking your tickler). And secondly, when the week was over, you still had the placeholders you need for all the projects and actions that were deferred the previous week. If you had been keeping a lot of that stuff in your head, either you would have lost it while you focused on something else, or else you would have had to distract yourself by rehearsing it during the week so as not to forget it. You could afford to focus because you knew nothing more important was slipping, and when you were done, all your reminders would still be in place.

Still, it's a good point that writing down many specific small action steps is a lot of overhead. If you don't need as detailed of actions either for the reminder or for the motivation, then use coarser-grained actions to save time and overhead maintaining your system, or just whatever actions you need to get started. If you can shortcut any GTD steps while achieving everything you want to achieve, shortcut all you can. It's possible that for programming, a single action or even just the name of a project is enough to get you started working productively toward an outcome for many hours.

I'm not a very good programmer, but I have to do a fair amount of programming for my work. I don't write down many discrete, small NAs for programming because I don't even know how to do that. I have to get into the environment, look at the code, figure out what to do, and just stay with it until I get it done. I need (unpredictably) large chunks of time to get the necessary momentum, too. I thought that I just couldn't define NAs because I am not skilled enough. But I work with people who are highly skilled, and they don't seem to make any lists of specific actions either. They might have a list of a few different coding projects they're working on, with each project a placeholder to get them started, and from there they know what to do.

So it is obviously possible to be highly productive without writing down in advance every little discrete action, especially for projects that you'll be working on for large chunks of time anyway, or for projects in which your skill and motivation are high. And we don't have to write down the work that shows up to be done right now, when that work is more important than all the stuff on our lists.

Your story is a great illustration of how we should maintain only as much in our systems as we need to get stuff done, and no more. The point is to get things done, and that's what you did.
 
Great point. I have several projects that I find more effective to work on in "timeboxes" on my calendar, like programming, and writing. These are best executed in a "flow", as a whole, rather than in nibbles of Next Actions.

In general, I'd GTD to make sure a single project isn't taking away time from the other things I need to be doing (checking your tickler file was a good idea), but I agree that sometimes, if you can meet the project outcome without detailed next actions, it involves less overhead to just execute.

So just as a rule of thumb, I wouldn't GTD projects that:
a) I work on all by myself (unless "flow" can be delegated)
b) are short and can be completed in a few sessions (a small project, like writing an app in a week)
c) have just one context (@Laptop would be a single context regardless of where I carry it to...)

Actually, "flow" is a good justification for GTD for me. It lets me move along the things I don't necessarily enjoy, while I'm consumed by the things I do.
 
For writing, and I suspect for programming as well, planning individual steps can be as complex as just going ahead and doing the work. The only writing-related NA that I've ever had any luck with is something like "Write technology assessment: how do organic semiconductors work?" That is, it's a placeholder that tells me where I left off and where to start from.

Now, sometimes I'll encounter an NA like that and get stuck, but there's usually a tangible reason why, and that reason will generate appropriate NAs like "read Coakley paper on organic PVs" or "mindmap technology assessment chapter."

Katherine
 
Define Next Actions for all other active projects that are put on hold.

Next Actions can be treated as bookmarks in your multitasking (ie. doing multiple projects simultaneously) environment. You write NAs to know what to do next for each active project. Then you use them when you must switch your attention from one project to another.

But when you are working in the "crunch mode" on one, top-priority, active project you do not have to write the Next Actions.

You should write the Next Actions for all other active projects that are put on hold during this time.
 
maybe the reason you are so 'calm', is that the GTD system has the rest of your stuff under control, thus allowing you to work for a week on only one project.

Imagine if you had no GTD before - that pile of work floating around may have caused you a larger headache?
 
andersons said:
I'm not a very good programmer, but I have to do a fair amount of programming for my work. I don't write down many discrete, small NAs for programming because I don't even know how to do that. I have to get into the environment, look at the code, figure out what to do, and just stay with it until I get it done. I need (unpredictably) large chunks of time to get the necessary momentum, too. I thought that I just couldn't define NAs because I am not skilled enough. But I work with people who are highly skilled, and they don't seem to make any lists of specific actions either. They might have a list of a few different coding projects they're working on, with each project a placeholder to get them started, and from there they know what to do.

So it is obviously possible to be highly productive without writing down in advance every little discrete action, especially for projects that you'll be working on for large chunks of time anyway, or for projects in which your skill and motivation are high. And we don't have to write down the work that shows up to be done right now, when that work is more important than all the stuff on our lists.

Your story is a great illustration of how we should maintain only as much in our systems as we need to get stuff done, and no more. The point is to get things done, and that's what you did.
Click to expand...

This is a very good point. I often had a hard time coming up with NA for my programming tasks. This week, I just put the name of the programs I'm working on and just go from there. They are more like bookmarks. For example, I'll have: Curve fitter, continue on ALDateFromString function. I know it doesn't fit the David Allen definition of a NA, but I'm not going to worry about that as long as I get things done.
 
You must log in or register to reply here.
Top