<< dcgross.com

Improvisational Productivity

(Author’s confession: the second half of this post is much better than the first. It starts around sub-title “To Dos”. You might want to skip to that.)

You thought his piece de resistance was “Software is eating the world”.

But I think Marc Andreessen’s best is his seminal “Guide to Personal Productivity”. I read it at least once a year and I’m not alone. I know plenty of friends, founders, and engineers that read it and wish – wish! – they could secretly follow the advice in the article.

The main thesis is that, um, you should do whatever the heck you want to do all day. Never take meetings, and just follow the Mistress of Motivation from task to task, doing whatever seems most interesting to you at the moment. To an over-scheduled introverted founder, this is an unfathomable fantasy. It’s liberating to think of, but it’s also unrealistic.

There’s a reason computers use a scheduler! The odds that two elements will be free at the same time are low. It’s helpful to agree on a time in advance. Hence the calendar. So why is it such an annoying product to use?

Calendar Issue #1: The Index

Time isn’t the correct index for a schedule. Time doesn't know when I'll be in flow. White space in the calendar doesn’t mean I’ll be sitting at my desk, twiddling my thumbs, just waiting for someone to call. It usually means I’ll be working. When I mis-fire and schedule a meeting for when I’m in flow, it can cost me double the meeting time. Breaking the feedback loop of flow with a meeting, notification, or anything else should be illegal. And time-based scheduling often causes it.

The correct way to schedule is based on context:

“Both you and your counterparty wanted to meet. You’re both alone and are browsing Hacker News. Should I patch them in for a call?”

This could be at any time of the day. The hour is irrelevant. Unfortunately, nobody has built this.

Calendar Issue #2: The Pre-compiler

When you have a meeting in the future, you tend to start chewing on it before the meeting. Thinking about how to best accomplish your goal. What you should say. Etc. It’s a conscientiousness feature and a bug. You’ve come to the meeting prepared, but you also spent an hour chewing on a 30 minute sales call, and weren’t as able in the other goals you had for the day.

The pre-compilation step applies beyond meetings. It applies to your to-do list, too.

To Dos

The longer you think about a task without doing it, the less novel it becomes to do. Writing things in your to-do list and coming back to them later helps you focus, but it comes at the cost: you’ve now converted an interesting idea into work. Since you’ve thought about it a little bit, it’s less interesting to work on.

It's like chewing on a fresh piece of gum, immediately sticking it somewhere, then trying to convince yourself to rehydrate the dry, bland, task of chewed-up gum. Oh. That thing. Do you really want to go back to that? “We’ve already gone through all the interesting aspects of that problem, and established that there’s only work left”, the mind says.

Stateless Browser

One day someone will make a to-do product that lets you serialize and deserialize flow, like protobuf. Until then, my solution is to (somewhat counter-intuitively) not think about the task until I am ready to fully execute it. I do not unwrap the piece of gum until I’m ready to enjoy it in its entirety. I need to save the fun of thinking to pull myself into flow. Practically, this means things like:


Living in a state of improvisation is more conducive to flow. Unlike Marc’s recommendation, I don’t let myself pursue any idea I have all day (that would be a lot of Wikipedia), but instead I try to make my actual work appear as interesting as a new idea by minimizing the cognitive state buildup I have until I am ready to fully accomplish the task at hand.