In an office, a vague task gets fixed in thirty seconds at someone’s desk. On a remote team, the same vague task costs a message, a wait for the reply across time zones, and often a full day. The fix is not more meetings. It is better task descriptions.
The test: could someone start without asking?
Before you assign a task, read it as if you were the person receiving it, on a Monday morning, with no context from last week’s call. Could you start work right away? If the answer is “probably not”, the task needs two more minutes of writing.
A five-part template
Most good tasks answer the same five questions. You do not need headings for each one, but you should be able to point at the answer:
- Why: what problem this solves, in one or two sentences.
- What done looks like: the result you expect, as concrete as possible.
- Context: links to the related tasks, files, or conversations.
- Constraints: deadlines, budgets, or things that must not change.
- Who to ask: one person who can answer questions quickly.
Here is a short example in plain text, the way it would sit in a task description:
Why: New customers drop off on the second setup screen.
Done: The screen asks for 3 fields instead of 7, live by May 30.
Context: Survey results and screen recordings are linked below.
Constraints: Keep the company-name field; billing needs it.
Ask: Leo for product questions, Omar for design.Write the result, not the steps
A common mistake is to describe how to do the work instead of what the work should achieve. “Add three fields, move the button, change the copy” leaves no room for the person doing the task to find a better way. “Halve the time it takes to finish setup” invites them to think.
Steps are still useful for routine work, like a release checklist. For anything that needs judgment, describe the result and trust the person.
Use comments for decisions
Once work starts, the task becomes the place where decisions are recorded. If a question is answered in a call or a chat, add a one-line summary as a comment on the task. Three weeks later, when someone asks why the field was removed, the answer is right there.
If a decision is not written next to the work, it will be made again.
Make it a habit, not a rule
You do not need to enforce the template on every small task. Save it as a task template, use it for anything that will take more than a day, and point to good examples in your weekly sync. Within a few weeks, the team starts writing this way without being asked, and the number of “quick questions” drops noticeably.
