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.

Screenshot of Forte Labs Shared Google Drive

4. Default to Informality Whenever Possible

I previously said that it takes a lot more context and structure – in other words, a lot more formality – to make content intelligible for a wider audience. However, even in the case where that’s necessary, you should still default to the minimum level of formality you can get away with.

I often see organizations default to a high level of formality in all their communication. For example, a complex feedback form with 12 required fields, a memo template that reads like a government decree, or a company wiki with 10 levels of hierarchy requiring you to find the exact place something belongs.

Defaulting to overly elaborate information-sharing is a constant temptation inside organizations because it feels like the right thing to do. It feels responsible to make precise workflows, comprehensive questionnaires, and elaborate rules to ensure people do things “right.” No one gets in trouble for being too rigorous or too precise in the documentation they create.

Yet what few seem to realize is that every bit of formality carries a hidden cost. It extracts a toll on people’s time and energy that will inevitably show up in the form of frustration, discouragement, and a sense of defeat. 

When you force people to follow elaborate rules whose purpose they don’t understand, you are robbing them of the enthusiasm and excitement they need to do their most creative, inspired work. No one will complain, but under the surface, their morale will suffer.

It doesn’t have to be that way. One of the most powerful but also unusual cultural norms I’ve noticed within companies is the expectation that informality is not only okay, it’s preferred. I believe this is one of the secret weapons of tech startups – the beanbag chairs and ping-pong tables don’t make a difference by themselves, but they imply a culture where it’s okay to be yourself. That attitude of informality then carries over into how people plan, strategize, communicate, and collaborate, which is a much more natural and effective way to work!

Formality is needed only in very specific, limited circumstances. For example, when doing randomized controlled trials for a drug you’re developing, or when drawing up blueprints for a new bridge, or when handling toxic chemicals. Beyond this kind of dangerous or high-risk situation, informality should rule. 

As important as informality is, it depends completely on clear, transparent communication. In the absence of clear communication, overly bureaucratic processes will be created to pull the necessary information out of people, leading back to a top-down approach.

That’s why the fifth and final element is the lynchpin of effective Knowledge Management within organizations.

5. Encourage a Culture of Writing

One thing you’ll quickly discover when it comes to Knowledge Management is that it is essentially a form of communication. 

A document, note, or other digital asset is a message being communicated through time. When it comes to team knowledge management, the quality of that communication becomes even more important, since you don’t know who exactly will be receiving it on the other end.

What determines the quality of a piece of communication? Well, it turns out it’s the same things that determine the quality of a piece of writing, for example:

  • Is it interesting and attention-grabbing? (Does it make people want to read it?)
  • Is it precise and clear? (Can people easily understand what it’s trying to say?)
  • Is it empathetic? (Is the writer seeing things from the reader’s point of view?)
  • Does it help people solve a problem? (Is it useful and effective, or merely interesting?)
  • Does it inspire people to take action? (Does it make it easy for people to apply it?)

It turns out that effective knowledge management within an organization essentially boils down to how well people write down what they know, and share or otherwise express it in a form that other people benefit from.

The skills learned through writing also translate to other kinds of “knowledge” that aren’t in textual form: images, graphs, photos, GIFs, diagrams, slides, etc. also need to be intelligible and useful to future receivers.

Writing is the individual skill most relevant to Knowledge Management, and the fact that most people don’t write particularly well or often indicates why KM is also lacking in most organizations. To put it simply: the only way to share knowledge effectively is to create a culture of writing within your team. 

Here are some ideas for how to do that:

  • Senior leadership can set an example by regularly sharing their most important ideas and decisions in writing
  • Staff at all levels can be encouraged to take the time to express their thinking in writing, and rewarded when they do
  • Feedback and coaching to direct reports can include direction to develop their ideas in writing
  • Memos and other writing can be requested, circulated, and referred to in meetings and phone calls as central items for discussion
  • Meetings can begin with “reading time” to emphasize that the context for discussions is best absorbed in document form
  • Use a standard term for an internal piece of writing (such as memo, proposal, one-pager, article, or thesis doc)
  • Decide on a standard template (such as a Google Doc or Notion page), default length (such as 1,000 words or 2 pages), and method of sharing (such as email or Slack) these internal documents

The more encouragement and feedback, incentives and rewards, and practical tools and templates you can provide to your people, the likelier they are to sit down and compose their ideas in written form, and thus the more likely that knowledge will spread and make an impact.

By successfully creating a culture of writing within your team, not only will knowledge be shared far more fluidly and effectively, you will also be creating a healthier psychological environment where people believe in their ideas and are invited to find their voice and speak powerfully.

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.