I Accidentally Stopped Using My To-Do List
Listen
I stopped managing tasks and started building systems, and my main productivity app got less important as a result. For most of my career, productivity was a memory problem. Every morning I'd ask what I should be working on, what I was forgetting, what I'd promised someone. A lot of my energy went to remembering problems, not solving them. That's mostly gone now, and the reason is that I stopped treating recurring problems as tasks to remember and started treating them as capabilities to build.
A year ago I spent most days re-deriving what mattered. Today the work runs whether I'm pushing on it or not.
Why are recurring tasks the wrong unit?
Most productivity systems are built around tasks: capture it, prioritize it, complete it, check it off. But a lot of tasks are recurring problems in disguise.
Take an Amazon scorecard. The default move is a monthly reminder: "prepare Amazon report." I used to do that. Now when something recurs, my first question is why it's a task at all. Instead of a reminder, I open Claude Code and build. The first version saves a little time. The third version is automated. The fourth gets handed to my VA, Ann. Eventually I only get involved when something unusual happens. The task is gone. What's left is a capability.
What changes when you build capabilities instead of completing tasks?
The default response to a problem used to be "I should remember to do this." Now it's "how do I make sure nobody has to remember this again?" That shift shows up everywhere.
| Problem | Old response | New response |
|---|---|---|
| Agency selection | Decide case by case | A decision framework |
| Amazon reporting | Monthly recurring task | An automated scorecard |
| Business evaluations | Start from scratch each time | A repeatable system |
| Health routines | Remember the steps | Written SOPs |
| Vendor management | Track it in my head | An operating system |
The goal stopped being completing work. It became converting work into infrastructure.
Isn't the value just AI automation?
No. People assume the leverage comes from an agent saving me thirty minutes. The real leverage is that I never have to re-derive the same solution. Every recurring problem solved once becomes a permanent asset. Every framework becomes memory I can reuse, delegate, or automate later. The second time is easier than the first. The tenth time, the problem has almost disappeared.
The emotional change surprised me: I feel calm. Not because there's less work, there's more than ever. Agents run, reports update, apps monitor, Ann handles recurring workflows. Progress happens when I'm not pushing. A year ago, stopping felt like falling behind. Now stopping usually means the systems keep doing what they were built to do.
What's the new bottleneck?
Deciding what deserves to become infrastructure. Remembering tasks isn't the constraint anymore, and execution is becoming less of one too. But not every problem should become an app, not every workflow an operating system, not every decision automated. The highest-leverage work is spotting the recurring problems worth a permanent solution. That's where my time goes now.
The shift, in one line: I stopped acting like a task manager and started acting like an architect. An operator asks what to do today. An architect asks why a problem keeps appearing and how to make it disappear for good. I'm not interested in bigger to-do lists. I'm interested in systems that make the list shorter every month. Once you've felt that, it's hard to go back.
Frequently asked questions
Does this mean to-do lists are useless? No. You still need to capture what's in front of you. The point is to treat a recurring task as a signal that something should be built once, not remembered forever.
How do you decide what to turn into a system? Frequency and cost. If a problem returns on a schedule and re-solving it each time is expensive or error-prone, it's a candidate. One-off problems stay as tasks.
Doesn't building systems take more time than just doing the task? The first build usually does. It pays back by the third or fourth cycle, and after that the problem mostly runs itself or gets delegated.