Using Subtasks and Dependencies Effectively
Subtasks and dependencies are how you turn a vague, intimidating chunk of work into something concrete and sequenced. Used without discipline, they turn it into a maze instead.
Two of the most useful structural tools in any work system are subtasks and dependencies, and two of the most commonly misused. Subtasks break a large piece of work into smaller, concrete steps. Dependencies capture the fact that some work cannot start until other work is finished. Both address real problems - work that is too big to act on, and work that must happen in a particular order - and both, applied without judgment, create more structure than the work can bear.
The skill is knowing when each earns its place. A subtask that clarifies is worth adding; a subtask that merely fragments a simple task into needless pieces is overhead. A dependency that captures a genuine constraint prevents mistakes; a dependency added out of a desire to model everything precisely just makes the plan rigid and hard to change. Getting the balance right is the difference between structure that helps and structure that suffocates.
Subtasks make big work actionable
The core value of a subtask is turning something too large to start into a set of steps you can actually begin. A task like launch the new website is not actionable; you cannot sit down and do launch the new website. Broken into subtasks - finalize the copy, build the pages, set up the domain, test the forms - it becomes a sequence of concrete actions, each small enough to start and finish, which is what makes progress possible and visible.
Subtasks also reveal true scope. Breaking a large task down often exposes that it is bigger than it looked, with steps you had not consciously accounted for, which is far better learned during planning than discovered mid-execution. And they let work be shared, because distinct subtasks can have distinct owners. In Atlas, subtasks let you decompose a large task into its steps within the same task, so the breakdown lives with the work rather than in a separate plan that drifts out of sync.
- Turn work too big to start into concrete, startable steps.
- Expose true scope, surfacing steps you had not accounted for.
- Let distinct steps carry distinct owners so work can be shared.
- Make progress visible as steps complete, rather than one large unmoving task.
The subtask trap
The failure mode of subtasks is over-decomposition: breaking work down so finely that managing the subtasks costs more than the work itself. A five-minute task split into four subtasks is not clearer; it is buried in structure that adds overhead and obscures rather than clarifies. Every subtask carries a small cost to create, track, and complete, so subtasks are only worth it when the clarity they add exceeds that cost.
The test is whether the breakdown helps someone act. If the subtasks make a large, vague task concrete and startable, they earn their place. If they merely fragment something that was already clear and small into ceremonial pieces, they are overhead pretending to be organization. Break work down until it is actionable, and then stop - the goal is the least structure that makes the work clear, not the most structure you can impose.
Dependencies capture real order
Dependencies exist to capture a specific reality: some work genuinely cannot begin until other work is done. You cannot deploy before the code is written, cannot send the invoice before the work is delivered, cannot paint before the walls are built. When these constraints are real, capturing them as dependencies is valuable, because it prevents the mistake of starting something prematurely and makes the true sequence of a project visible, which is essential for understanding what can happen when.
The value of a dependency is that it encodes a constraint the plan must respect, so that the order is enforced by the structure rather than left to memory. This matters most in coordinated work with many moving parts, where the sequence is complex enough that no one holds it entirely in their head. A well-placed dependency turns an implicit ordering that people have to remember into an explicit one the system tracks, which is exactly where dependencies earn their keep.
Do not model what is not a real constraint
The dependency trap is modeling order that is not actually a constraint. Two tasks that could happen in either order, or in parallel, should not be linked by a dependency just because you happen to imagine doing one first. Every artificial dependency makes the plan more rigid and harder to adapt when reality shifts, and reality always shifts. A plan overloaded with dependencies that reflect preference rather than necessity becomes a brittle thing that fights every change.
So reserve dependencies for genuine constraints - the cannot-start-until relationships that are true regardless of preference - and leave everything else unconstrained so it can flex. The test is to ask whether the second task literally cannot proceed until the first is done. If it can, in a pinch, proceed anyway, it is not a real dependency and should not be modeled as one. Used this way, subtasks and dependencies together give you exactly enough structure to make complex work clear and correctly sequenced, without the burden of structure the work never needed.