Project switching friction
Saturday, April 30, 2005
Steve Pavlina's post on "dynamic planning" touches on something I've been thinking about lately: the friction caused by switching contexts or projects as you move from one action to the next.
During the first five years of my company, I worked from home. Any employees worked out of their own homes as well. In January, we finally made the move to an office space, as we were interested in building a more closely knit team environment, and also wanted to move the business to being more of a "job" than a total lifestyle.
Not having too worry about it for so many years, I have been a bit dismayed by the inefficiency of going to and from the office, even though the office is one mile from our house. One trap I've fallen into and am trying to correct is that I tend to have about an hour of unproductive time before leaving for the office. While I'm having coffee, I'll check my email and get a feel for the landscape of the day. This sounds harmless enough, but knowing I'll be leaving for the office soon creates a mental barrier to really completing any actions. I might respond to a few messages, but I know there isn't enough time to get drawn into any significant tasks, so I seem to be going through the motions without really getting anywhere. I'm thinking it might be better to just head straight for the office (we can make coffee there, too) so I can jump right into "work mode."
The other new element to all of this is simply dealing with files. Working from only one place is really simple in terms of file management, because everything you need is on one computer. Now I have to copy things back and forth using my USB key drive. It doesn't take that long, but it's an additional element of friction, and if I happen to forget something, it means an extra trip to the office or home.
What Steve is addressing, however, is the more pervasive friction that occurs any time you switch projects. There is a boot up time associated with reloading the tools, notes, and mental glue whenever you go to a different project. To me, the load time increases relative to how long the project has been inactive. If I worked on a project yesterday, today I'll be able to reload it pretty quickly. If it's been two weeks, getting back into the flow of the project is going to take longer. This seems especially true with code, as my own code will start to seem foreign to me if too much time passes.
I have marathon pushes on particular projects, where I will work an entire day or even several days on only one project. This is usually to meet a deadline. There's no doubt that this is great for getting a lot of work done with minimum switching friction. But in general, I don't like having to do this, because this great progress on one project means the load time on all my other projects is going to be increasing. If I only had three to four projects, I could get into this great flow on each every few days. With lots of projects, I want to keep all of them moving, even if this hinders big chunks of significant progress.
Part of what I like about the concept of the next action is that it can reduce some of this friction of switching projects. The next action is a bookmark, a shortcut to get you back into the fray of a project without having to go back and think, "now, where was I on this project?" every time. There will always be some friction, and I think there is a potential for software to help in this area. I must admit, however, that thinking software can help is usually a danger sign! I've found the best steps forward usually involve modification to mental models or systems and the software is in the background as a mere tool. Still, I can dream, can't I?
If the bookmark to the next action in a project could be expanded from a simple one-line note about what's next to the actual state of your tools and notes as they were when you last were on a project, it seems that would reduce a lot of friction. It would be great if, with one command, your project notes come up, your code editor comes up with the relevant files loaded, the email you were drafting is right there again, etc. In other words, the computer's state is tied directly to your mental state, and multiple states can be saved and reloaded at will. Sure, you can accomplish some of this with a well organized system of links, shortcuts, notes, etc. But I think tools have a long way to go in this regard.
So, in the meantime, I am trying to consider all the mental or physical ways I can reduce friction between switching projects, contexts or actions. Even if the reload time is only a few minutes or even seconds, reducing it can only give you that much more time to actually be productive on projects.
Boys and girls just wanna have fun
My "band," Splice Factor, which is currently just me and my (very hot and talented) wife, played a short set last night at the tenth Camel City Showcase at
The Garage in Winston (impeccably organized by my friend
Brent Naylor). We don't play out much and we practice infrequently, but I always want more after a show. The reason is that playing music really is play, and even grimly serious adults need play time.
There is something totally refreshing about having some time when your mind is essentially blank and free from any consideration of productivity, achievement or even what tomorrow may bring. The demands of others and the weight of your commitments melt away. It is temporary freedom.
Performing music is a physical, visceral activity for me. It's essentially a sport, where the mind takes a back seat to the body. There is also something about the fact that it's an "act," in the sense that you are on stage and presenting some kind of persona (and this dimension probably doesn't apply to tennis) - but these mental acrobatics of classifying and deconstructing your activities only take place after the fact. During the moment, it's all about your body and physics, as you hit strings and force air through your vocal cords.
Anyway, whatever your sport may be, never underestimate the value of refreshment and recreation. It's an entirely different world than the tedious and often draining details of knowledge work (or even "non-work" activities like writing). Step away from the computer and go play. It is the weekend, right?
Revolving workflow strategies
Sunday, April 24, 2005
I've been using
GTD principles for over three years now, mostly with good results. I believe the concepts are generally the best productivity approach for knowledge workers. There are times, however, when I think the model must be expanded to get the best results in a given situation.
There is no doubt that tracking every moving part of every commitment you have is a powerful foundation for productivity. Choosing what you work on at any given moment can get a bit nerve-wracking, however, when you may have hundreds of actions on any given context list.
I have set up my action contexts based on literal physical context. For example, I have an @Computer context. Yes, I spend 98% of my time in this context. Others in this boat have suggested making further sub-contexts, such as @Programming or @Email to account for the fact that @Computer is too ubiquitous for programmers. I use real physical contexts because, to me, that distinction is the reality behind grouping by context in the first place; i.e., can you perform this action in your current physical context? I do place actions to be done at a computer in @Office or @Home if the *only* computer these actions can be done on is in one place or the other (very few actions end up like this, but there are a few).
I've tried coming up with a lot of "conceptual" contexts instead of real physical contexts, but the small friction of this additional up-front labeling seems counterproductive to me, especially since I bundle relevant communication with any given action. For example, when I complete a programming task, I don't then make a separate action to email the client about it; I just go ahead and email the client (if necessary) as part of completing the action. The exception is when I might complete an action in the middle of the night and the next step is to call the client for discussion. Since I can't call the client in the middle of the night, I make an action for the follow-up call. Why I might be working in the middle of the night is a topic for another day.
Anyway, the point is that I move to other criteria when choosing actions to complete from a very long list of @Computer actions. In the book (p. 192 in the hardcover), David tells us that context is only one of four criteria to apply when choosing actions. The other three, in order, are time available, energy available, and priority. I don't generally track these in any formal way, but I do use the criteria intuitively, although I steer clear of priority for the most part. If I have agreed to do something, I need to do it, and setting priorities on actions tends to create a false order (for me). I intuitively know how to discern a real crisis from pedestrian actions anyway. This all works fine, as far as it goes.
I've recently noticed some patterns emerging from how I address actions, and I thought it might be nice to formalize them somewhat for my own use. These are essentially approaches to a day's work, and I think of them as workflow strategies, in the sense of temporarily "prioritizing" the long action lists that confront me every day. These could be an expansion of the "threefold model for evaluating daily work" (p. 196 in the hardcover). David's list is:
- doing predefined work
- doing work as it shows up
- defining your work
My own patterns suggest the following strategies. While they could be rotated throughout a single day, I am finding I like to commit to a single approach early in the day and generally stick to it for the day (possibly choosing a second approach at night). I don't plan in advance what tomorrow's strategy will be, because a lot of it is based on external factors like the number of new client requests I might receive in the morning. These are certainly nothing beyond common sense, and many of them are even laid out in the book and elsewhere, but it has helped me to list them out and think about which I am using at any given time.
alternate projectsLet's see how many different projects I can "touch" today. While I might not make significant progress on any project, completing next actions for as many projects as possible ensures that they are moving forward.
big chunks of time on certain projectsVery nice for nights and weekends, when interruptions are at a minimum. Big chunks of time are necessary for making significant progress on certain projects, and ideally this strategy can be used at least once or twice per week.
complete as many small items as possibleSometimes it's those little actions that pile up and cause undue amounts of stress based on their sheer numbers. I think of these as "mosquito tasks." Occasionally, it's nice to spray the yard and keep their breeding to a minimum. This strategy is essentially focused on reducing the number of actions on your list.
oldest firstActions that age too long can cause problems. They can morph into crises, client dissatisfaction and other ugly foes. By going through actions in this order, you are decreasing the effects of or preventing a backlog. Please use this strategy generously if you get any complaints about your turnaround time. The next strategy can also help with managing perception of your turnaround time.
newest firstI use this strategy when it's evident that it's going to be one of those days when I am bombarded by client requests. Somehow there are just days when all clients, even ones dormant for years, emerge from the woodwork, or all active clients simultaneously decide that this is the day when they must unload all of their requests. I tend to have a "newest first" day at least once per week, and it's the strategy I most infrequently choose of my own accord. Luckily, it's usually pretty obvious early in the day if it's going to be that kind of day. The benefit of this strategy is that you are providing quick response and preventing a new stratum from being layered onto your action lists. This strategy might also be "newest and shortest first," because it is only really effective if the new items coming in won't take eight hours each.
squeaky wheelI am reluctant to advertise this strategy, as I'd hate for everyone to become more squeaky, but sometimes you just have to put the grease in the place that squeaks. If a certain client is upset, anxious or just antsy, this approach can help smooth the situation. Note that it's not a bad idea to diagnose why there are squeaks at all.
goal drivenIn theory, all your actions should be supporting some goal or another. In reality, there are plenty of actions that you must do that are entirely unrelated to your goals. For example, I've got to renew my driver's license this month. I guess "continue to be able to operate a motor vehicle" is a sort of goal, but it's a pretty bland and uninspiring goal at best. Client work also tends to be only indirectly related to goals; usually goals are about internal operations or personal matters. So, there are times that you want to focus on the actions that support the goals that are exciting to you. When all is quiet on the client front, I'll use this strategy for a day.
There may be others that emerge as I continue to observe myself in these patterns. These patterns certainly won't apply to everyone, but they have been useful to me for providing an extra dimension to being able to quickly decide which pre-identified action to do next.
