The efficiency trap and the backlog that proves it
Burkeman had a line in Four Thousand Weeks that I haven't been able to shake: your inbox is a to-do list anyone in the world can add to. The better you get at clearing it, the more you signal availability, so more stuff arrives. Getting better at the thing makes the problem worse. It's an efficiency trap.
The same logic follows for productivity tools. The better we get at building systems to manage tasks and knowledge, the more friction those systems introduce into their own function — and into our ability to actually access what we stored in them. The tool that was supposed to help you retrieve things becomes the thing you're managing instead.
If you drew that as a graph, you'd get two lines crossing. On one: how efficient the tool is at capture. On the other: the friction it generates just by existing. They intersect at a single point. After that point, the tool's overhead overtakes its usefulness and it effectively collapses under its own weight.
Notion sits right on that edge for a lot of people. You can build extraordinarily intricate systems for knowledge management in Notion — but at a certain complexity level, maintaining the system becomes a job in itself. It stops feeling like productivity and starts feeling like product design.
I've been using Jira for years and have no idea how much has accumulated in there. It all once seemed urgent. Most of it has just been sitting there, quietly not mattering.
I'm thinking of building an agent that approaches the backlog systematically, splitting it into three piles:
- Things other people are actually waiting on — the priority pile.
- Things only I know about and no one is following up on yet.
- Things that have already probably solved themselves, where the move is to scan quickly and let go.
That third category is the interesting one. How do you decide that something in your backlog has already resolved itself?
Captured, processed, and sent,
Zhenia