Need guidance: task management doc ecosystem

Hey friends, hope everyone is well.

I could use some help with an interconnected series of docs I’m setting up to support day-to-day task management for various groups of people with different levels of overlap. Here was my initial thinking (and I’m open to critique/feedback on any of this):

Despite multiple teams from different disciplines wanting to use Coda for the same function (creating and managing discrete tasks), I was reluctant to having all of these groups in one single doc for the following reasons (side note: this is also my first time articulating this, and by the time I get to the end I may have a solution for myself (but will post anyway as I suspect this is a problem others run in to frequently):

  • The different teams will likely not agree on the same task statuses.
    E.g. a team of UX researchers have expressed the following 8 statuses to be helpful for their process: “backlog, to-do, in-progress, cross-team dependency, blocked, needs review, de-prioritized, done.” Whereas the design team only needs 4 “backlog, to-do, in progress, done.” This is fine, and teams should have the freedom to work with statuses that make sense to their workflow. You could support differing statuses for different teams in the same doc, but I would think this means building more tables (e.g. “Task status - UX Research”, and “Task status - Design”).

  • Different teams will have differing ideas of how to group tasks.
    E,g, Researchers have “studies” or “initiatives” that have very concrete phases of work, but Designers may contribute to projects that could take many different shapes. Some teams might also be interested in sub-tasks (perhaps the new Canvas column and some inline checkboxes would be a sufficient solution…), or having projects that roll up into some larger bucket. I want to provide that flexibility to the teams that want to organize their work that way without imposing the structure on everyone. It’s easiest to do that by sequestering teams into their own team-specific task management doc.

  • I think there’s something to be said about giving these groups privacy. I am aware of the “personalized view” that can be achieved with filtering using User() , especially when pairing that with @Paul_Danyliuk’s admin controls and helper flow tables. There’s also “hiding collaborators activity” which hides cursor location and not their profile picture/avatar in the top right of the interface. So despite having lots of tools to create a team-specific experience in one Doc, all these folks will still know other teams are in that space. Maybe this is fine! The doc would just need to be explicit about what’s a personal space, team space, and cross-team space.

  • Performance. And I can’t make confident estimates as to how many tasks any one person may create because it’s highly dependent on the kind of work they do and how the “size” their tasks. Each team should have the freedom to be as granular or grand as is appropriate for them. Either way, there will be a “Task” table that will quickly fill with thousands of rows. If 1 person creates an average of 15 tasks a week, and I have 10 people interested in tracking their tasks in Coda, that’s 150 tasks per week, 600 tasks a month, and 1,800 tasks a quarter. Again, thanks to @Paul_Danyliuk’s excellent documentation and generous explanations and guidance regarding doc size limitations, I am now very sensitive to how a Doc for something like task management (which we want to use for a long, long time) can balloon. There are remedies for this too; a cross-doc based archival system that takes tasks that have reached a certain age and copy them into an archive doc for safe keeping (eventually to be deleted after they are no longer useful to reference), but I still worry about lag :sweat_smile: I’d be interested in setting this up whether I build one giant “task management” doc for all teams, or break them up into team-specific task management docs.

:point_up: Those have been my thoughts so far. Here’s the most recent dilemma that’s making me re-think my multi-doc approach:

Sometimes someone from the Design Team will need to collaborate with the Research Team on a research-specific task.

In a multi-doc task tracking schema, this raises questions: where does the task get tracked? In the Research Task Management Doc, because it’s a research task? Or does it get tracked in the Design Task Management Doc, because the task will be owned by a designer who tracks all their other work in that Doc?

In an all-in-one task tracking doc, it’s just a matter of who the task is assigned to and what project it’s bucketed under. Cross-functional task tracking seems much easier in this scenario.

But I’m torn. I’m nervous about the performance and complexity of a giant task management doc that will support multiple team’s work, but I’m also nervous about the silos created by giving teams their own Docs for task management because it makes that cross-functional task tracking difficult.

Any advice would be appreciated :pray:

1 Like

How are tasks being assigned? Directly from a doc and rows on a table? Or are they input manually and the project happens to be in Coda? If input manually id strongly consider something like Asana for the management.

If they get assigned live from coda tables (and I’m in this same boat now, mulling how to do it) I’m thinking I may end up using an automation through Integromat to push tasks to a task-management doc.

Likely it will be a task table in each doc that’s hidden and from that details and links are pulled and copied to a master task doc.

From there the user can click a link to the relevant doc to take action. They will need to manually mark things done tho. Or use a lot of webhooks and automation to keep things mostly in real time.

Heck even directly from a doc, with a well written webhook, it can just get pushed to Asana for actual management. Asana is pretty slick. When tasks are complete in Asana an automation can change something in Coda.

Again, I’m also mulling this over and rambling to develop ideas :slight_smile:

1 Like

Appreciate the reply Irfan!

How are tasks being assigned? Directly from a doc and rows on a table? Or are they input manually and the project happens to be in Coda?

If I understand your question (and do let me know if I’ve misunderstood), we are directly assigning tasks from a Coda Doc. Put another way: all projects and tasks would originate from the same Coda Doc. We’re trying to move away from Jira. I’ve used Asana in past jobs but never dug in deep. Could be worth exploring!

Perhaps more background would be helpful: a big reason why we’re interested in using Coda as a task tracking solution, especially for one of our teams (I’ll call them “Team-A”) is because Team-A is using Coda for other parts of their work and it would be very valuable for them to be able to have relationships between those deliverables and their task tracking tool. There’s a lot this unlocks for them in terms of task metric tracking (probably similar to what Jira and Asana offer), we could answer questions like “How long does this type of project take?” or “What kinds of work tend to have the most blockers?” or “Did Team-A’s efficiency increase after we changed the workflow in Q1?”

1 Like

HI Alice

This doc might have some ideas for you as well: (If you have not seen it already

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.