How to track time without making everything a task

By 6 min read

Most time tracking advice assumes you already know what you’re doing. Pick the task, start the timer, stop it when you’re done. That works beautifully for a well-defined piece of work, and falls apart for most of the rest of the day.

Why task-first time tracking breaks

When an app only lets you track time against a task, three things tend to happen.

  • You invent fake tasks. “Misc.” “Admin.” “Research.” “Calls.” They exist only to give the timer somewhere to live, and they clutter the list you actually plan from.
  • You stop tracking the messy parts. Creating a task before starting a timer is just enough friction that, for anything small or unclear, you don’t bother. The record gets quietly optimistic.
  • The record stops matching reality. At the end of the week you see five tracked hours on a day you know was full. The other three were real work; they just didn’t have a task.

None of these is a discipline problem. It’s a shape problem: the tool expects every hour to look like a task, and plenty of hours don’t.

Three levels to track time at

A better approach is to match the timer to what you actually know at the moment you start it.

Track onUse it whenTypical examples
The dayIt’s a stream of small, unrelated thingsCalls, messages, errands, helping a colleague, admin
A projectYou know the area, not the taskExploring an idea, research, reading around a brief, thinking
A taskThe work is defined and finishable“Draft the proposal,” “Fix the login bug,” “Edit chapter 3”

The rule of thumb: never be more specific than you really are. If you’d have to invent a task name, you’re not at the task level yet. Track the project, or the day, and move on.

What a day looks like this way

Here’s a realistic morning, tracked honestly:

  1. 9:00, task: review a pull request (25 min)
  2. 9:25, project: exploring a new product idea, no tasks yet (1 h 10 min)
  3. 10:35, day: calls, messages, odds and ends (40 min)
  4. 11:15, task: client proposal, first draft (1 h 05 min)
  5. 12:20, project: planning a house move (30 min)

Three hours and fifty minutes, all accounted for, and only two of the five entries were tasks. In a task-only tracker you’d have created three throwaway tasks or lost two hours from the record.

The mix tells you something too

Once you track at all three levels, the proportions become useful on their own:

  • A lot of day-level time usually means a fragmented day. If it keeps happening, that’s a sign to protect a block for focused work, not a sign you were lazy.
  • A lot of project-level time with no tasks means a project is in an exploring phase. That’s healthy for a while. When it lasts weeks, it’s often time to decide what the first concrete task is.
  • Mostly task-level time means your work is well defined right now. Good for estimates, and a great time to compare planned against actual (the loop I describe in time blocking vs. time tracking).

Common mistakes

  • Back-filling with fiction. Retroactively inventing tasks to make the week look tidy defeats the purpose. If it was a day-level hour, let it be one.
  • Splitting hairs. You don’t need a separate entry for every email. Switch timers when your attention switches to a different area, not every time you open a new tab.
  • Never promoting anything. If you’ve tracked the same project with no tasks for a month, take two minutes to write down what you’re actually doing. Sometimes that’s a task waiting to be named.

How this works in Zympl

This is the reason I built Zympl the way it is. Every day in the planner has its own timer and its own note, every project has its own timer, and every task has one too, so you can start the clock at whatever level is true right now. All of them land on the same day, week, and month timeline, and the weekly and monthly reports total everything by project and by task, so the unplanned hours count just as much as the planned ones.

If you want the longer story of why, it’s in Not everything is a task.