You open a task to check how it is going and find fourteen sub-tasks. Six are done, three are assigned to someone who left the project last month, and two say "misc fixes". Is the task nearly finished or barely started? You cannot tell without asking.

Or the opposite happens. A task called "Launch landing page" has sat at "In progress" for two weeks. It hides a dozen steps, three people and a client approval, and none of that is visible.

Both are the same problem from different directions. Work has been broken down to the wrong level. This article explains why that happens and offers a simple way to decide when a piece of work deserves a sub-task and when a plain checklist will do.

Why breakdowns drift into noise or go missing

Most teams do not choose a level of detail on purpose. It emerges from habits, and a few habits do most of the damage.

  • Splitting feels like progress. Turning a vague task into ten small ones feels productive, even when nobody needed ten items to track.
  • Leads want visibility. If the only way to see what someone is doing is through sub-tasks, people start creating sub-tasks for the lead rather than for the work.
  • Tools make creation cheap. Adding an item takes seconds. Closing, reassigning and cleaning up items takes much longer, so the debris builds up.
  • Big tasks feel safe. On the other side, a single large task avoids the admin of splitting. It also hides blockers until the deadline is close.

The underlying issue is that sub-tasks and checklists are being used as if they are the same thing. They are not. They answer different questions.

The test: does this piece need its own owner, status or time?

A sub-task is a small piece of work that has its own life. A checklist item is a reminder of a step inside one person's work. A quick way to tell them apart is to ask four questions about each piece.

  1. Will someone other than the parent's owner do it? If a different person is responsible, it needs its own assignee.
  2. Can it be blocked or finished independently? If it might sit waiting on a client or another team while the rest moves on, it needs its own status.
  3. Will it need its own conversation or files? If people will discuss it, attach drafts to it or ask questions about it, give it a place for that.
  4. Does its time need to be tracked separately? If you bill for it, estimate it or want to see how long it took, it needs its own time logs.

If the answer to any of these is yes, make it a sub-task. If all four are no, it is a checklist item. That usually means it is done by the same person, in the same sitting, and takes minutes rather than days.

In Tilvin, this test maps directly to what a sub-task carries: its own assignees, status, comments, files and time logs. If a piece of work does not need any of those, a sub-task is just overhead. A short list in the task's first comment, or a reusable checklist kept on a project notebook page, does the job with less clutter.

A worked example: one homepage redesign, two ways

Picture a six-person design agency redesigning a client's homepage. The lead creates a task called "Homepage redesign" and starts breaking it down.

The noisy version

Sixteen sub-tasks: "Open Figma file", "Check brand colours", "Draft hero", "Draft features section", "Export images", "Compress images", "Upload images", "Write alt text", "Send to client", and so on. Most belong to the same designer and take under an hour. The designer ticks them off in batches at the end of the day, so the list tells the lead nothing in real time. Worse, the two items that actually matter, client approval and the developer build, look no different from "Compress images".

The useful version

Four sub-tasks, each passing the test:

  • Design homepage mock-up, assigned to the designer, with draft files attached and its own time logs.
  • Write homepage copy, assigned to the copywriter, with its own discussion about tone.
  • Client review and sign-off, owned by the account lead, because it can be blocked independently and often is.
  • Build homepage, assigned to the developer, starting once sign-off is done.

Inside "Design homepage mock-up", the designer keeps a short checklist: check brand colours, export and compress images, write alt text. Those steps matter, but they are the designer's own working steps. Nobody else needs to track them.

Now a glance at the parent tells the lead exactly where things stand: copy is done, design is in review, the build has not started. That is the visibility the noisy version promised and failed to deliver.

Rules of thumb that keep breakdowns useful

The test handles most decisions. A few working rules handle the rest.

  • Aim for roughly three to seven sub-tasks. Fewer than three often means the parent did not need splitting. More than seven usually means some items are really checklist steps, or the parent is really two tasks.
  • Name sub-tasks as outcomes. "Client signs off homepage" is clearer than "Client stuff". If you cannot name an outcome, it probably is not a sub-task.
  • Do not use sub-tasks as a status report. If you want to know how someone is getting on, ask in the task's discussion or look at progress and dates. Asking for more sub-tasks just creates admin. We cover this in more depth in how to track project progress without micromanaging your team.
  • Review generated breakdowns before accepting them. Tilvin's AI task generation can propose tasks and sub-tasks from pasted meeting notes or an email, and you review them before anything is created. That review step is where you apply the test: merge small items into checklists and delete anything nobody owns. Our guide on turning messy meeting notes into clean tasks walks through that process.
  • Keep repeat checklists in one place. If the same steps come up on every task of a kind, such as a pre-launch check, write them once on a notebook page rather than recreating them as sub-tasks each time.

Signs your current breakdown is not working

You do not need a big review to spot trouble. Look for these signals in a project you already run.

  • Sub-tasks closed in bulk. If ten items are marked done within the same few minutes, they were checklist steps posing as sub-tasks.
  • Discussion about a sub-task happening on the parent. This suggests the sub-task is missing an owner or a clear scope, or should not exist at all.
  • Parent tasks stuck in progress for weeks with no sub-tasks. Something with several owners or an external dependency is hiding inside.
  • Workload reports that do not match reality. If the team workload report shows someone as lightly loaded while they say they are swamped, their real work is probably buried in a large task assigned to someone else.
  • Orphaned items. Sub-tasks assigned to people no longer on the project, or with dates long past, are a sign of breakdown done once and never maintained.

Next steps for this week

You do not need to restructure every project. Start small and let the habit spread.

  1. Pick one active project and open its three largest tasks.
  2. Apply the four-question test to every sub-task. Turn the ones that fail into a checklist in a comment, and delete anything nobody owns.
  3. Look for hidden work. For any big task without sub-tasks, ask whether it involves more than one owner, an outside approval or separately tracked time. If so, split it.
  4. Share the test with your team in a short project message, so new tasks start at the right level.
  5. Check again in two weeks. Look for bulk closures and stuck parents. If they have dropped, the breakdown is doing its job.

The goal is not more structure or less structure. It is structure that tells you something. When every sub-task has a reason to exist, a quick look at a task is enough to know where the work stands.