Team Knowledge Management: How to Use PARA in Your Organization

Our digital world is constantly colliding and overlapping with the digital worlds of others. 

No one is an island, and that is especially true in our hyperconnected age where information can be so easily shared and intermixed. I’ve long advocated for individuals to create a personal system of knowledge management to help them skillfully navigate this world of information abundance – which I call their “Second Brain.”

One of the most common questions people have as they begin implementing what I teach is how they can share it with others. Whether by teaching their colleagues how to organize their own private thoughts and ideas, or creating a shared platform where everyone they work with can collectively document the knowledge they use.

Knowledge is meant to be shared, so this is a natural direction to move in once you start to experience the power of organizing your digital world.

It all begins with PARA – the cornerstone of my book Building a Second Brain and the starting point for organizing digital information of any kind. PARA is a system and a methodology for making knowledge stored in digital form far more accessible and useful, and it applies just as well to teams and companies as to individuals.

I’ve consulted with many organizations on how to implement PARA, from multi-billion dollar international financial institutions like the World Bank, to leading biotech firms like Genentech, to innovative startups like Sunrun. 

We all operate in a knowledge-based economy, and thus the ability to document what your people know and help them access that knowledge when it’s needed is a crucial capability for any organization. I would say it’s even essential for survival.

A Bottom-Up Approach to Knowledge Management

PARA is part of a discipline called “Knowledge management,” or KM for short.

KM is an extensive field with many research studies, academic journals, and conferences stretching back decades. Its purpose is to find ways for people to effectively share their knowledge with each other to advance the organization’s goals.

Let me give you my controversial take on Knowledge Management as it is usually practiced: it’s often used by management as a tool for top-down control. 

A wiki or knowledge base is created one day out of the blue, and staff are told to “share their knowledge” by inputting what they know. On the surface, this seems like a perfectly reasonable proposition. We are hired to contribute our knowledge to our employer, right? But in practice, there are multiple problems with this “top-down” approach to knowledge management.

First, it takes a lot of time and effort to articulate one’s knowledge in a form that can be easily understood by others. And typically, staff aren’t being evaluated or compensated for this effort, which means it is essentially a distraction from the outcomes they are being evaluated on. 

Second, there are risks to sharing one’s knowledge so openly. You don’t know how it will be interpreted, where it will end up, or whether you will be properly credited. It might even be taken out of context and used against you.

Finally, there is always the fear lurking in the back of people’s minds that by sharing their hard-won knowledge, they are making themselves obsolete. If your most valuable knowledge can be fully documented and made searchable, why should they keep you around?

All of this leads to my conclusion that modern organizations need to take a “bottom-up” approach to knowledge management instead of a top-down one. It can’t be about “extracting” knowledge from their people; it has to be about empowering them to do their absolute best work.

The following recommendations are centered on the needs and goals of the individual. It’s not that the organization isn’t important – it’s that the organization only benefits when staff embraces and feels inspired by the approach to knowledge sharing they’ve been asked to follow.

I’ll summarize my years of consulting experience into 5 concrete recommendations for how to practice knowledge management effectively within teams.

Here are my 5 recommendations at a glance:

1. Get clear on your organization’s flavor of PARA
2. Train people in how to use PARA
3. Keep only shared projects on shared platforms
4. Default to informality whenever possible
5. Encourage a culture of writing

​​1. Get Clear on Your Organization’s Flavor of PARA

My first recommendation is to define what PARA looks like and how it works for your team specifically.

Even if you’ve decided you’re going to follow my advice to the letter, there is always a “flavor” of PARA that makes sense for your culture. This can include decisions such as:

• What is our definition of a “project,” “area of responsibility,” “resource” and “archive”?
• What needs to happen when we kick off a new project for it to be considered “active”?
• What needs to happen when a project gets completed, put on hold, or canceled (for it to be considered “inactive”)?
• Who is responsible for maintaining the standard for each shared area of responsibility?
• What are the officially supported platforms on which PARA will be used?
• What are the strict rules, softer “rules of thumb,” dos and don’ts, and cultural norms that govern how people will use PARA?
• Who will be the “PARA Champion” who oversees its implementation and makes sure the guidelines are being followed?

I suggest summarizing these decisions in a one-page “PARA Guide” for your team where everyone can reference it. 

2. Train People in How to Use PARA

I recommend viewing the implementation of PARA in your team as primarily a training challenge, not an organizational or technical challenge. 

The fact that it takes me thousands of words to explain what PARA is and how it works should be a clue that even with such a dead simple method, people still need to learn it. They have to change their mindset, let go of limiting beliefs, observe and practice new behaviors, and then integrate all of that into their day-to-day work habits.

The first and biggest pitfall I see managers succumb to is the idea that they can implement PARA without teaching their people anything. That they can “install” it on their shared cloud storage drive like a piece of software and people will somehow magically know how to use it.

Nothing could be further from the truth. I promise you: you will need to train your people not just in how PARA works, but how it works in your team. The document you created previously with all the norms and rules of PARA will serve as a reference, but you will also need to make presentations, conduct training, and facilitate discussions with your staff around what that looks like.

PARA is really a set of common behaviors that everyone on your team will need to adopt: a shared set of assumptions, conventions, and policies that govern how people create files and folders, where they put them and why, and in what circumstances they should retitle, move, or archive them.

3. Keep Only Shared Projects on Shared Platforms

A tendency I often see is for teams to want to centralize all digital assets of their team in a single, all-encompassing place. The thinking goes: if all this digital content is potentially valuable, shouldn’t everyone have access to it?

The answer is no. You absolutely do not want everyone to have access to everything. Here’s why: for a piece of information to be understandable and usable by a wide variety of people, it has to be highly formal and structured, which takes a lot of time and effort. And you shouldn’t spend that time and effort without very good reason.

For example, if you have some notes on a book you’re reading, meant only for your personal use, those notes can exist in a very informal, casual, free-form state. You don’t need to define your terms, don’t need to add headings or sections, don’t need an outline or table of contents, and can add highlights and annotations without much context at all. In other words, you can depend on the fact that the person making the notes and the one retrieving them are the same person – you.

However, if you want to share those book notes with even one other person, suddenly the whole situation changes. There is a chasm that separates any two minds. You have no idea what the other person knows, remembers, or understands. You now have to add a considerable amount of context and structure to make sure they have a shot at understanding what your notes contain. Now expand that to dozens or hundreds of others, and the effort needed to make that knowledge intelligible explodes. 

Adding context and creating structure – including steps like defining your terms, making your assumptions explicit, or bridging the logic from one point to another, among many others – are cognitively expensive. And every minute you spend adding formality and structure to a document is a minute you’re not spending moving your team’s projects and goals forward. There is always a tradeoff.

I recommend advising your staff to keep all their notes, files, and documents in their own individual PARA folders by default. That way they can remain informal and messy until the moment more formality is needed. 

Only when a project or area becomes collaborative, with multiple people involved, should it be moved to shared Projects or Areas folders. If you think about the totality of all the work the entire team takes on, most of it will be at the individual level. Thus only a minority of the organization’s overall workload should reside in the shared PARA system.