Architectural Balance in Asana (Ebook Chapter)

Larry Berger, Asana Certified Pro, Trilogi Solutions

Please enjoy this chapter I contributed to Secrets of Successful Teams in Asana, an ebook by Bastien Siebman along with several other Asana experts. The ebook is overflowing with great tips and best practices for Asana teams of all types and sizes, new or old. This chapter is yours free (all rights reserved). The full volume (34 chapters, 100+ pages) is available for purchase here.

Update: See also my free Workshop Webinar Video in Asana Academy: Tackle (almost) anything in Asana: Step-by-step for an expanded presentation of this article’s topic, and more.

Secrets of Successful Teams in Asana

“Should I make this a Project or a Team?” This question, and others like it, comes up often when starting something new in Asana, for both novices and experts alike. And it’s really just the tip of the iceberg.

How can you envision the structural, big-picture view of what you want to accomplish and translate that into an architectural framework in Asana that will enable your workflows, processes and information repository needs durably and flexibly, now and as they scale?

Asana often provides more than one way to accomplish something. This is good: we can do more with Asana as a result. But there’s a downside too: How can we avoid less-desirable solutions, and especially ones that even may lead to dead ends?

This chapter helps you decide how to set up your work in Asana. Just consider the following precepts as guides rather than as inflexible rules.

Asana’s Available Hierarchy

We must work within the structure Asana provides, which is:

Organization > Team > Project > Section > Task > Subsection > Subtask

In your Organization, each level can repeat as often as needed; e. g., you can have multiple Teams, multiple Projects within each Team, etc.

(An alternate hierarchy is available too but I generally discourage its use. That hierarchy eliminates the Team level entirely and replaces the Organization level with what’s known as a Workspace.)

Achieving Balance: Building Blocks

We’ll start with suggestions for each of the constituent parts individually before treating them holistically further below.

Organization

Your single Organization should encompass all the related work you and your colleagues do. Even if you’re a solo entrepreneur, I think you’ll find it much easier to operate within one Organization than multiple Organizations (or multiple Workspaces).

Asana makes it easy to collaborate with others and see all your varied work only if it’s all contained in the same Organization. Each Organization member sees their own Inbox (your Notifications) and their own My Tasks area (Tasks assigned to you) that house all your work from across your entire Organization.

Teams and Projects

Our natural thought process when we’re ready to begin something new is to create a Project. But in an Asana Organization, Projects can only exist within a Team, so instead, you should first consider your approach to Teams and at least create the key initial ones and have a clear plan for how that will evolve.

First, make a Team for every workgroup, permanent or transient, that will be using Asana for their own work. Don’t skimp, and don’t worry if some Teams have the same members right now; create a Team for each workgroup/purpose combination. For example, you’d usually want all of the following types of Teams in order to start to provide a logical home for every Project you’ll eventually create:

• All: Everyone in the Organization
• Department1: Everyone in Department1
• SubDepartmentA: Everyone in SubDepartmentA
• BigInitiative: Everyone working on BigInitiative (which is cross-discipline/department)
• AInitiative: Everyone working on AInitiative (even if the members list currently happens to be the same as those for SubDepartmentA)
• Me+Person1: One-on-one with Person1 (if you expect to have more than one shared project)
• Me: Just you (for your private Projects)

Another type of use for Asana Teams is to group things. Think of these Teams as buckets rather than the workgroups of people above. You might want a Templates Team so you can easily locate all your master Template Projects. If you use Asana as an information repository (in addition to work tracking and other uses) you might have Teams corresponding to functional areas of your business, and/or high-level folder names you’d find near the top of your organization-wide file share.

Once you have a handle on Team structure, it should be readily apparent where to put each new Project you need.

Make a Project for each logical grouping of work to be done. For example, a project 2020 Spring Offsite might make sense. For ongoing work that you’re not sure how to categorize yet, start with a Project named Main within that project workgroup’s Team. Even though all sorts of different things are in there, it still meets the “logical grouping of work to be done” test for now.

Use the Project’s List View by default because it is more powerful and flexible than Board View, though for simple, contained uses, and particularly simple process stage workflows, Board View may be preferred.

These recommendations partially address the question “Should I make this a Project or a Team?” Before we tackle the key remaining considerations (in the Putting It All Together section), let’s continue down the Asana hierarchy.

Sections and Tasks

Sections in List View (which appear as Columns in Board View) group related tasks, so you should use them if your Project is comprised of different collections of Tasks; otherwise, your Project may not need them. If you’re using a paid version of Asana, consider as an alternative to Sections a dropdown Custom Field and sorting (grouping) by that Custom Field as a potentially more flexible solution.

Task Titles should be kept reasonably short, and start with a verb if actionable. Section Titles should be even shorter and easily scanned.

Consider using Subtasks, but with the caveats below, as a way to simplify your Project by reducing the number of Tasks.

Subsections and Subtasks

The textual content of a Task, beyond its Title, can be specified in the Task’s Description, Subsections/Subtasks, or a combination of both. (Usually, you’d only use Comments for ongoing dialog, not persistent, task-defining information.) Among other pros and cons, the Description offers rich text whereas Subsections/Subtasks offer a built-in two-level structure, drag-and-drop reordering, Assignee, Due Date, and Completion checkmark. Although Sub-Subtasks (up to several levels deep) are supported, I’d recommend their use only in very specific circumstances.

Subsections/Subtasks are good for providing progressive disclosure — for not cluttering the main Task List — and are excellent for breaking down a Task’s component parts or enumerating anything. I would not use Subtasks for most everything else. When using Subtasks, I generally only recommend the use of Subtask Title, Assignee, Due Date, and Completion checkmark (so no use of the Subtask’s Description or its Comment thread).

Consider using the parent Task’s Comment thread in order to avoid having to descend into the Subtask for this (or any other) reason; in the parent Task’s Comments or Description, use an @reference to the Subtask to establish context. However, just before this chapter was published, Asana added the feature to expand a task in List View to see its first-level subtasks underneath. Because you can then click a subtask and have it appear in the right-side Detail pane, you have better access to the subtask’s metadata and comments so this paragraph’s considerations are suggestions, not necessarily recommendations.

I freely use Tasks with dozens of Subtasks when appropriate; my Projects are shorter and simpler for it. Those who have attempted to do too much with Subtasks and run into problems now recommend against their use entirely. I feel outlawing Subtasks is only warranted if you are unable to shepherd your team’s use of Asana to abide by this section’s recommendations.

Achieving Balance: Putting It All Together

In addition to the above rules of thumb for using each element in the Asana hierarchy, there’s one more key concept to bear in mind: Balance. To answer the question “Should I make this a Project or a Team?” it’s important to take stock of the volume and scope of your active content (non-archived Projects and incomplete Tasks) now and with a view toward scaling.

The answer to that question of Project or Team, say, for planning a monthly meetup event, may actually be neither: instead, a single Task with Subsections/Subtasks might be the best choice if each event usually has no more than a few simple steps/to-dos. Each event is a Task, and that means you only need one Monthly Meetup Project to house all of these events, which can all easily be seen in the Tasks List in a clear summary display, their contents just a click away in the Task Detail pane.

A much more complex event would warrant its own Project for each event occurrence because the guidelines above for Subsections/Subtasks would be violated by trying to pack in so much content there. Top-level Sections/Tasks are needed to offer enough breathing room for the work to be specified, optionally broken down into Subsections/Subtasks.

Finally, an even more complex event could require multiple Projects, and thus demand a Monthly Meetup Team to house them.

As you can see, there isn’t a single correct answer. But there is a way to discover the right Asana set-up every time . . .

Architecting Anything New in Asana: Step by Step

Here’s a step-by-step approach you can follow whenever you tackle something new and somewhat complex in Asana:

1. Briefly envision the amount and complexity of your work’s content now and as it scales
2. Draw a simple outline (hierarchy) depicting each logical grouping of content, e.g.:
   Monthly Meetup
   Jan 2020
   . . ToDo1
   . . ToDo2
   . . ToDo3
   Feb 2020
   . . ToDo1
   . . ToDo2
3. Choose a starting point for your topmost box from the prior step: For more complex and/or high volume groupings consider starting at the Team/Project levels of the Asana hierarchy; otherwise, consider starting at the Section/Task levels
4. Sketch (crudely, with a Sharpie, boxes, and lines) what the following parts of Asana would look like given your chosen starting point from above:
   a) Left sidebar: Rough indication of quantity of Teams and Projects added
   b) Tasks List: Rough indication of quantity of Sections and Tasks in each new Project
   c) Task Detail: Rough indication of quantity of Subsections/Subtasks across all the Tasks
5. If it appears manageable with neither a), b), nor c) too overwhelming, and you’ve generally achieved some balance across Teams, Projects, and Tasks, and Subtasks, proceed.
6. If you fear running out of room or risk violating the Subtasks guidelines, try “left-shifting:” In your sketch, use Sections/Tasks instead of Subsections/Subtasks, use multiple Projects instead of a single Project with Sections, and use a Team instead of Project.
7. If you have a sparse layout — perhaps multiple Projects but each with very few Tasks, or similar imbalances — try “right-shifting:” In your sketch, use a Project instead of a Team, use one Project with Sections instead of multiple Projects, use Subsections/Subtasks instead of Sections/Tasks.

Asana can be put to a million different uses, and with a little practice, you can get every one of yours in balance.

Keep in Mind . . .

Some brief, additional considerations on your path to architectural balance in Asana:

• Think Big, Start Small. In order to correctly architect your structure, envision the big picture of how your work will look once you get going. As long as you have thought ahead and know the correct entities that you’ll need (Teams, Projects) you can wait to create the bulk of them only when required.
• Many Teams and Projects. As you grow, you’ll add Projects, and maybe Teams too, naturally. Large or active Asana Organizations may have a lot of Projects and Teams.
• Archive Projects and Teams. Archive Projects when they become inactive. For Teams, consider faking a Team archive (not a feature in Asana) at the bottom of the left sidebar by creating a dummy Team called 🗄️ Teams Archive and positioning it after your last active Team. Drag Teams there that you no longer use (but don’t yet want to delete).
• Permissions. Get familiar with permissions since there are multiple ways to handle access rights at the Team, Project and Task levels. By starting with a sensible Team structure as above, it will simplify your work here.
• Advanced Search. If you are on a paid Asana plan, Advanced Search / Saved Reports can simplify your work and potentially reduce the number of Projects you need.
• Subtasks Undergoing Change. As of this writing, Asana is known to be improving the Subtasks feature but it’s not known specifically what is changing.