When you search for "time tracking," you find two families of tools that seem to do the same thing but rest on radically different philosophies. On one side, project management tools that added a time tracking feature. On the other, tools designed for tracking time as it's actually lived. The difference seems subtle. In reality, it changes everything: how teams enter data, the quality of collected data, and ultimately the reliability of the decisions that follow.
The top-down approach: time as a resource to plan
Most time tracking tools were born in the project management world. Their reasoning goes like this: you have a project, the project contains tasks, each task has an estimated duration. Time tracking means assigning hours to those planned tasks.
This is a top-down approach:
Project → Phase → Task → "I allocate time to it"
In this model, the starting point is the project tree. The user opens a project, navigates through its phases, finds the right task, and records hours against it. Time is treated as a resource to allocate, like a budget to distribute.
This approach has an obvious merit: it's consistent with how a project manager thinks. It allows comparing actuals to estimates task by task. It produces Gantt charts and burndown charts. It satisfies managers who want to know "where the project stands."
But it has a fundamental flaw: that's not how people experience their day.
The bottom-up approach: time lived in real time
A team member's day doesn't look like a project tree. It looks like a flow. You arrive in the morning, handle emails, join a meeting, code for an hour, get interrupted by a colleague's question, switch to another topic, do a code review, prepare a demo.
Time imputation starts from this reality:
My day → "I note what I do as it happens" → It gets allocated to projects afterward
The starting point isn't the project. It's the flow of the day as it unfolds. The user doesn't ask "which task in project X did I work on?" They ask "what did I do between 9 and 10 AM?" and note it down. Allocation to projects happens naturally, as a consequence, not a prerequisite.
Why the difference matters in practice
The distinction might seem philosophical. It isn't. It has direct and measurable consequences on three critical dimensions.
1. Adoption rate
The number one obstacle in time tracking is that teams don't use it. And the primary reason they don't is friction at the point of entry.
In a top-down tool, recording an hour requires:
- Opening the tool
- Finding the right project (among 10, 20, 50)
- Finding the right phase or milestone
- Finding the right task
- Entering the duration
Five steps before recording anything. If a team member works on 3 projects in a day, they do this 3 times. If they forgot to enter and are catching up on Friday, they must mentally reconstruct their days AND navigate the tree structures.
In a bottom-up tool, entry follows the day's rhythm:
- Open the tool (today's view is already displayed)
- Fill in slots as the day progresses
Two steps. Context is immediate: it's today, it's now. The project and task are attributes you assign, not doors you walk through.
Field observation: tools that start from the calendar or daily view show daily entry rates of 80-90%. Tools that start from the project tree drop to 50-60%, with massive catch-up sessions on Fridays.
2. Data quality
Delayed entry means degraded entry. Studies show that beyond 24 hours of delay, the error rate on reported durations reaches 15-20%. Beyond 3 days, it exceeds 30%.
The bottom-up approach naturally encourages real-time entry because it mirrors lived experience. "What am I doing right now?" is a question anyone can answer effortlessly. "How much time did I spend Tuesday on task #47 of project X?" requires a memory reconstruction effort.
3. Coverage of actual time
The top-down approach creates a structural blind spot: time that doesn't fit into any planned task. Cross-functional meetings, admin work, learning, mentoring, interruptions. In a project-centered tool, these activities have no natural place. Result: they don't get recorded.
The bottom-up approach doesn't have this problem. The day has 8 hours, the team member fills 8 hours. Everything goes in -- including what wasn't planned. It's precisely this completeness that makes it possible to understand where non-productive time goes and act on it.
The hybrid tool trap
Faced with this reality, some tools try to combine both approaches. They offer a calendar view AND a project view, a timer AND manual entry, a timeline AND a tree structure.
The result is often a complex tool that does neither well. Users don't know where to start. Supervisors don't know which view is authoritative. Data gets entered inconsistently across team members -- some start from the calendar, others from the tree -- making aggregations unreliable.
A good time tracking tool must make a clear choice about its primary logic. Not because the other logic is bad, but because the entry experience must be unambiguous for the data to be reliable.
Which paradigm for which need?
The two approaches don't serve the same situations.
| Criterion | Top-down (project management) | Bottom-up (imputation) |
|---|---|---|
| Starting point | The project tree | The team member's day |
| Central question | "How much time on this task?" | "What did I do today?" |
| Ideal for | Tracking project progress with planned deliverables | Tracking actual time spent, billing, profitability |
| Entry frequency | Often weekly (catch-up) | Daily (as it happens) |
| Covers non-project time | With difficulty | Naturally |
| Data quality | Variable (depends on discipline) | High (immediate entry) |
| Entry complexity | High (tree navigation) | Low (fill your day) |
If your primary need is tracking project progress -- knowing if tasks are on schedule, redistributing resources -- a project management tool with built-in time tracking may work.
If your primary need is knowing where time goes -- billing correctly, measuring profitability, understanding actual workload -- the bottom-up approach is superior.
And in most service companies (agencies, IT consultancies, architecture firms, engineering offices), it's the second need that's critical. You don't manage a project with a stopwatch. You manage profitability with reliable time data.
Imputation in daily practice: what it actually looks like
Take Mathilde, a UX designer in an 8-person agency. Her typical day:
- 9:00-9:30 AM: emails + Slack → she notes "Communication" on her morning slot
- 9:30-11:00 AM: wireframes for the Vauban project → she fills 6 fifteen-minute pills on the project, "Mockups" milestone
- 11:00-11:30 AM: team meeting → 2 pills on "Internal"
- 11:30 AM-12:30 PM: mockup review for the NovaTech project → 4 pills, "Validation" milestone
- 2:00-4:00 PM: Figma prototyping for Vauban → 8 pills, same milestone
- 4:00-4:45 PM: NovaTech client call → 3 pills, "Follow-up" milestone
- 4:45-5:30 PM: admin + research → 3 pills on "Internal"
At 5:30 PM, her day is complete. 8 hours filled, spread across 3 projects and internal time. She never needed to navigate a task tree. She simply noted what she was doing, slot by slot, as the day progressed.
The next morning, her manager opens the dashboard and instantly sees: Vauban consumed 3h30, NovaTech 1h45, the rest is internal time. This data is reliable because it was entered in real time, not reconstructed on Friday evening.
Conclusion: choose the logic that matches your reality
The choice between top-down and bottom-up isn't a theoretical debate. It's a practical decision that determines whether your team will actually use the tool, and whether the data it produces will be actionable.
If you recognize your daily reality in the imputation logic -- varied days, multiple projects, the need to know where every hour goes -- then look for a tool designed for that. Not a PM tool that also does time tracking as an option, but a tool whose entry experience is built around your day.
That's exactly the philosophy behind the 15-minute pill system: an interface that follows the flow of your day, not the tree structure of your projects. Time flows up naturally to projects, milestones, profitability reports -- but the starting point is always your lived experience.