Why your task list keeps growing (and how to cut it)

I exported my list once and regretted it

A while ago I was switching task apps (a separate mistake) and had to export everything to a spreadsheet first. The file had 140 rows. The oldest was eleven months old and said "look at caching." I had no memory of which project it belonged to, what I had meant by caching, or why it had felt urgent enough to write down.

Out of curiosity I sorted the rows by date and counted. Twenty-three were things I had already done and never ticked. Around thirty were the same intention written two or three different ways ("invoice thing," "send invoice reminder," "chase March invoice"). Forty-odd had no verb at all. They were just nouns sitting there: "backups," "onboarding email," "the API thread." The list was not a list of work. It was a record of every moment I had felt slightly responsible for something.

That spreadsheet changed how I think about task lists. They do not grow because you have too much to do. They grow because adding a line is effortless and removing one requires a decision, and most of us avoid decisions whenever there is a polite way to.

Photograph

Where the growth actually comes from

When I went through those 140 rows, almost every one had arrived by one of four routes.

Topic lines with no first move. "Website." "Caching." "Q3." They cannot be started, so they cannot be finished, so they stay forever. The fix is the rewrite in why remote workers need a clear next action: verb, object, location, or delete it.

Decisions parked as tasks. "Decide on hosting" was on my list for two months. It was not a task. It was a choice I was avoiding, dressed up as work that was waiting for a free afternoon. Decisions need an owner and a date, and if the owner is you, the date should be this week.

No exit. Things went in through chat, email, calls and the shower. Nothing came out except by accident. A list with an inbox and no outbox only goes one way.

Fantasy capacity. On a good morning I would happily put eight hours of tasks onto a day that had five hours of free calendar. Whatever did not fit rolled forward, and the rollover compounded. Planning eight hours into eight hours is the longer version of that trap.

Remote work makes all four worse. Capture is frictionless, because every tool has a "create task" button. Completion is invisible, because nobody sees you finish anything. The list becomes the only visible evidence of your conscientiousness, so it gets longer.

They do not grow because you have too much to do.

Four questions at the door

The cheapest place to stop growth is the moment something arrives. When a new item turns up, I ask once:

1. Is this mine?
2. If yes, what is the first visible action?
3. If no, who owns it, and have I told them?
4. Does it need a date, or can it die now?

If I cannot answer within a couple of minutes, the item is a project, not a task. It goes on a project list with exactly one next action on the daily plan. During a focus block, new things go on a scrap sheet beside the keyboard and get processed in the next message window, not mid-block. A "quick" addition during deep work is list growth in disguise, and it costs you the block as well.

The thing I had to unlearn is that capture is not commitment. Writing something down feels responsible. It is actually a small promise to your future self, and an inbox full of promises with no owners and no dates is how you end up with a row that says "look at caching" for eleven months.

Three containers, not one pile

The other structural fix is refusing to keep everything in one view.

The daily plan holds one primary outcome and two or three secondary items, all startable today. If you need help with the shape, structuring a remote workday covers it.

The backlog holds everything else that is real, sorted by project, and is explicitly not today. It never appears on the same screen as the daily plan. Even if the count stays flat, seeing ninety lines behind your primary makes the primary feel smaller and the day feel hopeless.

The someday pile is not a task list at all. It is a place for ideas that might matter later. I review it monthly, not daily, and nothing goes in without a short note about why it is not happening now. If it grows past one screen, I delete half without rereading. The things that really matter come back on their own. Anything that has survived four monthly reviews untouched was never going to happen, and keeping it is just a way of not saying so.

The daily plan should have one line at the top when you sit down: something that names a finished thing ("PR merged," "email sent," "section drafted for review") rather than an area. The backlog can be as messy as it likes behind that line. The morning only needs the line. If you want a way to judge the day afterwards, busy versus finishing is the scorecard I use.

How the 140 became 19

Here is what the cut actually looked like on that exported spreadsheet, because the numbers surprised me.

I gave myself forty minutes, which was far more than a weekly cut should take but this was eleven months of debt. The twenty-three done items went first. Then I merged the duplicates, which turned about thirty rows into nine. Then I went through the forty-odd noun lines and gave each one about ten seconds: rewrite it as an action, or delete it. Most got deleted. "Backups" became "check last week's backup restored on the test machine." "The API thread" got deleted, because whatever that thread was, it had resolved itself months ago.

The decisions came out next. Five rows were choices, and I moved them into a short list with dates. Three I made on the spot, which removed another handful of tasks that only existed because the decision had not been made.

What was left was nineteen rows. Nineteen real things, each with a first move. I picked tomorrow's primary from those nineteen, not from the 140, and for the first time in weeks the list felt like something I could get to the end of.

The lesson was not that I needed better software. I was literally in the middle of switching software. The lesson was that if an item is not worth a verb and a location, it is not worth a row.

The client who adds one small thing a day

The other kind of growth comes from outside. On one maintenance retainer, a client would send one "tiny" request a day: change this button colour, move this paragraph, can the footer say something different. Each was a five-minute job. Each got its own line. Within a month there were forty open items, and the actual milestone for that month, a booking form, kept slipping behind them because the small things always felt more finishable.

What fixed it was batching. Small requests went into one list that I worked through on Friday mornings, and the primary for every other day stayed the milestone. I told the client this plainly, and they were fine with it. Most clients just want to know their request has been seen and when it will be done. Without that window, my list had quietly become their unlimited free bucket, and neither of us had decided that on purpose.

Team boards have the same problem in a different shape. If you assign yourself every interesting ticket, you can end up with twelve "in progress" items and none moving. I cap my own active work at three. Anything beyond that is either unassigned or scheduled, and if something urgent arrives, something else gets explicitly parked with a note to whoever was expecting it: "Pulling the payment fix ahead; the FAQ page moves to next week."

The weekly cut template

Once a week, usually Friday afternoon, I run this. It takes fifteen minutes on a normal week. If it routinely takes an hour, capture is too loose, and the fix is to capture less rather than cut harder. Notes that are not tasks belong somewhere else, as in useful work notes without a second Notion.

WEEKLY CUT (15 minutes, then stop)

For each line in the backlog, do exactly one:

Done already:          delete
Not mine:              tell the owner, then delete
No verb:               rewrite as an action, or delete
No date, not someday:  give it a date, or delete
Duplicate:             merge into one line
Someday:               move to the someday pile with a one-line why
Active:                keep only if under 3 active; otherwise park
                       it and tell whoever was expecting it

When the timer ends, stop. Leftovers wait for next week.

The rule that matters most is the last one. A thorough cut that you skip because it feels too big loses to a rough cut that happens every Friday. In a crunch week I shrink it to ten minutes and delete more aggressively, because keeping the habit alive matters more than doing it well. Why productivity systems fail after the first week is mostly about that tradeoff.

Deleting is the work

The hardest part of all this is emotional, not procedural. Deleting a line feels like admitting you will not do the thing. That is exactly what it is, and it is fine. Leaving the line there does not mean you will do it. It means you will feel vaguely bad about it every time you scroll past, for months.

So I count removals as progress. A Friday where I delete twenty lines and finish two things is a good Friday. If the list keeps growing while the one line at the top stays empty, I am collecting, not working, and no app has ever fixed that for me.