I just checked out the great new “Coda Essentials” series yesterday on YouTube. @maria Great work as always in the channel! As a somewhat novice Coda user, I’m always able to learn something new from content you guys deliver in these clips, many thanks for putting these together and please keep it up!
I wanted to ask if you would consider some basic Team-type stuff in your upcoming plans. I’d really be interested in some content that would show some ways to build basic “team” stuff you might find in apps that are used by teams, that Coda is replacing in many cases, like Jira, Trello, Wrike, Asana, Monday, Clubhouse, etc. Unlike Coda, these apps have some “forced” structure, which often includes:
Some basic reports like Resource Management, Tasks completed by assignee, etc.
Central Activity log for what has been going on within the team
Suggestions for setting up hierarchies factoring in both 1) in-table lookups, and 2) table-to-table lookups, and the differences. I think basic hierarchy is a fundamental feature of a lot of other apps - things like Task/Subtask, Epic/Story, Objective/Key Result. In my experience in Coda there are differences that are important which result depending on what combination of in-table, and table-to-table structures you set up, for example in Grouping. There is a lot of discussion around hierarchy handling in the community, so I think this last one would be particularly useful.
I’d be particularly interested in how to emulate a more sophisticated Team Dashboard. I have seen some docs that will filter tables for things like tasks or other individual entities, but I’m curious about a more robust view.
In this post there is some discussion of a dashboard with things like Meeting Notes, Project Milestones, Tasks in Motion, etc.
I’d be interested in some solution like that, which would pull in data from multiple parts of a doc, or even cross-doc if you want to add stuff like Customer Feedback status, CRM pipeline health, etc.
Oh and PS Maria, I watched your Bug Tracking video with great interest, but had trouble with the Audio. Perhaps it was my internet connection, but during the entire clip the audio seemed jumbled!
Maria, that’s great! Have been looking through the Coda Essentials videos and picking up bits and pieces each time I review, thanks again for posting. Really appreciate your guys’ steady stream of video tutorials these days, I definitely find them very useful!
And sorry if I am going overboard here with the suggestions, but another thing that has been on the top of my mind as I try to move forward with Coda is the best approach to Cross Doc as a way to build out Coda for more all-team use.
I just watched your tip here:
at around :55 in, you were actually talking about things getting disparate if teams build their own docs and get to working too much in isolation. That is one of my main goals in my Coda use: Keep as much of Coda in sync through all the teams it is used by.
There is talk in the community about various approaches to Cross-Doc to meet this need, and I’d love to find out more. For example, the “hub model” via @Paul_Danyliuk; and also discussion of various approaches to “push” vs “pull” as I understand, like this quote:
In particular I’d like to see how a team could set up Cross-Doc so that work can be created and planned from a central location, by say Product and management teams, then carried out within individual docs, but all tracked back at the “main” doc. A good dashboard in this mix would be a great piece.
My friend @Jean_Pierre_Traets also suggested this as one of your topics, so I’ll add that in here too:
Thanks again Maria! I feel like I am getting ready to graduate “Freshman year at Coda University” thanks to all your training materials, haha! Can’t wait to watch the “Business in a Box”!
All great questions @ABp! When it comes to cross doc, I like to think about it in two main ways:
Let’s start with Repository. Think fo the data that you’ll want to use in multiple docs. Things like OKRs, org charts, customer details, etc. These will be items that you’ll want to have in one doc. You can then cross doc that data any time you need it. Note, any data that you put into the new doc will NOT be posted back to the core repository YET. This is a feature we’re working on, but it isn’t available today. We’ll be exploring this in the Business in a Box series.
Next we have Distribution. You’ll use this if you have data that you want to distribute pieces of to a wider group. Performance Reviews/data is the perfect example. You might have a full table with the feedback for everyone in the organization, but you certainly don’t want everyone to see all the feedback. You could instead cross doc a filtered view into individual docs for everyone.
For your case, I might recommend the following:
Each team has a doc that they use to manage their tasks, projects, and meeting notes
You could cross doc their task tables into a master doc and see all the team’s data there
Depending on the size of your team, you could also have one Coda doc with sections for each team. You can also always make changes at any time. Here at Coda, we’ve gone through several iterations for how we run our teams as we’ve grown and changed over time.
Hey @maria, that’s great, thank you! In particular glad to get reaffirmation that you guys are working on further 2-way sync capability.
I think it would be great if you guys built out some comprehensive material around this theme, in particular with some specific examples, a few that come to mind:
I want to run Product Development by collecting feedback from Intercom and ranking my Future Features list based on the number of Intercom conversations that relate to those items in the list. Then, transition the ones I choose into development, so those items need to move to the development “area,” likely in another doc. But also be able to prioritize from a “Bird’s Eye” in my central “Repository,” where I track the entire team’s work across all departments or function areas.
CRM - I’d like to manage leads and conversations with them, tasks I do for them if they report bugs or need a custom report, etc. But also include certain leads into a Marketing campaign that I want to target to select groups I have in the CRM. And possibly plan content around that campaign, if the campaign involves, say, a drip Email series that needs to be written by yet another team.
I have been posting quite a bit in the community, but my two of my top posts are these according to my Discourse rankings:
So I think that’s an indicator that using Coda as a team solution is a question that a lot of users are trying to solve. Well maybe I can’t be sure about others, but at least I can tell you it’s a question I’m trying to solve
I have thought a lot about using a mass doc vs. trying Cross-Doc with a plan to later on be able to integrate as you guys build out the Cros-Doc capability. I am facing those examples above and many more, and I think it would be great if you guys could shed light on as many specific examples around team docs as possible. Perhaps one idea would be to select some of the great Templates you have, and propose some “mash-ups” people could run that would bring in very expanded capabilities. So like a combo doc, or multiple linked docs, taking from Meetings, Project Management, Product Development, and maybe others that would work well together. But the key would be to get from your guys’ expert point of few how to integrate these Templates. That’s something I’ve struggled with.
Thanks again Maria. Your content is always very helpful to me!
Yes in fact you made the connection - those examples were more or less inspired by those two great videos, I watched them both, CRM was particularly interesting. It was good to see @Charlotte_Espeland talking about how you guys use that particular pack, too, as she has helped me many a time with my own Intercom inquiries!
So in fact to close the loop in what I was suggesting to you guys, I’d love to see some examples of how the CRM or Intercom doc can tie with a full-team set-up. To add some more context, one thing I was trying to achieve was a place where all the tasks a whole team was working on could be seen. One of the things that brought me to Coda was the prospect of seeing team’s work all together, and not have it in silos. I had some concerns that if I build so that my functional areas or “teams” like CRM & Feedback were in separate docs, management, or decision-makers would have trouble seeing the respective tasks in one place.
Specifically, I’d be interested in seeing a set up that might accommodate a smaller team of say 11 - 30, working in some key areas like CRM, Development, Support/Success, Marketing, Content. There will be tasks in each of these areas. I’d like to do this type of activity around all those teams:
Look at their work in one place - in the context of both tasks, and projects the tasks are in
Link work as there is a bunch of cross-team initiatives that are typically covered by those functions, like product releases. So play a release including Dev, Marketing, Content - have tasks in all those teams, but the Release itself in the “main” area since it really doesn’t belong to any of those teams, but to the company at the top level.
Plan work ahead, and possibly see new hiring needs, a big need of start-ups of this size. If you could plan out several of these releases or initiatives, and then assimilate the hours needed to complete with stuff like sizing of work and then rolling up those numbers, you might be able to practically predict where you’d have specific new hires needed. And virtually have the work for the new hires ready to go as soon as they are onboarded!
In other words, in the context of the videos you cited, I would really like to see how those two docs fit in the whole of the “all-Coda” System. I’d also would like to see where the great meeting doc you guys demoed fits in as well!
Such great ideas @ABp! My key recommendation when anyone is thinking through building a system is to map out what the workflow of the average person using it would be. It can be really easy to get caught up in all the possible connections, but the most important part of any system is the human element and making it super clear and easy.
If the workflow will be giving people one place where they can see everything that’s going on, I would recommend having a doc with several cross doc’d tables of their tasks across areas filtered by the =User(). They could then jump off to the docs of choice to dig deeper or take action. You could also include a section with the company wide tasks filtered by week or month across all docs.