My position on subtasks is pretty well-known: they are really powerful but they come with limitations you should be well aware of.
The other day a client shared with me an interesting benefit of using subtasks for document review. They had a document attached to a task, and each subtask assigned to a reviewer. The reviewer was giving feedback in the subtask.
They realized the benefit was that a reviewer would not be influenced by what other people said. They were able to work and review in isolation, and share feedback on their own subtask.
I usually advocate for the same task to be passed around, but in this case there is a hidden benefit of using subtasks!
I do like this idea, but if the purpose is to not be influenced by others’ comments, can’t the assignee just look at the other subtask comments? Not sure I understand that piece.
I advocate for subtasks. They give you a clear overview of what has been done by whom within the main task. The subtasks can then be shown in workload and my tasks days ahead instead of receiving the main task at some point. Commenting on the main task!
I like the client idea to not be influenced by others! Maybe make the main tasks or subtaks private, so the others can see the content?
I use this feature before, assigning literature to be reviewed, and then I create a shared doc, for input and sharing ideas that is attached to the larger task, sometimes we use the main task as a major agenda item when we are looking at big ideas or brainstorming
I route Marketing content and prefer reviewers see each other’s comments to avoid conflicting changes. This way, I won’t need to reach out individually to explain why I can’t incorporate certain edits. So, I am an advocate of summarizing all edits on to the parent task. There should be an option to summarize comments, or turn it off.
We use subtasks for reviews but encourage comments at the main task level so people can not duplicate the same feedback. But in this use case, it still doesn’t make sense to me since the attachment is at the main task level anyway.
I’m happy to see this shift in perspective! We use subtasks for all our content reviews after discovering some deal-breakers for my team (and some interesting psychological insights). Passing around a task required everyone to remember who it needed to go to next, which resulted in a lot of inconsistency and missed steps (yes, you can automate this with rules and the board view, but this didn’t work when reviewers were different each time). There’s no single person clearly responsible and accountable for each individual assignment, so a lot of tasks stalled out if someone got busy, was out of office, or forgot (yes, an overall project manager is a best practice, but we don’t have the people power for that). There were lots of issues around the due date: keeping it the same to reflect the overall due date meant the individual’s due date was unclear, but changing it each time meant the overall target due date was nearly impossible to uphold. Then we tried making tasks in the project for each step so there was the clarity of responsibility, etc., but that was time consuming, and the project was messy and hard to navigate. Lastly, no one got the satisfaction of checking off the task and seeing their narwhal or unicorn fly across the screen! When the passing around method wasn’t working consistently and I asked what kept people from following through, they generally said they would do the review and then simply get busy with the next thing and forget. Checking off the task is a clear sign of completion (and a little dopamine hit!) and that small act makes a real difference psychologically.
We use a task template (or project rules) to add subtasks reflecting the standard workflow of revisions and approvals (automation/standardization). The parent task is assigned to the person responsible for the overall task – this might be the writer or a project coordinator (clear ownership/accountability). A shared doc link and the assignment brief is included in the parent task description, and each subtask assignee puts their comments in the shared doc – we actually see a benefit to reviewers seeing others’ comments for context. Subtasks are all dependent on each other so that when one is checked off, it notifies the next person that the content is ready for them as well as the parent task assignee as a status update (automation FTW). It allows me as a project manager/team supervisor to see where it’s at in the process without bugging people, and the responsibility for oversight is spread out among the team (trust-building, agile). And the due dates for both the overall assignment and each step in the workflow are visible to everyone (clear expectations). We do have an agreed best practice that subtasks only go 1 level deep.
You don’t get the ease of being able to adjust dependency due dates in the timeline or some other features, but the clarity and automation available with subtasks outweighed everything else for us. We’ve been using the same system now for 5 years, just making tweaks depending on the needs of the specific project. I Asana so much
My position on subtasks is pretty well-known: they are really powerful but they come with limitations you should be well aware of.
The other day a client shared with me an interesting benefit of using subtasks for document review. They had a document attached to a task, and each subtask assigned to a reviewer. The reviewer was giving feedback in the subtask.
They realized the benefit was that a reviewer would not be influenced by what other people said. They were able to work and review in isolation, and share feedback on their own subtask.
I usually advocate for the same task to be passed around, but in this case there is a hidden benefit of using subtasks!
We use subtasks for all our content reviews after discovering some deal-breakers for my team (and some interesting psychological insights). Passing around a task required everyone to remember who it needed to go to next, which resulted in a lot of inconsistency and missed steps (yes, you can automate this with rules and the board view, but this didn’t work when reviewers were different each time). There’s no single person clearly responsible and accountable for each individual assignment, so a lot of tasks stalled out if someone got busy, was out of office, or forgot (yes, an overall project manager is a best practice, but we don’t have the people power for that). There were lots of issues around the due date: keeping it the same to reflect the overall due date meant the individual’s due date was unclear, but changing it each time meant the overall target due date was nearly impossible to uphold. Then we tried making tasks in the project for each step so there was the clarity of responsibility, etc., but that was time consuming, and the project was messy and hard to navigate. Lastly, no one got the satisfaction of checking off the task and seeing their narwhal or unicorn fly across the screen! 
Asana so much