Stop Tracking How Many Tasks You Complete. It’s Making You Do the Wrong Ones.

Last March I closed 47 tasks in a single week. I was at my desk past seven every night. My to-do app showed an impressive streak of crossed-off lines. I’d cleared my inbox to zero twice. By Friday I felt destroyed.

I also moved exactly zero things that mattered.

The feature spec I was supposed to be writing? Untouched. The hard customer conversation I’d been deferring? Still on next week’s list. The strategic note my manager had asked for? Three sentences and a placeholder. What I’d done all week was answer 23 emails, file 8 sets of meeting notes, post 4 status updates in Slack, make 6 minor edits to a doc that wasn’t urgent, and respond to roughly a dozen small Slack threads that could have waited a month.

Forty-seven completed tasks. Zero needles moved.

I’ve spent the last decade in cross-functional roles. Product, sales, customer success, marketing, growth. I’ve launched 30+ features and watched most of them flop. I’ve also built personal measurement systems for myself and watched them quietly shape what I did with my time, sometimes in directions I didn’t intend. The week of 47 tasks was the cleanest example I’d seen of a metric actively making me worse at my job.

The metric was task count. The metric was the problem.

TLDR

Task count is a vanity metric. It rewards completion regardless of importance, so under any amount of pressure you reach for whatever’s easiest, and your week ends with a long record of finished things that didn’t matter. Track three things instead. Hours on the one project that defines your week. Things you actually shipped (output someone else can see). Whether the hardest thing on your list got done before the easiest. Stop padding the list to feel busy. Stop counting administrative work the same as creative work. Task count IS the right metric if your work is genuinely uniform (support tickets, QA queues, a stream of identical requests). For everything else, it’s misleading you about whether your week was real.

How a metric quietly shapes what you do all day

Here’s the thing about measurement. The number you track is rarely the most interesting thing about it. The most interesting thing is the behaviour the number quietly produces.

If you track tasks completed, you do tasks that are easy to complete. Not consciously. The brain rewards completion with a small dopamine hit, and it doesn’t audit whether the completed thing was important. The reward is the same for “wrote a critical product spec” and “replied to the Calendly reminder.” So under pressure (and most of us are under some kind of pressure most of the week), the easier completion wins.

This is a well-trodden idea in economics. When a measure becomes a target, it stops being a good measure. The version of that idea most people know is Goodhart’s law, and the example most people remember involves Soviet nail factories making thousands of tiny useless nails to hit their production count. The factory floor analogue of my week of 47 tasks. The point isn’t that workers were lazy. The point is that the measurement decided what “good work” meant, and the workers complied.

Task count has three properties that make it especially bad as a productivity metric for knowledge work.

First, it’s trivially gameable. You can triple your count before lunch by splitting one task into three subtasks. “Email Sarah” becomes “draft email to Sarah,” “review email to Sarah,” “send email to Sarah.” The work didn’t change. The number tripled. Most of the time you can’t even catch yourself doing this, because the granularity that inflates the count is also the granularity that helps you plan. Most splits are padding.

Second, it mixes trivial and critical at the same weight. A 6-hour piece of focused thinking on a hard problem counts as one completion. So does “respond to slack ping.” A productive day measured in tasks looks identical whether you wrote one important thing or thirty unimportant ones. The metric strips out the only information that mattered.

Third, and this is the one I find most uncomfortable, task count is the most reliable disguise for avoidance I’ve ever seen. There’s a real psychological pattern here. Researchers sometimes call it productive procrastination, or procrastivity. You put off the priority task by escaping into other tasks that still feel productive. You answer emails instead of writing the spec. You file notes instead of having the hard conversation. You make tiny doc edits instead of the structural rewrite. From the outside, and from inside your own to-do app, you look busy and productive. You’re not. You’re avoiding. The list of finished tasks is the receipt for the avoidance.

I’d been writing about this pattern for years before I caught myself doing it. After the 47-task week, I went hunting in a GTD forum and found a post from someone who’d checked off 230 items in a month: roller blind, phone top-up, gym, shopping. In their own words, “what I’m not achieving are more important things, writing some software, more learning I want to do, some creative writing.” The list of completed things and the list of important things had completely diverged.

The honest read of my week wasn’t that I’d been productive. It was that I’d built a record of avoidance. The record just happened to look like productivity from the outside, and my measurement system kept congratulating me for it.

What I track instead

When I stopped tracking task count, I needed three things to replace it. Not five. Not seven. Three numbers that, between them, tell me whether the week was real.

Hours on the one project that defines your week

What it is. On Monday morning I name the single project that, if it moved this week, would make the week count. Then on Friday I look at how many hours I actually spent on it.

Why it matters. Aggregate “focus time” or “deep work hours” is too generous a category. It includes focused work on the wrong thing. The honest question is how much of your week landed on the one project that actually defines whether the week mattered. Most weeks the answer is shockingly low. Mine averaged about 4 hours when I first started measuring. That number is not impressive. It’s also probably typical. The lever is not “work harder.” The lever is “stop letting the other 36 hours hide the fact that the one project that mattered got 4.”

The tactic. Name the project before Monday morning is over. Not a category (“product strategy”). The specific thing (“the launch spec for the Q3 release”). Then look at where your calendar and your real time actually went on Friday afternoon. The first few weeks the gap is uncomfortable. That’s the point. The discomfort is the signal.

The common mistake. People name three or four “priority projects” instead of one. Then every week some subset of them gets time and the rest don’t, and you can always claim partial victory. The single-project rule prevents that. Pick one. Defend it. Or admit you can’t, which is also useful information.

Where a tool helps. A time tracker that categorises by project automatically saves you from the worst version of this, which is end-of-week guessing. I cover the specific tools in the dashboard section below. The short version: automatic tracking beats manual timers because most people don’t press the button consistently.

Things shipped, not things touched

What it is. By Friday, what produced output that someone else can see. A draft that someone else read. A decision sent in writing. A spec that’s been reviewed. A piece of code merged. A question answered for a customer. Something that has crossed from your head into the world.

Why it matters. Most knowledge work is reversible up until the moment it ships. You can polish a draft forever and call it work. None of it counts as moving the needle until someone outside your own head has seen it. “Shipped” is a brutally honest filter.

The tactic. On Friday afternoon, list the things that crossed the line. Sent. Posted. Merged. Reviewed by someone other than you. Decisions in writing count. Half-finished drafts don’t. There’s no minimum number. Some weeks I ship two things and they’re the right two. Some weeks I ship eleven things and they’re trivial, in which case the count is a warning, not a brag.

The common mistake. Treating “ready to ship” the same as “shipped.” A draft sitting in your folder marked “for review Monday” doesn’t count. If it’s the most important thing you did this week, send it. The friction between “ready” and “sent” is usually where avoidance lives, and shipping is what punctures it.

Whether the hardest thing got done before the easiest

What it is. A simple sequence check. On each day this week, was the hardest thing on your list the first thing you worked on, or the last? Or did it not get worked on at all?

Why it matters. Sequence is a signal. If your easy tasks consistently finish first, that’s not productivity. That’s avoidance with extra steps. You’re warming up by doing them, telling yourself the hard thing needs the right energy or one more piece of information, and then at 4pm the hard thing rolls to tomorrow. Tomorrow becomes Friday. Friday becomes next week. Track this and you find out very quickly whether you’re prioritising or rationalising.

The tactic. At the end of each day, mark one of three things on a sticky note or in a journal. “Hard thing first.” “Hard thing later.” “Hard thing not at all.” Three days of “later” or “not at all” in a row, the next morning starts with the hard thing, no exceptions. No checking email first. No “just one quick reply.” The discipline is in the sequence, not in the volume.

The common mistake. Confusing “uncomfortable” with “hard.” Hard means cognitively demanding, ambiguous, or high-stakes. Uncomfortable means you’ve been avoiding it because it’s awkward, like an apology email or a difficult conversation. Track both, but separately. The fixes are different.

Where a tool helps. Honestly, this one doesn’t need a tool. A sticky note or a one-line entry at the bottom of a daily journal file is enough. I keep a plain markdown file on my desktop with three lines per day. That’s it. If you find yourself searching for “the right app” to track sequence, you’ve already drifted back into the same pattern this article is trying to interrupt.

What to stop tracking, doing, and feeling responsible for

Telling you what to add isn’t enough. The space these new metrics take up has to come from somewhere.

Stop padding the list to feel busy. If you find yourself adding a task to your list specifically so you can cross it off (“brush teeth,” “make coffee,” “check email”), you’re not measuring your work. You’re medicating an emotion with checkboxes. The dopamine is real. The signal is fake.

Stop counting administrative work the same as creative work. Answering routine emails is not the same kind of work as writing a strategic brief. Treating them as equivalent units distorts the picture. If you have to track admin (some weeks you do, especially after a holiday), track it separately and never let the admin number reassure you about the work that actually mattered.

Stop measuring your day by checkmark volume. A day with 4 checkmarks can be the best day of your quarter. A day with 27 checkmarks can be a write-off. The number is decoration. It doesn’t tell you anything you can act on tomorrow.

Stop the Sunday-night dread that comes from a long list inherited from a longer one. Once a week, prune the list. If something has rolled over four weeks in a row, either schedule it, delegate it, or delete it. Not deciding is itself a decision, and the decision is usually “I won’t do this,” dressed up as “I’ll do this later.”

Stop checking your task list more than twice a day. Once in the morning to set sequence. Once at end of day to mark the sequence check. Anything in between is decoration. The list checking the list checking the list is a closed loop that produces a feeling of work without producing any.

When task count IS the right metric

I want to be careful here, because the entire piece would sound contrarian without this section. Task count is not always a bad metric. There are situations where it’s the right one, and saying otherwise would be dishonest.

Task count is genuinely informative when your work is uniform. Support tickets where each one is roughly the same size. QA passes through a queue. Processing a backlog of customer requests with similar weight. Moderation workflows. Order fulfilment. The work is a stream of similar items and the question of “which item to pick” matters less than “how many got through.” In those situations, count is a real signal.

The trap is treating knowledge work like uniform work because it makes the measurement easier. Most knowledge work has a 10x or 100x range in item importance. A spec is not the same size as a Slack reply. Counting them at equal weight isn’t simplifying. It’s lying to yourself.

My take, which is probably an unpopular one: if you can honestly look at your last week’s task list and say each item was within 2x or 3x of every other item in importance, count is fine. For everyone else, the count is decoration, and you can prove it to yourself by asking whether the count predicted anything useful about your week. Mine didn’t.

The simplest dashboard for this

I want to keep this section short, because the point of the article is that the apps were never the answer. Two tools and a piece of paper.

For the time-on-the-one-project metric, you need something that tells you where your hours actually went. Rize runs in the background and categorises by project using what’s on your screen. It costs $16.99/month for the individual plan, less with annual billing. The cheaper alternative is Toggl Track’s free plan, which is genuinely usable for a solo workflow. The trade-off is that Toggl needs you to start and stop the timer, and most people don’t. Automatic tracking exists because most people don’t.

For the things-shipped count and the hardest-thing-first check, I use a plain markdown file. No app. No template. Three lines per day. Friday afternoon I scroll back through the week. That’s it. I tried building this in three different tools before realising the tools were part of the problem the article describes. A note app that gamifies completion will sneak its measurement back into your week. A markdown file won’t.

I run a Raycast snippet that opens the markdown file with a single shortcut, because the friction of opening it was the only reason I ever skipped the Friday check. Raycast is free for personal use; if you don’t already have it, anything that opens a file with one keystroke does the job.

That’s the entire stack. One automatic time tracker. One markdown file. One shortcut. The rest is the discipline of looking at the file on Friday.

What changed when I switched

I want to be honest about this part, because the easy thing to write is “everything got better.”

The first three weeks were uncomfortable. My “hours on the one project” number was around 4. Hardest thing first about twice a week. Shipped count was four or five, but two were drafts that should have been sent the week before. None of those numbers felt like wins. They felt like a confession.

The fourth week, the numbers started to move because the measurement started to drag the behaviour. Hours on the priority project went to 8. Hardest thing first hit 4 out of 5 days. Shipped count dropped to three but they were the right three. By week eight I was averaging 12 hours on the priority project per week, which is not a lot in absolute terms but is three times my baseline.

What didn’t happen: I didn’t start working more hours. The total time in the week was roughly the same. The 47-task week and the 12-hours-on-priority week were the same number of working hours. The difference was where the hours landed. Pick metrics that can’t reward avoidance, and the avoidance becomes visible. Visible avoidance is fixable. Invisible avoidance, dressed up as 47 completed tasks, is not.

FAQ

What if my job genuinely is doing lots of small tasks? Then task count is probably the right metric for the bulk of your week. The test is whether the items on your list are within 2x or 3x of each other in importance. Support tickets, queues, moderation, processing work, that’s the regime where count is honest. For mixed work, count is misleading because it averages a 10x importance range into a single number.

How is this different from time-blocking? Time-blocking is a scheduling tactic. What I’m describing is a measurement system. They can coexist. Time-blocking decides when work happens. The measurement decides whether the work that happened was the right work. Most time-blocking systems still use task count as the success metric, which is exactly the problem this article is about.

Doesn’t this just replace one metric with three? It does. The difference is that the three metrics are harder to game and easier to act on. Hours on a single named project can’t be inflated by splitting tasks. Things shipped can’t be inflated by polishing. Sequence can’t be faked because either the hard thing happened first or it didn’t. Three metrics that can’t be gamed beat one metric that can.

What about Eisenhower matrices and other priority frameworks? Those help with sorting. They don’t tell you whether your week was real. You can sort everything correctly and still spend the week on the urgent-but-unimportant column, and a sorting framework won’t catch you. The measurement catches you. They’re not competitors. They’re complementary.

How do I track “things shipped” without it becoming another vanity metric? The discipline is in what counts. Internal drafts don’t count. Things “ready to send” don’t count. Only output that has crossed from your work into someone else’s hands counts. If you find yourself padding the shipped count by lowering the bar for what counts as shipped, that’s a behaviour signal worth paying attention to, and probably the same instinct that produced the 47-task week in the first place.

What if my manager tracks task count? Then by all means show them a high task count, but don’t run your own measurement system on it. Keep your private numbers. Hours on priority, things shipped, hardest first. Use those to decide what to work on. Use the task count to satisfy the reporting requirement. The two don’t have to be the same.

How long before I see a difference? Three to four weeks before the numbers start moving in a useful direction. The first two weeks are mostly diagnostic: you’re finding out where your time actually went, and the answer is often unflattering. Past the diagnostic phase, the measurement starts dragging the behaviour, and the change shows up in priority project hours first.

What if my role is high-volume by design (e.g. sales, support, recruiting)? Run two systems. Volume metric for the uniform stuff (calls made, tickets closed, candidates screened). The three metrics above for the work that isn’t uniform: the deal that needs a strategic conversation, the escalated ticket, the candidate who needs real nurture. The non-volume work is always the stuff that gets lost in the count.

Is the markdown file really enough? No tags, no structure? Three lines per day, Friday afternoon review. That’s enough. The tooling rabbit hole is one of the failure modes the article warns about. If you’re spending more than two minutes a day on the system, the system has become the work. Strip it back until it’s barely there.

What’s the one number to start with if I can only track one? Hours on the one project that defines your week. It’s the most useful of the three because it forces the question “what is the one project?” which most people can’t actually answer cleanly. If you can’t name the one project on Monday morning, the lack of an answer is itself the diagnostic, and the rest follows from there.