Things keep getting reiterated about how to get everything into Coda, and yes, that would be great, but it also doesn’t necessarily need to be in a single Coda doc. Send me a system name and I’ll send you a use-case that will crash that system. That’s easy, anyone can do it, and no system out there is immune to it. Sitting here insisting that the system should fit that particular use-case that particular way also isn’t getting anything accomplished.
In short, step back, take a breath, and view things at a different angle.
The Uber doc was one big project, and all people involved used it as their source of truth and that’s how the project was run. That’s why we posted it. Other companies have their entire schedules running on Coda, so big stuff is possible when it’s the necessary information.
When things require brainstorming, notes, various meetings that only apply to that particular project, and various lists and resources, break that away from the initial scheduling doc and create a doc specific to that particular project. You can link to it in the original doc. The lets each team run the project the way they need to and gives them freedom to work the way that suits them. Trying to force all this information into one doc doesn’t make sense. So I don’t run into performance issues on a regular basis, only when someone insists on things being in one doc.