Guest post by Nat Eliason

I took Tiago’s Building a Second Brain (BASB) and Getting Stuff Done Like a Boss (GSDLAB) courses in the fall of 2017.

At the time, I was a solo operator working on my blog and doing some marketing consulting, and the strategies worked perfectly.

But over the next year, I went from working on my own to running a marketing agency with five full-time employees plus fifty contractors. On top of that, I had to manage my agency’s work, my blog, my podcast, my personal life, as well as agency sub-projects like our tea company and writer matchmaking service.

As the scope of my team’s work grew, the Evernote-heavy BASB format I loved started to break down. Evernote is great at many things, but collaboration is not one of them. Things, too, the preferred task manager in BASB and GSDLAB, doesn’t work with teams, and it was becoming more and more obvious that I needed to change my PARA implementation to fit working on a team.

Specifically, I needed to figure out a way to:

  1. Maintain a bird’s-eye view of all my active projects
  2. Track and prioritize my projects and goals
  3. Collaborate with my team on those projects
  4. Make relevant information easily findable for the team

For anyone else who loved BASB and Tiago’s work but has struggled to implement them for their team, hopefully this will be useful. It’s still very much a work in progress and it’s being constantly refined, but here’s what’s worked for us.

I’m also going to attempt to explain it in the way Tiago does his PARA implementation, starting from the task level and working our way up.

PARA as an Organizational Philosophy

The first step to getting PARA and BASB to work for a team is loosening the strictness. Having a strict organizational style works well when it’s just you, but when you need team members to also work with your organizational method, strictness becomes an impediment to adoption.

You want some order, but not so much that it gets in the way. And from what I’ve noticed, that strictness can get looser as you move up the PARA hierarchy.

What you don’t want to lose is the underlying organizational philosophy of PARA, which I’ve interpreted as:

  1. Active projects should have their relevant information and tasks in one place.
  2. Projects should be contained within Areas when possible.
  3. Areas, too, should have all their relevant information in one place.
  4. Separate your active information (Projects & Areas) and inactive (Resources).
  5. Archive anything inactive, or no longer interesting.

You could implement this across any combination of tools, but after trying out a few different ones what we found worked best was using a combination of Asana and Google Drive.

I also still use Evernote personally, and there are a few tools on the sides that help make this process easier, but almost everything lives in Asana and Google Drive.

 

The Projects Layer

All of our active projects start out in Asana. Sometimes, the projects are very specific and fit the PARA definition of a “Project”, like this one for launching The Writer Finder:

And then other times, the projects are more like Areas since they’re ongoing and don’t have a specific end date, like the Cup & Leaf editorial calendar:

You could think of each article as its own little project. When you open an article task you can see all the steps that lead to its completion:


So in this case, the editorial calendar board is the Area containing all of these article Projects.

Again, the terminology isn’t hugely important, it’s the underlying philosophy you want. Each Project should have all of its relevant tasks within it (whether that Project needs its own Asana board or just a task/card). And ideally, it should have all of the relevant information as well.

We do that through rich descriptions within each task. For an article Project, we’ll have all the images, docs, and other links included right in the task:

And for a bigger Project that needs its own Asana board, we’ll make each task within it richly detailed as well:

In this case, I’ve linked to a specific email in Front where someone sent me feedback on the site. By clicking that link, I can quickly open the email back up to implement their feedback, similar to Tiago’s inbox zero strategy.

This rich-task strategy for organizing information, similar to the strategy of containing Project information in Evernote folders, does 90% of the work. Someone who has never looked at our Google Drive can easily navigate to the documents they need to complete a Project just from the rich tasks.

Occasionally we’ll also need some Area-level information to reference, which we also do within the Asana boards. In the editorial calendar example, we’ll link to the spreadsheet where we’re organizing the broader strategy within the board description:

If you’re not familiar with Asana this might be going way over your head, but the principles can be copied over to any team collaboration tool:

  1. Create clear steps (tasks and subtasks) for each Project
  2. Assign each step to one person with a specific due date.
  3. Include all relevant Project information within the tasks so there’s no hunting.

Outside of Asana, the other place I’ll implement the Projects layer is in Drive. My top level looks like the typical PARA implementation:

Then within Projects, I have folders for any Project that doesn’t fit within an existing Area. Within Areas, I have folders for all of our clients and on-going focuses (like Cup & Leaf), and as Projects turn into Areas (like The Writer Finder will) it’ll get moved into the Areas folder.

The big difference here from normal PARA though is that I don’t follow the Drive organization very strictly, and I don’t expect my team to either. Everything is organized in Asana so that we don’t need to, and as long as we know the name of the folder we’re looking for (or it’s linked) then it doesn’t really matter where that folder is.

The Areas Layer

There isn’t much else to say about the Areas layer beyond what we covered in the Projects section. Areas are just the containers you put your Projects in, whether that’s in Asana as boards, or in Drive as Folders.

It’s easy enough to do this in Asana, but Drive is where it can get messy. You need to make an effort to file all of your documents in the right place so that other people on your team can find them without everyone constantly asking each other where something is.

Rich tasks like we talked about in the Projects layer helps a lot, but so does having sensible Area folders in Drive. The one difference here from normal PARA is that I will do nested Areas.

So for example, Clients is an Area, but each client is also an Area. The top-layer within Areas looks like normal PARA:

But then within an Area, there might be a mix of Areas and Projects:

With the number of different Areas and Projects you might have going on in your company, a two-tiered Area hierarchy makes life much easier (and organized). You can imagine how cluttered my Areas folder would get if all of these (and all of the other sub-areas) were in the top-level folder. Plus having Cup & Leaf Projects and Areas in two separate sections (the top-level Projects and Areas folders) would make finding things messy.

Two levels has been enough so far, but in the future it might make sense to go down to three. Each business Area could have its own PARA breakdown, which would make sense when you reach a certain critical mass of information and moving pieces.

The key, I think, is to keep the flexibility that Tiago talks about in BASB. The system should work for you, not you for it.

The Resources Layer

Our resources layer is entirely in Google Drive, and mostly contains templates, standard operating procedures (SOPs), data, and designs.


We end up using a lot of templates in our business, and having a dedicated folder in our Resources folder makes it easy to keep them all in one place. The same goes for SOPs: when we find something we can systematize, we like to write it up and hand it off to a contractor, so having all of those in one place too makes things easy.

Aside from that, we have a shared “education” folder with access to a bunch of different online courses (and our Progressively Summarized notes on them), we have some of our past client results, our brand designs, and everything else that doesn’t quite fit in an active Project or Area.

On a personal level, I also use Evernote for my own collection of Resources. If I’m reading something and take notes on it, or find an interesting site, or want to jot down notes for an article, I’ll typically do that in Evernote. I try to keep it exclusively personal-project-related, though, and keep everything team related in Drive.

The Archive Layer

The archive layer is the simplest: whenever something stops being relevant, it either goes into the Archive folder in Drive, or gets archived in Asana.

Archiving projects in Asana is particularly useful since they can end up being useful templates for projects in the future, so we tend to keep them in the archived area instead of deleting them. This can make some of our Teams cluttered, but since archived projects are hidden by default, you don’t normally see them.

Two Finer Details

There are a few other details that help make this system work well.

No Email

We never use email internally, instead doing everything in Slack. If someone sends us something important over email, we turn that into Asana tasks and Drive documents, and will talk about the email in Slack if we need to discuss it.

This makes sure that no documents, notes, or discussions get lost in our emails, and that we never have to go to Gmail to search for something a client said or one of us said to each other. It’s all right where we need it.

Front again makes this easy since it integrates with Slack letting you forward an entire email conversation into Slack to discuss it there, here’s what it looks like:

And like I mentioned before, I can easily turn emails into Asana tasks:

The High-Level View

Since I have so many different types of projects going on at once, some of them within Growth Machine and some not, I keep a separate high-level view in a spreadsheet that makes it easier to keep my goals and the projects I’m working on in check.

I discussed it in more depth in my article on how I stay productive, but it lets me easily set monthly, weekly, and daily goals, and tie them back to my yearly goals.

I’ll also link the daily, weekly, or monthly goal to the corresponding Asana board when it’s relevant, just to make it easier to move from my spreadsheet to the relevant parts of Asana.

This part isn’t necessary, but it definitely helps with keeping track of everything you have going on if you have a bunch of different projects you need to stay on top of.

The big difference between the spreadsheet and Asana is that the spreadsheet is all the projects I personally am working on, while Asana is all the projects the company is working on. Not all company projects involve me, so they don’t need to be on the spreadsheet.

Implementing it Yourself

This is very much tailored to what’s worked for me and my business, so I don’t recommend you try to copy and paste it into your life.

But the underlying philosophy that guides it, PARA and how you can extend it to teams, should work for most small businesses that want to easily collaborate and stay productive. It’s fairly tool-agnostic and will work well for remote and co-located teams alike.

If you get too hung up on trying to force yourself into a rigid system, it’s unlikely to work well for you and will implode when you try to add other people.

Instead, experiment with it, tweak it, and adjust it to become a natural part of how you operate your business.

Follow us for the latest updates and insights around productivity and Building a Second Brain on Twitter, Facebook, Instagram, LinkedIn, and YouTube. And if you're ready to start building your Second Brain, get the book and learn the proven method to organize your digital life and unlock your creative potential.