Multi-Step Work Becomes Epics, Not Loose Tasks

The problem

A task list starts clean: flat items, each one a single action. Then real life gets involved. A task like “confirm the invoice and collect the updated license” is really two independently checkable outcomes — but it lives as one line. A follow-up spawns a subtask. An orphan appears with no parent and no context. Within a few hundred items, the list is a mix of parents, children, and loose tasks, and nobody — human or assistant — can answer the only questions that matter at briefing time: what is actually blocked, what is waiting on someone, and what can be done today?

The failure is subtle because flat task lists degrade gracefully at small scale. Ten tasks, no structure needed. But the daily brief inherits the mess directly: a loose task that bundles three steps shows as either done (when one step finished) or open (when it isn’t), with no way to see which. Blocked work and finished work blur together. The assistant stops trusting its own list, and starts asking the principal questions the list should have answered.

The root cause is a category error: treating structure as something to be reconstructed from notes, instead of something encoded in the task graph itself.

The philosophy behind the choice

Promotion is a structural event. The rule: any task that bundles more than one distinct follow-up, decision, or outcome stops being a task. It becomes an epic — a container with explicit child tasks, one per independently checkable outcome. Crucially, the parent stops being actionable itself. You never “do” an epic; you do its children. That single constraint is what keeps the graph honest: if the parent were still actionable, the same ambiguity would simply move up a level.

Promotion applies at creation time going forward — when a task is born multi-step, it’s born an epic — and converts existing loose tasks when their multi-step shape becomes clear. The deliberate non-goal is a one-time forced pass over every task, splitting things for the sake of symmetry. If an item is genuinely one call, one payment, one confirmation, it stays a task. Overhead applied to simple work is its own failure mode; the rule has an explicit reverse condition: if epic overhead makes simple tasks feel bureaucratic, revert.

Why does it matter so much? Because a loose task hiding multiple steps makes progress invisible. “Check the invoice and update the license record” marked done after only the invoice part is a lie; marked open after both parts are finished is clutter. Children fix this by making each claim atomic and separately falsifiable.

Structure is the schema, not a convention. The hierarchy uses the task system’s native parent-child mechanism — no separate spreadsheet, no parallel “project” tool, no schema change. When two tools claim to be the master of your work, you get sync conflicts, silent drift, and an audit rail that breaks exactly when you need it. One system of record; everything else is a view.

Views sit on top instead of ad-hoc queries. The second half of the fix is a small set of named, reusable saved filters — perspectives, in the classic personal-task-manager sense — over the task data: filtered by venture, by mode of work, by status and labels. Plus the two views that matter most for briefing: a “today” view where deferred and waiting items with a future follow-up date are hidden until they come due, and a “waiting” view of everything parked on someone else. Every deferral gets an absolute date, so “waiting” items resurface on a schedule instead of rotting in place.

The reasoning: ad-hoc queries drift — everyone composes a slightly different filter each time, and the assistant’s answer depends on which variant it happened to run. Named views are shared, stable, and reviewable. They turn “what’s blocked?” from a judgment call into a lookup.

How it’s wired at a high level

Three pieces.

The promotion rule. At creation: does this item bundle more than one distinct follow-up, decision, or outcome? If yes, create an epic and attach each outcome as a child, each with a concrete action verb in its title. Existing loose tasks convert opportunistically — when the multi-step shape shows up in practice, promote them then, with the parent’s original title split across the children. No bulk migration.

Epic/child conventions. Children are created with a parent link; the parent carries the outcome-level description, the venture label, and the “not directly actionable” status. List views group by epic so the default reading of the list already shows structure. Children inherit the venture label so cross-venture reporting stays possible, and each child carries its own mode label (deep focus work, batchable work, a live call, a quick errand) — because the pieces of a multi-step effort often have different modes even when the whole doesn’t.

The view layer. A short list of saved views defined once over the task data:

• Today — actionable now; deferred/waiting items with future follow-up dates are excluded until due.
• Waiting — parked on someone else, each with an absolute follow-up date in the title or metadata.
• Blocked — children that can’t start until an upstream dependency clears.
• Per-venture views, and views by work mode (focus sessions vs. batchable work vs. calls).

The daily brief reads the views, not the raw list. That’s the payoff: the brief’s “done / blocked / waiting” sections are generated from the same named filters the principal sees in the review UI, so the numbers always agree.

What your chief of staff should be able to do afterwards

Hand this guide to your system, and afterwards it should be able to:

• Apply the promotion rule at capture time: when a new task arrives with two or more distinct outcomes baked in, create an epic with explicit children instead of a loose task — and say it did so.
• Convert loose tasks opportunistically: detect when an existing task reveals a multi-step shape (one part done, another pending) and promote it, splitting the title across children.
• Keep parents non-actionable: never mark an epic itself done while a child is open; close the epic when its children close.
• Maintain the named views: keep “today”, “waiting”, “blocked”, and per-venture views defined over the live task data, with deferred items resurfacing on absolute dates.
• Brief from the views: generate the daily brief’s status sections from the same saved filters — so “done”, “blocked”, and “waiting” are lookups, not reconstructions from memory.

At a few hundred open tasks, the graph stays readable — because structure lives in the data, and the list is just the views on top.

#task-management · #epics · #hierarchy · #saved-views · #briefing · #workflow