In Search of Productive Simplicity
Last week, I described a kink in my project productivity systems. I was oscillating, somewhat haphazardly, between two different strategies, tracking hours (e.g., when the work is open-ended), and pursuing milestones (when the work is known and I need to hustle).
This felt too complicated, so I asked for your thoughts and you responded with over thirty suggestions.
A lot of your advice seemed to fall into the category of “different work requires different tools, switch as needed.”
This is probably good counsel.
But it still nagged at my preference for simplicity in such matters (which, as a theoretical computer scientist, I of course measure in terms of Kolmogorov complexity).
Then I got an e-mail from an academic in a field that also requires proof-style work (e.g., problems for which the process to completion is unknown in advance). He explained how he approaches projects:
Milestones for me. In [my field] I hit roadblocks and dead ends which force me to start over or take off in a different direction.
After asking him some clarifying questions, I filled in the details. When working on a complex problem, he would set a key milestone and attack it. If he failed to reach the milestone, he would then ask “why?”, and react accordingly:
- If his answer is “I didn’t spend much time on it,” then he knows the next step is to put aside more time in the near future to work deeply.
- If his answer is, instead, “I did spend enough time on it, but I didn’t get anywhere,” then he’s forced to either: (a) identify a brand new approach and tackle the same milestone again with this new approach; or (b) move on to an unrelated milestone.
To summarize, this approach focuses on milestones of the form “accomplish X by Y” (not hour tracking), but when a milestone is missed, it generates an immediate postmortem to figure out what comes next.
Once I understood these details, the full simplicity and power of this approach resonated with me. This academic was reacting to an important truth that I was overlooking: the difficulty of hard-to-predict processes — like solving proofs — is not just making sure you put in the time, but also making sure you don’t waste time stuck in a cul-de-sac (to borrow a Seth Godin term).
Stated more concretely: it’s likely way more productive to spend five hours each on three different approaches to a problem then to spend fifteen hours stuck on one approach.
This milestone-centric strategy is inspired by this reality. There are two reasons why it appeals to me:
First, I love the simplicity of using a single tool to unify how I approach the various important projects in my life.
Second, it resonates with my experience: if I fail to prove something with a given approach after, say, 5 – 6 hours, I’m likely never going to succeed with this approach. I either need to try something new, read something new, talk to someone, or move on to a new problem, keeping this one in the back of my mind in case I later come across a relevant new tool (a common trick of Richard Feynman).
I need to try this approach more extensively before declaring it successful. And it likely does not apply to many fields outside my own. But I thought it might be interesting to offer some insight into the meta-thinking that supports a lot of what I do.
More importantly, it’s a good excuse to bring up Kolmogorov.