To Go Fast, Go Implicit
To Go Fast, Go Implicit
Smart Defaults For Smart People
A lot of advice on personal performance revolves around adding things to ones system—a novel method here, an extra step there, some fancy tweaks in several places. Maybe because, generally speaking, adding is so much easier than removing.
When we add, we move toward more sophistication. Which usually feels good. It feels like progress. Yet every addition, no matter how small, has the potential to create friction. Not only in the beginning when things are vetted and smoothed out but also in the longer game. Simply because many small things eventually burden the whole, making our overall system more fragile.
This is why I found that some of the smartest and most sustainable moves in productivity involve stripping away instead of sticking in. They are not about sophistication, but about moving towards simpler and leaner setups.
Tagging serves as a great illustration here. Some people have abandoned tags because they foster an “adding” mentality. Every novel use case prompts the addition of yet another new tag, and before you know it, you end up with similarly spelled or misspelled tags or with different tags referring to the same thing. If ones doesn’t actively fight tag inflation, this leads to an ever-expanding and unwieldy system.
However, as I’ve discussed, tags by themselves aren’t bad. The culprit, most of the time, is the wrong strategic tagging approach:
I believe you can build an antifragile tagging system with “kaizen” in mind. Such a system defaults to “no tag”, is triggered by your workflows, is automated and templated where possible, is deliberate where useful, is pruned opportunistically, and makes every tag count. With such a system there is no upfront setup of a perfect tag hierarchy. You start on a green field and build up as your needs require it. And just like with folders, tags evolve over time.
The key point of this example: to build a lasting tagging system, start with the unintuitive premise that most taggable things won’t have any tags and that most things will not only start but also remain tag-free. This defensive approach leads to a much more maintainable system. It normalizes “no tag” and makes it the “default.”
Smart Defaults are practical protocols that let us turn explicit action into implicit workflows. When no-tag becomes the pre-selected choice we no longer actively need to make decicions about tagging in most cases. It’s a smart standard deliberately designed to guide oneself toward beneficial outcomes.
Let’s look at a few more examples.
Task Manager
Consider your task management system. Let’s say you use quick capture to add new task artifacts to your inbox. During your review process, you tag them with “action” labels, such as “read” for articles. This helps you quickly find and batch-process tasks based on their execution context. However, you can streamline this further with smart defaults. In Todoist, for instance, instead of tagging an article “read,” you could move it to a “to-read” project.1 This way, the task's location (which project it is assigned to) implies the action. If blog posts are the most common kind of link you save, you could even default to viewing any task artifact that only contains a link as a description as a “to read” item. Then, neither a tag nor a specific project is needed. This approach embodies the essence of a smart default—no work is needed in the ordinary case; only exceptional cases need handling. This means that I have to do nothing in most cases, and in addition, it makes the outliers more meaningful.
Calendar
During my weekly review, I schedule gym workouts for the week. I distribute three events (upper body, lower body, full body) around noon on the three most fitting days of that particular week. Without defaults, I would have to create or copy these calendar events every week anew. Instead, I use a smart default. I have these events defined as weekly recurring events. So, every new week, I automatically have an event set for Mondays, Wednesdays, and Fridays. With this approach, during my weekly planning session, I only have to move these events around (and many times, I don’t have to do anything, as no other meetings sit at lunchtime). The best thing about smart defaults, in this case, is that whenever they let you eliminate the human component on a critical point, they let you eliminate potential mistakes involving manual action. The recurring events stare me right in the face when I open my calendar. So, the smart default prevents me from forgetting to schedule them; they make my setup more robust.
Note Formatting
I spent much time in my personal knowledge companion, Obsidian. Most of what I do in Obsidian involves editing text in Markdown format. However, text and notes are finicky, and if I don’t rely on smart defaults, all my notes end up looking different. Some will use big headings, others small ones. Some will include note metadata; others won’t. Some bullet lists will be formatted with - and others with *. These diffs may seem trivial, but if you like to have a consistent touch and feel to your notes, you may end up formatting and reformatting your notes a lot. And unlike the examples above, reformatting notes is a huge time sink. It has value, but it’s not worth the manual effort. So, what’s the smart default here? It is to define a fixed protocol for how your notes should look by default. For instance, do not use H1 headings; always use - instead of * to denote bullet lists and * instead of _ for italicizing text. Committing to a style is very helpful, but it still involves your manual work to follow it. So, to make formatting truly implicit, you can use templates and an Obsidian Plugin like Linter, which performs the formatting according to your rules for you, whenever you trigger a certain command. Using a tool-enforced default style, you can save time and enforce a consistent style.
Many times in life, we must turn implicit into something explicit to learn about ourselves and to improve. But here, during execution, we sometimes need to move in the opposite direction. We need to explicitly build implicit tactics. We need to design and build workflows based on “no action.” We need to automate things. We need to switch between opt-in & opt-out workflows. Many of these changes are simple, yet not immediately obvious and visible to us. So, whenever we find yourself tweaking & tuning our system, it’s helpful to remember the following question:
Can I solve this with a smart default instead?
Because if we want to go fast, we need to go implicit.
I’m curious: What are some of the defaults in your system and worklows?
In Todoist, every task needs to be inside a project bucket, so if I tag a task “read,” I additionally also need to move it to some project. Instead of having a “to-read” project, I only have to do one of these two things.