Lab notes is a regular feature in which I report on my efforts to make my life more remarkable.
The Zurich Initiative
Around this time last summer, I found myself at an espresso bar in Zurich Airport’s newly redesigned Terminal 2. I took out my idea notebook and titled a blank page: “Core Principles: Computer Science.” I then sketched out a new, three-part system for tackling my academic research.
As I explained in my last blog post, I’m fascinated by people who build remarkable careers. In my field, building a remarkable career requires remarkable research. This is why as I sat sipping espresso in Switzerland, my last pre-professor year looming, I decided it was time to get serious about exactly how I tackled my work.
My original three-part system, sketched at the airport, quickly faltered in practice. It called, for example, for me to separate “exploration days” from “logistics days,” a level of isolation I found unrealistic.
In other places, it was so vague as to be useless. It said, for example, that “when an exciting problem presents itself, [I should] start working on it early and persistently” — a request way too abstract to translate into day to day action.
But I kept at it: I studied the CV’s of professors I admired; I read books on innovation and craftsmanship; I dissected many years worth of award-winning papers from relevant conferences; and above all else, I tried things — lots of things — to see what actually worked.
Now that I’m a month away from starting my new position at Georgetown, I’ve arrived at a relatively stable research strategy. I assume it will evolve as I gain more experience as a professor, and I’m somewhat nervous that the more experienced among you will scoff at my naivety, but it’s a starting point — a way to start my new position with a proactive (not reactive) mindset.
In this post, as part of my effort to be more transparent about my own quest to build work I love, I explain this system.
Research System: Bottom Level
The best way to understand my research system is as a three-level pyramid (illustrated at the top of this post).
At the bottom level is background research. Every week, I try to learn something new about my field. I either read a paper, attend a talk, or schedule a meeting.
To ensure that I really understand the new idea, I require myself to add a summary, in my own words, to a growing document that I call my “Research Bible.”
Here’s a screenshot of the first page of the table of contents for my bible (as of June 23):
Because I particularly admire professors who make innovative connections between different fields (often a recipe for an interesting career), every other week I focus on adding an “exotic” topic to my bible. This week, for example, I added a chapter on the MIT Media Lab’s Junkyard Jumbotron.
In addition, I set aside one walk each day (usually my walk back to my office after lunch) for brainstorming. There’s no structure here: I allow the ideas in my bible to combine and recombine in novel ways.
Notice, this strategy is lifted directly from the liquid networks concept promoted in Steven Johnson’s book, Where Good Ideas Come From.
Research System: Middle Level
My background reading and brainstorming generates concrete projects. Borrowing a nice concept from Peter Sims, I call these projects “little bets.” Each little bet has the following characteristics:
- It’s small enough to be completed in less than a month.
- It forces me to create new value (e.g., master a new skill and produce new results that didn’t exist before).
- It produces an output that I can use to gather concrete feedback (e.g., a talk or a short write-up).
I try to keep only two or three of these bets active at a time, and I attack them aggressively, tracking my hours using the tally I discussed in a previous post. This provides a simple metric I can aim to maximize.
I also force myself to be specific about my timing for these little bets, as I find I get better work done faster when I’m fighting to meet a specific deadline.
Here’s a screenshot of the Google Docs page where I list my active little bets. I blurred out the description of the bets, but notice the timing column to the right:
These bets produce the following two advantages:
- They force me to master new skills and produce results that generate feedback. This is classic deliberate practice. The system, therefore, helps accelerate my ongoing efforts to be “so good they can’t ignore you.”
- Of equal importance, these bets — and the feedback they generate — help guide my research in more productive directions. A lot of young researchers jump at any idea that is potentially publishable, but this has a way of building a scattered CV that’s hard to later justify. I’m trying instead to evolve a research vision that other people care about. This is really hard. The bets allow me to be more systematic in my efforts.
Research System: Top Level
My little bets lead to publications and grants. In my recent experience, maybe one out of every three bets directly leads to something larger. But the system is too new for me to be confident about this metric.
Research System: My Mission
Off to the side of my three-level research system is my research mission. Here’s how I currently word my mission:
To apply distributed algorithm theory to new settings with the goal of creating new functionality and improving performance.
This mission helps direct the background research that occupies the bottom level of my system. The response I get to my publications and grants, produced at the top level, help evolve the mission. In other words, the system as a whole is a closed feedback loop — constantly evolving itself toward better and better results.
This current system took around a year to develop. I’ve been using it for only a few months now, but it’s already proven more stable than any iterations that came before it.
I fully expect it to evolve — perhaps significantly — once I deploy it at the professor level. But at least I’m hitting the ground with a plan in hand.
I’ll keep you posted about how this plan unfolds.