I disagree with Paul Graham on Procrastination

by Thomas A. Limoncelli

Related link: http://paulgraham.com/procrastination.html

I eagerly await each article that Paul Graham.com posts to his web site. They are brilliant, educational, fun to read. Plus I have to admit that since I wasn't in Silicon Valley for the dot com bubble, I like to live vicariously through his recollections and stories about those years. Sit down and read every essay in one sitting and you'll feel like you just got an MBA with a specialization in startup-ology. Pretty cool stuff.

In this month's article he makes many excellent points about procrastination. The point of his article is to say that if you send all your time working on little stuff and errands you'll never fix the big problems. This is correct. However, his advice about how to skip the little stuff is to just "let delight pull you" to the difficult problems. That's a beautiful and poetic platitude, but useless the average system administrator or technical grunt that is flooded with zillions of tiny tasks that can't just be "put off" because if we do, our employers will be very, very, unhappy.

While I think his advice is good for people that are brilliant scientists and inventors of web 9.0, I think system administrators are of a slightly different mindset, and a very different problem.

The biggest time management problem for system administrators is interruptions. Your boss values your ability to get projects done but the people you serve value your "availability" (how easy it is to interrupt you so that you'll focus on them). These two things are in conflict with each other. There are many ways to fix this. My favorite is the "mutual interruption shield" technique. You catch all interruptions for a co-workers in the AM, letting him or her do project work. Then you switch in the afternoon, i.e. you focus on projects with the support of your co-worker catching all interruptions. System administrators often need some kind of management buy-in to get this kind of structure set up. If you can't get management buy-in, at least structure your seating arrangement so that people that want to interrupt you have to walk by your co-workers before they get to you. Even if they have to pass by a single sacrificial co-worker to get to you the reduction in interruptions can be significant. (Note: buying them t-shirts with a big target on them might be going too far.) TM4SA includes additional techniques, each requiring a varying levels of management buy-in.

The next biggest TM problem that system administrators have is the inability to prioritize. If you have a written/PDAed todo list, you have a chance to start prioritize. It is incredibly difficult to prioritize if you don't have your little tasks, big tasks, and your your life-time goals written down. I spend four chapters in TM4SA on "The Cycle," a simple system for tracking "todo's", "events" and "goals". ("Four chapters is simple? Ha!" Ok, ok, it's a lot more simple than the number of chapters would indicate. To be honest, I was told ORA would license one UserFriendly comic strip for each chapter, so I kept the chapter short and made lots of them.) The side-effect of recording your todo's and goals is that you actually can start to prioritize. This is why the chapter after The Cycle is on (ta da!) prioritization!

Paul writes,

When I talk to people who've managed to make themselves work on big things, I find that all blow off errands, and all feel guilty about it. I don't think they should feel guilty. There's more to do than anyone could.
I appreciate what he's saying, and I agree that people shouldn't feel guilty, but I go about solving the problem 180 degrees differently. I find that I can't focus on the big things if I have too many little things on my todo list. The little things bother me whether real or perceived reasons, or just because they're cramping my brain leaving little space for my tiny brain to work on the big things.

In college I got most of my big projects done between midnight and 4am. This is not because I'm a "night person" (I'm not). It's because I would spend all evening whittle away all the small dumb errands that I had (laundry, cleaning my email box, putting up posters, and so on) untiil they were eliminated and I had no other excuse but to work on the big project that I should have been doing in the first place. Also, since so little new email would arrive after midnight (my smarter friends were asleep, or studying, or doing other non-email-generating tasks) I wasn't tempted by that constant distraction. With my todo list eliminated, the only thing left to do is the big project that should have been my top priority.

Now that I use The Cycle things are very different.

The Cycle encourages you to make 365 todo lists per year. If you have a PDA, software like DateBook5 makes it easy. If you have a paper organizer, each month you load the next set of 30 Page Per Day refill sheets.

Here's how I start each day. I look at today's todo list and say, "Sweet Jesus! That's more than I could do in a week!" So I mark each item with an A, B, or C priority. Then I move the "C" priorities to future todo lists. That new software package I need to experiment with? Move it to next Wednesday's todo list. That script to automate such-and-such? No harm will come if it doesn't happen until Monday, so I put it on Monday's todo list. Calling that salesperson about blah-blah-blah? Move that to tomorrow's list. If there is still more work than can be accomplished today, I do the same for the "B" priorities too. Look Mom, I'm prioritizing!

I mentioned that interruptions take a lot of my time, so when I calculate "how much work I can get done today" I include 2 hours of "interrupt time". That's about average for me in my current job. If it turns out that I have less than 2 hours of interruptions today, I have spare time at the end of my day. W00t. If an interruption wipes my entire day, at least I know I can look at today's list and quickly triage the things that have to be done no matter what. Now I'm prioritizing and I'm dealing better with interruptions. Joy.

If you recall I mentioned that in college I couldn't focus on a big project if I had any little tasks to do. Here's where The Cycle saves me. I just move all those little items to tomorrow's todo list. Ha! Takes a minute to do, and gets them "off my plate." In college I would have spent all night actually doing those tasks but this is much better. I get to the important big project faster, and yet I don't lose those small items "by mistake." While they aren't "done", they are "managed", which is much more important than actually doing them. Once they are "managed" off today's todo list, they are no longer making me crazy or otherwise making it emotionally difficult to work on "the big project". No guilt.

That bears repeating: the important tool here is that you are shifting from "I want to get everything done" to "I want to make sure all my tasks are managed". "Managed" might mean picking another date to do something, deciding to never do it (and notifying those that will be affected), delegating it, or pushing it back to your boss (politely, of course).

Now we can add a task to be managed called, "work on the big things", schedule 2, or 4, or 8 hours of it a day, schedule it, or do it guilt-free when the inspiration hits us.

Don't procrastinate: tell me what you think!


2005-12-28 10:14:10
Missing the Context
I think you are missing the context of what Paul is talking about. While I completely agree with you on that his system would not work in the context of a sysadmin, that doesn't mean that Paul is off base for his context which generally seems to be startup company founders.

A sysadmin is a cog in the bureaucracy that is a company's support structure. Of course, his day is interrupt driven his work is to make sure others can do their work.

If he is supposed to find/create some new software to help the company that is a very different job description and so he really needs a different job title, like developer. But of course bureaucracies are too dumb to figure that out so they just complain when nothing happens the way they want.

But that is a different problem from procrastination.

2005-12-29 12:03:25
Missing the Context
"A sysadmin is a cog in the bureaucracy that is a company's support structure."

Wow, I forgot that so many people think about sysadmins as the janitors of the IT world. I disagree. Sysadmins work way beyond the helpdesk. They are tasked with multi-thousand and multi-million-dollar projects. They are asked to find "the big solution". They write millions of lines of code without being given any credit.

Just the other day I met with a sysadmin that worked for Yet Another Company that was spending millions of dollars to develop a a web-based service, but the entire deployment, fail-over, and disaster recovery aspects of the project where "left for IT to work out". The sysadmins were expects to do it all in their spare time. This is typical, not a rarity.

Now you may be saying, "but any company that would do that is run by a bunch of idiots." Congrats, you've just insulted 90% of the industry.
(Or you were thinking, "But that stuff should be a no brainer!" in which case I recommend you spend a day with a system administrator at your company. Or read http://sunportal.sunmanagers.org/pipermail/summaries/2002-January/000696.html )

And you wrote:
"If he is supposed to find/create some new software to help the company that is a very different job description and so he really needs a different job title, like developer."

That's a very interesting perspective on what sysadmins do. My experience is very different. Sysadmins are the IT architects much more than just the helpdesk answer-dude.

Are you a CEO? I would love to get an understanding of how you have organized your company. (I'm not being sarcastic, I really would like to have a dialog with you to get an understanding of what you are talking about.) Please contact me at the email address listed on http://www.oreillynet.com/pub/au/2176