In other words, I’m interested in ways I can design my work-flow/environment/habits to avoid bike-shedding (aka the Law of Triviality), which is the behavior of “substituting a hard and important problem for an easy and inconsequential one” [1]. Examples include 1) looking into an interesting idea that you ran across while doing a research task, even though it is irrelevant to your goal, 2) spending unnecessary time on the formatting of an essay rather than on the actual writing, 3) buying things/building systems to make very minor productivity improvements instead of doing your tasks for the day.
The first system I thought of: Think about your goal and break it into bite-sized sub-tasks (e.g. completable in <30 minutes), writing each on a sticky note. While doing each sub-task, put its sticky note on your monitor, to remind yourself of what you are supposed to do. If you realize that your goal decomposition was wrong (e.g. discovered that there is an unexpected thing you need to do that you weren’t aware of when you originally decomposed your goal) stop what you are doing and add the new sub-task(s) to your pile of sticky notes. Ask yourself whether the new sub-task(s) is actually necessary; if it isn’t, throw away the sticky note and don’t do that sub-task.
Getting Things Done is a great system that I learned independently and that I since learned many EAs use.
https://en.wikipedia.org/wiki/Getting_Things_Done
This answers your question because it gives a way to prioritize tasks and connect larger objectives with day to day tasks.
You should know at first it gives off a sense of being overly prescriptive and it seemed “cargo culty”, both of which I am really biased against, so I ignored it for years after I first heard about it. But actually, the entire thing is essentially the normal process of prioritizing and deciding what things get done.
For starting out, I don’t recommend reading the original book, but instead online summaries.
Another plus is that it introduces you to Kanban boards (cooler and simpler than it sounds), which are basically a better way of making lists.
+1 to GTD
This is a good introduction/summary:
https://hamberg.no/gtd
Here’s another one:
https://www.samuelthomasdavies.com/book-summaries/business/getting-things-done/
This should give you a sense if you want to dive in further.
Thank you!
I’ve been experimenting with different ways to do this for a number of years now, since I’m temperamentally quite susceptible to tunnel-vision/completionism of the kind you describe. Assorted thoughts below.
GTD is a great way to manage your to-do list and make sure you don’t miss stuff, and I definitely recommend implementing it or something like it. But I find it a bit lacklustre for actually deciding what tasks to execute on on a given day. The same is true for quite a few task-management systems.
One system I’ve found effective for breaking through ugh fields and focusing on what’s important is Final Version Perfected. Eisenhower matrices (or at least the concepts underlying them) can also be useful. Timeboxing can help too – I recommend Complice’s pomodoro timer for this, though if you overuse that it can lose its force somewhat.
If you can, having regular check-ins with another human to describe how you’re planning to spend your time can be quite effective – it’s harder to rationalise time-wasting activities to another person than to yourself.
Finally, an important prerequisite for doing what’s important is having some idea of what’s important in the first place. For that, some kind of Weekly Review system is extremely valuable – mine is currently a mashup of GTD’s system, Complice’s built-in reviews, and various personal modifications that have built up over the years.
This is the first time I’ve heard of the Final Version Perfected (FVP). As a person who’s struggled with confronting “tasks I really should do, but aren’t absolutely necessary to do” in a large list of other seemingly more pressing tasks, this could prove very useful. Thank you for mentioning it!
In the past, I’ve put my tasks in a spreadsheet and rated them by “urgency” and “importance,” which were multiplied to give a “priority score.” While this was useful early on, I found that classifying each task in this way resulted in a lot of decision fatigue and was ultimately unsustainable. YMMV.
very informal/undersupported but I’ve found that creating short feedback loops helps? Things like commitment bets/devices/”I will submit this deliverable in 6 hours regardless of how good it is” tend to force the rational prioritization you seem to be going for.