How to create a remote-first company wiki [template] |

How To Create a Wiki for Remote Companies & Teams [Template Included]

Posted by Luke Thomas

I've worked remotely since 2013, and I've never seen a single one successfully setup and maintain a company wiki. There are a variety of reasons why this might be the case, but the biggest problem I see is that they are surprisingly difficult to setup.

It takes time to think up the structure, to write down a particular process, and to document standard operating procedures.

But it's worth it.

If we look at the thoughtful companies who are leading the charge on building a great place to work from anywhere, they have all created repositories to store and share institutional knowledge. Look at Gitlab for example, their handbook is 4,000 pages.

The rationale for a company wiki is simple, yet it cannot be overlooked. Over time, teams and organizations build up "institutional knowledge" on anything from communication, to company policy, to team structure. Another name for institutional knowledge is, "the way we do things around here."

When you are in the office, you learn this way of operating through osmosis and observation. When remote, you don't have this opportunity to learn from observation like you might in the office.

This institutional knowledge needs to be documented and shared in an accessible way, especially for new employees. Otherwise, you will constantly repeat yourself and the company won't be built on a solid foundation where everyone is working from a level playing field.

To use a computer analogy, think of a wiki as the hard-drive for your company. The hard drive stores information and makes it easy to access over time. If information doesn't persist, it doesn't exist and is quickly lost. When you shut restart the computer, if something isn't saved to the hard-drive, it's gone forever.

The same principle is true at work.

The problems with a remote company wiki

Before I chat about how to set up a company wiki for workplace, we should first discuss the common issues that people run into when they try to roll out a wiki as a home.

1. Wikis can be a tax on productive people

A pain point I experienced in the past that drove me to use a wiki was when people asked me the same question over and over. I became so tired of repeating myself, that I wrote it down in a wiki and would send the post to my coworkers. The issue is that not everyone feels the pain of repeating yourself over and over, which means some people in your company will use the wiki much more frequently than others

2. Wikis can become outdated

This might be the #1 issue with a company wiki. You need to regularly prune content and remove outdated stuff. In larger organizations, I've seen full-time "librarians" who are responsible for updating a confluence instance.

3. Everyone has an opinion on the structure

Another issue that you may run into setting up a company wiki is that the structure is dependent on the individual doing the organizing. Some tools have special access privileges where a small group of people can update the structure (nesting of files, creating top-level categories, etc).

4. Digital file cabinets aren't very exciting

The truth of the matter is that a company wiki is not very exciting. It's a digital file cabinet. While the file cabinet is important, you shouldn't expect people in your company to reference it everyday. Wikis aren’t high usage tools by default. Once again, this doesn't negate its usefulness, it's just something to be aware of.

5. Not all content is treated equally

Here's another reality with a wiki. Not all content should be treated the same way. A random set of meeting notes are not nearly as important as outlining company values, goals, or KPIs for the quarter. Some content will be relevant for years, while other content will be relevant for a few days.

Despite these problems, a company wiki is still critically important for companies who want to build a remote-first operating model. I'd argue it should be a non-negotiable.

Why are they so important? I'll work to explain this in the next section before we dive into the template I recommend.

Your Company Wiki Needs to Be Simple for Remote Teams

The reason why most company wikis fail is because people try to do too much with them. The wiki is seen as a dumping ground for documents and random meeting notes, when it should be seen as a special place for the most important written content that everyone in the company needs to know about.

In other words, I'm arguing that your company wiki should be a place for your most important stuff - free from collaborative noise and ephemeral content. Let the random documentation be in Google Docs or Drive.

Who Is Your Primary Audience? Long-Time Employees vs. New Hires

The next point I'd like to make is that while your audience is the entire company, this content is much more valuable for new hires. A well-documented company wiki could save dozens of hours of back and forth, Q&A, and frustration.

Someone who has worked for your company for 5 years may not need to constantly reference your company values. But a new employee may.

Therefore, you should gear the content towards new hires as the primary audience. Additionally, you should repeatedly ask new hires for feedback on what content should be added, updated, or removed. I recommend dropping them a note 30-days after hiring.

Most companies don't do this! You should.

With all this context out of the way, let's get into the important stuff. In the next section, I'm going to share a template I recommend if you're trying to build a company wiki from scratch.

Copy This Remote Company Wiki Template

The purpose of this template is to inspire you and break down the barriers to getting started. Some of this may be relevant, while some of it may not be.

If your company wiki was a book, I'd argue that you should have three main sections:

  • The Building Blocks (pillars for the company)
  • Department/Team pages (information about each department or team)
  • The Day-to-Day (standard operating procedures and how to behave and act on an everyday basis)

Section #1: The Building Blocks

Part 1: The founding story

Take a few minutes to write down the founding story and how the company originated. This can be helpful context as to why the founder/CEO is passionate and motivated by the problem. It also can help with sales calls and other customer-facing communication.

Part 2: Mission, Vision, Values

Next, write down the company mission, vision, and values. I believe that company values may be one of the most important parts of the entire wiki. Values guide decision-making, behavior, and who you hire (and need to let go).

Part #3: Who we serve (customer personas)

Every business exists to serve customers, and capture value in the process. Who do you serve? List out your customer personas on this page.

Part 4: Why we are different

Outline what makes your business unique and different in the market. Consider highlighting competition, both direct and indirect.

Part 5: Annual Goals

Next, you should share the high-level annual goals and KPIs. Perhaps you want to zoom out even more and share a 3-5 year plan. Everyone needs to know where you are moving.

Part 6: Product Principles

This may not be relevant to you, but at Friday, we document product principles. These are guideposts and principles that guide how we build our products. I've never seen organizations do this, which is unfortunate.

Part 7: Org Structure

Next up, show the company org chart or a directory of employees who work at the company. A new hire should be able to easily navigate and answer the question, "what do you do here?"

Part 8: Hiring process

Finally, document from a high-level how you hire new employees. Do you look for undiscovered talent? Do you value credentials and top-tier schools more? While this is not as relevant for new hires, it's super important for existing employees.

I'm sure you can add other sections as you see fit, but these building blocks should rarely change (maybe update them once a year?). This section contains your most long-lasting content.

Section #2: The People and Teams

In this section, map out the departments, teams, and individuals who make up the company.

The goal is to provide visibility into:

  • The structure of the company and where teams are allocating their time and attention
  • The people who you work with and what makes them tick

Part 1: Departments/Teams

I recommend creating a page for each team or department that stores the following information on the department "homepage". Team leaders should own these pages, but I'd recommend the following content:

  • Goals/KPIs/OKRs
  • Members of the team
  • Tools and links to more information regarding standard operating procedures.

Part 2: The People

We can't forget about the people that move work forward for the company. That's why we recommend that you have each employee create their own "employee profile" that contains the following information:

The goal with these profiles is to give others enough context so that they can kickstart meaningful and fun conversations with their peers. It should also answer the, "what do you do around here" question.

Section 3: The Day-to-Day

In the final section, you should dive more into the day-to-day operations. This content will change a bit more frequently compared to the first two chapters. In this chapter of your company wiki, you should provide guidance on how to be successful in the day-to-day.

Consider including the following information:

Part 1: Policies

Outline vacation time, PTO, expensing, benefits, and other policies. This content will be referenced regularly by new and existing employees, which is why it's in the day-to-day chapter.

Part 2: How we communicate

On this page, document how your organization should communicate. Should Slack be used sparingly? Should you turn on your video camera when taking Zoom calls? What is your stance on meetings? When should that meeting be an asynchronous update?

If you don't outline expectations here, you shouldn't expect people to automatically pick up on them. It's much better to be crystal clear with your expectations.

Part 3: Tools we use

Finally, you should share a bit more about the tools that you use and why people should use them. For example, workplace chat, password managers, Google drive hygiene, etc.

In Conclusion: If You Don't Have a Company Wiki, You Aren't Doing Remote Work Right

It takes time to create a company wiki for your company, but if you want to be successful when remote, you MUST have a central place to share key information. If you don't, people will have different expectations and you will struggle to create predictability in the business.

I hope this article helps you successfully create your first remote-first company wiki. If you have anything you think I should add, feel free to drop me a note.

Your operating system for working from anywhere
Try it Free

The easiest way to work from anywhere