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
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.
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 
