Compound tasks are how work gets lost

Here is a task that looks fine: Write the proposal and send it to Acme. Sandy owns it. It is due Friday. Friday comes, the proposal is written, and the task is still open — because it has not been sent yet, because the send is waiting on a price from Joe. Monday, still open. Two weeks later it is still open, the proposal is stale, and nobody can tell from the list whether the writing part ever happened.

That is a compound task. Two pieces of work sharing one line, one owner and one due date, when they did not really share any of those things.

The tell is the word "and"

Read your open list and look for and. Not the and inside a noun — Terms and conditions is one document — but the and between two verbs. Write and send. Fix the header and update the footer. Call Acme and book the venue. Each of those is two things a person can finish — two of what a task is — stapled together.

Stapled tasks fail in a particular way. The first half gets done and the task cannot be closed, so it sits there looking late while the actual work is finished. Or the second half is small and gets done first, and the task looks nearly complete when the hard part has not started. Either way the list stops telling you the truth, and a list that does not tell the truth is a list people stop reading.

Three ways out

Split it. Write the proposal — Sandy, Wednesday. Send the proposal to Acme — Sandy, Friday. Two tasks, two dates, and when Friday's is stuck on Joe's price you can see exactly which piece is waiting and on whom. This is the right answer nine times in ten, and it costs you one extra line.

Make the pieces subtasks. When the pieces only make sense together and one of them changes hands, keep the parent and put the hand-off inside it. Homepage copy has subtasks Draft (Sandy), Client review (Acme's person), Final (Sandy again). The parent shows 1 of 3 as they finish, and you can mark the review as blocking so the parent refuses to close while it is still open. Subtasks go one level deep on purpose — if a subtask needs its own subtasks, the parent was never a task.

Admit it is a project. If you split Redesign the site and migrate the blog and end up with fifteen tasks across two months, you have not got a task with an and in it; you have got a project, and it wants its own page. Subtask or new project? is the piece on drawing that line.

What splitting gives you back

Take the agency example again. Sandy's Write the proposal and send it to Acme becomes two tasks. On Thursday morning the first one is done and ticked; the second one is open, due tomorrow, and its notes say "waiting on Joe for the hosting price". Joe is mentioned in that note, so the bell tells him. Nobody has to ask Sandy how the proposal is going, because the list already says: written, not sent, stuck on a number.

Compare that with the compound version, where the only honest status on Thursday is "sort of".

Where they come from

Compound tasks are rarely written on purpose. They come from writing things down at the speed of a conversation. A client says "can you write the proposal and get it over to us by Friday" and the sentence goes into the list whole, because that is what was said. Or a task is written before the work is understood, when write and send looked like one motion, and only turns out to be two once the price is missing. Neither is a mistake worth feeling bad about. It is just worth noticing, because the sentence you were told is not the same as the work you have to do.

A habit, not a rule

You do not need to police this. Type tasks the way you say them — Write the proposal @sandy wednesday — and the box at the top of a project does the rest. Then, once a week, read the open list for and. When you find one, ask which half is actually finished. If the answer is "the first half, ages ago", split it right there. The task that has been sitting longest is usually the one to look at first.

The question this answers

Compound tasks are the ones that grow old, because they can never quite be closed. So the list that finds them is the list of open work, oldest first.

Show me open work, oldest first — anything near the top with and in its title is two tasks waiting to be written down properly.