Workflow Part One: Blocking

One of the most agonizing parts of anyone's workday is the inevitable question: What should I do next? I think more of my time has seeped into that never ending hole than I have ever spent working on any one thing. I used to labor hard over multitasking, GTD systems, and organizational schemes to try to solve this problem, but ultimately I've come to believe that the foundational trick to being productive is complete focus on the correct thing. Of course, that still leaves us with the monumentally difficult task of choosing the right thing to be working on.

When I was in school, I would hurdle this step by choosing what seemed to be a simple and arbitrary pattern of work: I would work on homework in the order that I had the classes in the day. It was just an unconscious decision, but it took away a lot of subconscious headache, because rather than being overwhelmed by being faced with six pieces of work, I knew which one I needed to tackle next and could focus purely on that.

This sort of workflow pattern works great when you are flying solo. Homework just depended on me working on it. It almost never depended on someone else's response to my work, or any form of collaboration. As soon as you start working with other people, a whole different set of considerations sets in. You may want to work on this project, and it might be your next priority, but now you are waiting on feedback, or your tester to publish results. You start seeing tasks being blocked because they are waiting on some external influence to proceed.

(This next section here is a bit nerdy, so you can (read, should) skip it if you'd like.)

As I was mulling over this problem one day, I realized it reminded me of something. The Linux kernel has a very similar problem: all processes on the computer require some I/O (file writing/reading) and CPU (thinking) time. All processes are weighted to needing either more CPU or more I/O, and these are characterized as either being CPU bound or I/O bound respectively. The problem that the computer faces is that I/O bound problems will "block", or wait for the file request to come back, immediately. If you bring up an I/O bound process, and force it to stay on the processor, it will waste time as it makes a long winded, time-expensive request to the file system, while idling on the CPU preventing other problems from being worked on during the wait.

The solution the Linux kernel adopts is to track which processes are I/O bound and which are processor bound, and adjust their priority so that the I/O bound processes come first. They will immediately block, send off a request for I/O, and allow the processor to be freed up for working on more tasks.

Still here? Lets talk about productivity.

This idea can be directly translated to your workflow. Prioritize things that will "block" immediately, so that they are off your plate, allowing you to move forward and give you that burst of morale. This also is considerate to anyone who depends on you, because they become aware of what you need from them immediately. Now you can be freed up to work on things that require longer, more personal focus. Tasks that can be blocking are usually some form of communication with someone else: any email, request for information or approval, phone calls, new designs. You'll be surprised at how much time you'll free up and how productive you'll feel if you knock out all the ones that require some sort of external influence at the beginning of you day, so that you have the rest of the day free to concentrate on things that rest only on you.

All of this really just comes down to the oft-repeated, never-heeded advice of taking care of the "big rocks first." Choosing to work on items that will block soon is just a strategy to help you manage (prioritize) those boulder sized rocks first, by removing distractions and tasks that get in the way of your productive workflow.