Practice workflows
How to Track Tasks Across a Legal Team
A task labelled research or draft tells a legal team almost nothing. Defining the deliverable, owner, reviewer, and source turns a vague list into accountable work.
A task list in a legal team is where good intentions go to die vaguely. "Review contract", "do research", "prepare draft": each looks like progress and none of them can actually be finished, because no one agreed what finished means. When a partner delegates in a corridor and a junior notes it down in shorthand, the two of them are often tracking different tasks. Multiply that across a matter and a team, and work either gets done twice, not at all, or in a form nobody wanted. Tracking tasks well is really about making delegation unambiguous.
Define a task by its deliverable
A task is trackable only when you can say exactly what its completion looks like. "Review contract" is a topic; "note whether the indemnity clause caps liability, in a one-page memo to the partner by Friday" is a task. The shift is from naming an area of work to naming an output someone can hold up and call done. Before a task goes on a list, it should carry a deliverable specific enough that two people would agree, on sight, whether it has been produced.
Attach the details that make it doable
Around the deliverable sit a handful of fields that turn a wish into an assignment:
- the owner who will do the work
- the reviewer who will check it
- the source material and, crucially, which version of it
- the due date and any task it depends on
The version point matters more than it looks. A junior who drafts from last week's version of an agreement has done real work that is now worthless. Naming the source version inside the task is what stops that quiet waste.
Separate the owner from the reviewer
Most legal work has two roles that a single task label hides: the person who produces it and the person who checks it. Make both explicit. The owner knows the work is theirs to move; the reviewer knows it will land on their desk and can expect it. Without that separation, work gets "done" but never checked, or sits waiting for a review nobody knew they owed. Naming the reviewer also sets a realistic deadline, because the due date has to leave room for the review.
Make dependencies and blocks visible
Legal tasks rarely stand alone. A draft waits on research; a filing waits on a client approval; a review waits on the latest disclosure. When these dependencies are invisible, people sit blocked in silence or barrel ahead on stale inputs. A task should show what it is waiting on and what is waiting on it, so that when the blocker clears, the next step is obvious and the chain keeps moving rather than stalling at each handoff.
Close the loop, and reopen when the ground shifts
A task is not finished when the work is done; it is finished when the result is linked and any loose end is recorded. Close each task with a pointer to the reviewed output and a note of anything still open, so the next person inherits the conclusion rather than a bare tick. And when the underlying document changes after a task was closed, reopen it: a review of a superseded version is not a review at all. Keeping tasks tied to their matter and its documents in a shared workspace makes both the closing link and the reopening trigger natural, so the team's list reflects reality instead of an optimistic snapshot.
Handled this way, task tracking stops being a nag and becomes the connective tissue of a matter. Everyone can see what they own, what they are owed, and what completion means, and the small ambiguities that quietly derail delegated work are settled before the work begins rather than discovered after it goes wrong.