Just wanted to say @Aisling_Grogan nailed it - this pretty much encompasses how I’ve seen most engineering teams work in Asana.
Company-wide, we set high-level goals (we call these Key Results and try to stay at 2 per team member per 6 months) at the beginning of the Episode (approximately a time-boxed Epic in Scrum terminology). The Key Results tasks are placed into a company-wide project to track them.
Additionally, in Developer Relations, we keep an overarching “big story” project with the key results and our backlog / triage of incoming or reactive “general” work that is off-sprint for our main goals.
In DevRel, we then create a project for each of the Key Results so that we can separately track the progress of each goal (i.e. update each key result project on the “Consider updating your project progress” message). This works well for us, because we are so cross-functional that having just one update story doesn’t actually communicate well for us, so we want stakeholders to be able to track only the work for which that makes sense for them to be involved and cuts down on their noise. Also, in this way, the goal of the episode is to invalidate or deprecate each project, which works great.
At the end of the episode, we use a set of Custom Fields across the company to report the status of each Key Result task, and then a script runs through and generates a report of these: how many did we hit, when were they hit, what did our progress look like, did we reach company-wide goals, and so on.
Everything that’s not company-wide is up to the team leads and project managers to choose as best fits their team; I’ve seen everything from “put it all in one project, and pull in the backlog to a section at the top” to finer-grained project management than I highlighted here. That’s one of the things Asana does well - it aims to be flexible, not proscriptive. You don’t even have to do the company-wide activity here; that’s just how we coordinate our separate teams to sync back up and track company progress.