Module 2 — Projects and Tasks · Lesson 2.4
Subtasks, Dependencies and Recurring Work
Breaking work down, expressing what blocks what, and never typing the same task twice
~12 min
What you'll learn
- Decide when to use a subtask versus a separate task
- Express blocking relationships and read them on the timeline
- Set up a recurring task generator and choose its cadence sensibly
- Recognize when structure is helping and when it has become overhead
A flat list of tasks stops working somewhere around the point where one of them takes more than a few days, or where two of them cannot happen in either order. Kavanah gives you three tools for that, and the skill is knowing which problem you actually have — because using the wrong one produces structure that looks organized and answers no question.
Subtasks: decomposition
A subtask is a checkable piece of a parent task. They are first-class in Kavanah: a subtask has its own status and can be assigned to someone other than the parent's owner.
Use subtasks when the parent is one deliverable that happens to have several steps, and when you would report on the parent rather than the pieces. 'Launch the pricing page' with subtasks for copy, design, build and QA is the right shape: one thing ships, four people touch it.
Do not use subtasks as a filing system for unrelated work. If the pieces would each be reported on separately, or would land in different sprints, they are tasks and the parent was a project or an epic.
The practical test: if completing every subtask does not obviously complete the parent, the decomposition is wrong.
Dependencies: sequencing
A dependency says this task cannot start until that one finishes. It is a different claim from decomposition, and the two get confused constantly.
Dependencies are what the timeline and planning surfaces read to work out what a slip actually costs. A task with three things waiting on it is a task where a two-day delay is a six-day delay, and that is invisible on a board and obvious on a timeline.
The discipline that makes dependencies useful is to record only real ones. A dependency you added because it felt tidy — 'design before build' when the build could genuinely start on the parts that are settled — produces a plan that is more sequential than reality, and therefore a forecast that is pessimistic in a way nobody can trace.
The honest test for a dependency: would starting the downstream task now actually waste the work? If not, it is a preference, not a dependency.
Recurring work
Some work comes back: the weekly report, the monthly invoice run, the quarterly access review. Kavanah has recurring task generators for exactly this, so the task appears on the right cadence without anyone remembering.
The generator creates a real task on its schedule. That is the important property — it is not a repeating checkbox that resets, it is a new task each cycle, which means each occurrence has its own history, its own completion time, and its own contribution to your throughput numbers.
Two pieces of advice. Set the cadence to when the work should START, not when it is due, or you will generate a task that is already late. And review your generators every quarter: a generator for a process that has quietly stopped mattering produces a task nobody does, which trains everyone to ignore generated tasks in general.
When structure becomes overhead
There is a point where each additional relationship costs more to maintain than it explains. The signs are consistent.
Nobody looks at the timeline, but the dependencies are meticulously maintained. That is maintenance with no reader.
Subtasks get completed in a batch at the end, all at once, because nobody was tracking them individually. That means the decomposition was for the plan, not for the work — write it in the description instead.
A generated task gets closed unread every week. Either the process is dead or the task is not the right artefact for it.
When you see these, delete structure rather than adding process to enforce it. Structure that nobody reads is a cost with no benefit, and removing it is free.
Add the right structure
- 1
Break one large task into subtasks
Pick the task on your board that has been in progress longest. If completing the subtasks would not obviously complete it, the decomposition is wrong — try again.
- 2
Record the dependencies you actually have
Only the ones where starting early would genuinely waste the work. Preferences are not dependencies.
- 3
Set up one recurring generator
Pick a piece of work that comes back and that someone currently remembers manually. Set the cadence to when it should start.
- 4
Look at the timeline to see what the dependencies cost
The planning surface is where a chain of dependencies stops being abstract and starts being a date.
What to watch
- Subtask completion spread
- Whether subtasks under a parent complete over time or all at once at the end.
- Healthy signal: Spread out. A batch completion at the end means nobody was tracking them, and the decomposition was decoration.
- Blocked-task count
- How many open tasks are waiting on an unfinished dependency.
- Healthy signal: Low and moving. A stable set of blocked tasks means the blocking work is not being prioritized — the chain is the thing to fix, not the queue.
- Generated-task completion rate
- Share of tasks created by recurring generators that actually get done.
- Healthy signal: High. A low rate is the clearest possible signal that a generator is encoding a process the team has abandoned.
Key takeaways
- ·Subtasks decompose one deliverable; if the pieces would be reported separately, they are tasks.
- ·A dependency means starting early would waste the work — anything else is a preference.
- ·Dependencies are what turn a slip into a visible cost on the timeline.
- ·Recurring generators create real tasks each cycle, so each occurrence has its own history and metrics.
- ·Structure nobody reads is pure cost; delete it rather than adding process to enforce it.
Next: making the board match your process rather than the other way round — custom statuses and custom properties.