In the age of digital-first, AI-empowered operations, your company’s knowledge base is an operational lifeline. Leaders who understand this are already reaping the benefits of rapid scale, efficiency, and improved culture.
Here’s a complete, detailed guide to setting up a handbook, intranet, or knowledge base for a distributed team at any size.
In this post:
The term “handbook” is misleading.
A handbook feels like something small, self-contained, static — a little PDF you could print out and put in a binder, read once when you start your job, and then forget about it.
In the age of digital-first, AI-empowered operations, a living knowledge base is an operational lifeline. Leaders who understand this are already reaping the benefits of rapid scale, efficiency, and improved culture.
It’s impossible to overstate the value of great information for a distributed organization: it impacts efficiency, productivity, culture, security, innovation… and more. The word “handbook” fails to capture the impact.
Every virtual-first company needs a knowledge base that:
>> Is digital, searchable, AI-friendly, and integrated with other tools
>> Can be easily updated by internal team members
>> Contains SOPs/playbooks to help people work efficiently
>> Supports a stronger culture and promotes team engagement
>> Has measurable outcome targets and a strategy to hit them.
While there are plenty of templates out there for how to organize your information, I suspect that most orgs don’t need to know how to do it; they need a clearer understanding of why.
Bad information: the $47 million problem
It’s been estimated that the average large business loses $47 million per year due to poor knowledge sharing. If you’re reading this, you may already understand the risk. But most companies have a very limited idea of what a “handbook” is, and they vastly underestimate the impact of a powerful knowledgebase.
To understand how this works, let’s run some scenarios.
Scenario A: I have a question. I search the intranet and find the answer. I move on with my day.
Scenario B: I have a question. There’s no central knowledgebase, so I go looking for the information. First I search Google Drive, and then I send a note to somebody on Slack. They don’t know the answer, so they share the question with more people. Ultimately my question reaches someone who has the information, and they schedule a “quick chat” with me the following day.
In this scenario, we’ve lost at least a day of real time — plus 30-60 minutes of my working time, 30 minutes for the person who now has to update me, and 5 or so minutes of other people’s time.
Not to mention, we’re all a little ticked off.
Scenario B doesn’t happen every day, for everyone — but it happens a lot. A very conservative estimate: at a company with mediocre knowledge management, each person wastes an average of 10 minutes per day just trying to find information they need to do their jobs.
For a team of 100 people, that adds up to 16.67 hours wasted every day — the equivalent of two full-time people. Expand that math further: for a team of 1,000, you could be losing close to 50,000 hours per year. And again, that’s a conservative estimate; at many companies, it’s likely twice that much or more.
Add to that the many difficult-to-measure impacts: frustration, siloing, risks of duplicated or poorly-informed work, slower communication, increased context switching, and overabundance of meetings.
So a company’s approach to knowledge sharing is truly much more than a “handbook.” We’re talking about a cultural practice which affects every person, team, project and function of the company.
An operational lifeline.
In the age of AI, knowledge management is a must-do
As AI makes itself a key element in organizations, we’re going to see a big boost in efficiency for companies that have a searchable, up-to-date knowledgebase. The reason should be obvious: just give an AI access to your information, and it can help answer people’s questions on the fly.
Companies with robust handbooks are already implementing more advanced uses of AI, such as:
- Identifying initiatives that can be aligned or combined for better efficiency
- Automatically sharing updates on key projects and outcomes
- Tracking engagement metrics to understand issues employees need help with
We’re just starting to understand how AI can unblock information and help people work better and faster; but if your company doesn’t have a solid base of information already in place, you’re entering the AI age at a disadvantage.
How to start creating your knowledgebase
Start simple. No need to over-think this: you can get started by pulling together the information that’s already scattered across inboxes and folders throughout your company. No matter where you’re starting from, you’ve already written down a significant amount of useful information. In this phase, you’ll audit your existing written communications and documentation: emails, slide decks, notes, agendas, Slack discussions…
- Designate an information audit group, objectives, and outcomes. I highly recommend your working group includes someone with an engineering or technical communications background, in addition to communications experts and someone with DEI expertise.
- Work with your IT team to open up access to information without compromising security or team members’ sense of privacy. Some information can be scraped, but I advise against scraping personal email archives or drives; instead, ask people to share emails and files on specific topics within their purview.
- Consider incorporating a GenAI tool to help compile and organize information as it’s discovered.
- Your information architecture will begin to emerge naturally (again, technical communications experts can help here), and you should end up with a functional framework that’s ready to fill in. Keep reading for more thoughts on building your content.
How to choose & implement a handbook/intranet tool
The right tool for your team is absolutely essential to its success. This is not a decision to take lightly.
It’s common to hire a consultant or project lead with intranet expertise to manage the vendor review and catalog needs, along with a decision-making group of leaders with skin in the game. The process can take months, and it’s worth the time.
Choosing the right handbook tool for a small remote company
(2 to 100 team members)
For a small and growing team, the outcome you should seek is minimizing inefficiencies before they balloon. Small teams usually rely heavily on individual expertise and knowledge, making it difficult to transfer knowledge when someone leaves or a new person joins. If you’re planning to grow, this will block you.
Small teams do well with a wiki-style knowledge base that can be adapted to your needs, and where everyone on the team can add or edit information. I’ve had great success with Notion; more technical teams might choose something closer to a true wiki, like Docuwiki. Check out how Oyster uses Notion for inspiration.
Word of advice: Confidentiality is a big risk in small teams. Leaders should carefully consider what information you’re sharing in public channels — especially if you’re new to transparent documentation. With wiki-style handbooks, it’s easy to mistakenly publish information to the whole company.
Choosing an intranet tool for a medium-sized remote company
(101 to 1,000 team members)
There is a huge difference between a company at 100 people vs. 1,000, so your mileage will vary. But no matter your size, whether you’re in scale or maintaining a stable equilibrium, a medium-size company absolutely must have a functional knowledge base. Informal knowledge-sharing won’t cut it — think back to the time wasted I mentioned earlier — so to fight chaos, build a strong structure and allow everyone to contribute.
Companies at the lower end of this range might still use Notion, but larger orgs should consider a tool with more centralized information management, outstanding searchability, plus some social-friendly features to help people get to know each other. I have been very happy with Haystack, which has a clean, user-friendly UX while maintaining strong editability and team-building features. For inspiration, here’s Thumbtack’s customer story. (Confluence is another option for engineering/product teams already using Jira, though I don’t recommend Confluence for non-technical teams.)
Word of advice: Hiring an intranet expert will greatly improve your outcomes here. You may choose someone temporary to oversee the implementation, and/or an ongoing person to keep things tidy and functional. Whatever you do, don’t under-resource this. I recommend calculating your time savings, then carving out some portion of that budget to fund a role.
Knowledge management tooling for a larger distributed company
(1,000+ team members)
Large companies are a completely different ballgame — primarily because most of them do have an intranet, and their intranet is not great. Either the intranet was set up a decade ago and is completely clunky, or it was built in-house and it never quite works right. The former is usually true at legacy orgs, while the latter is incredibly common at engineer-driven companies (looking at you, Apple).
Many larger organizations use SharePoint, but I don’t recommend it. In fact, the only recommendation I can make here is: hire an expert, a consultancy if necessary. You can’t afford to overhaul your intranet often, so invest in doing it right this time. Conduct a complete audit of your internal needs plus the tech available (and/or options to improve your internal tech, if you’re married to it).
Word of advice: This is probably obvious, but you need a tool that’s tech-forward and adaptable — particularly regarding searchability, individual contribution, and AI integration. The near-future of big intranets is a chatbot interface, but the longer-range future is leveraging AI to analyze information and pull out insights and even business ideas. Don’t sleep on this potential.
How to structure your distributed company’s knowledgebase (so you don’t have to rebuild it later)
You really only want to do this one time. So, choose a structure that will grow and evolve with your company. There are many templates online for building company handbooks, but they usually fall far short of what digital-first companies really need.
The early adopters of remote work have done much of the trial-and-error already: I highly recommend Doist’s account of their lessons learned and handbook redesign.
Think of your handbook as a mirror of your company’s DNA—it’s not just a set of policies, it’s a guide to who you are and how you operate.
As I mentioned above, your process starts with an audit of the information you’ve already written down. You’ll probably find there are several big buckets of info, such as:
- Company information (org chart, mission, values, leadership)
- Onboarding & training
- Essential employment resources (policies, workplace information, HR documents)
- Culture & team building (internal communications, events, team profiles)
- SOPs and playbooks
The first three are universal and self-explanatory. You’ll do most of your customizing around #4 and #5.
Customizing your culture and teambuilding resources
Done right, this section of your knowledgebase can be the best part.
You likely have a function (or a person!) overseeing culture and engagement at your company: Internal Comms, DEI/DIB, L&D, or something similar. They should be given license and opportunity to play in this section of the handbook. Their work is often experimental even as it is programmatic: a series of initiatives that respond to current and future needs. These teams are usually also creative and passionate.
I recommend setting up a landing page that summarizes key, evergreen elements of your culture: a link to your values and mission, a quote from the CEO, a team photo, how you measure and track culture and engagement. From there, you should have subsections or subpages for current and past initiatives, which can be maintained by your culture experts.
But this can go beyond documentation, if you’re using an intranet-style tool with features like events and announcements. Give your culture people some real estate on the handbook homepage where they can share what’s new and upcoming. They will often have good things to share, and it’ll make your entire knowledgebase feel vibrant and active.
Playbooks/SOPs: the lifeblood of remote-first teams
If you aren’t familiar: an SOP (Standard Operating Procedure) is a key resource for almost any type of team. It explains, as clearly as possible, how to do something that people will need to do frequently and consistently. These are also called playbooks, and they are invaluable for distributed teams — whose members might need to do something quickly and/or during a time of day when nobody’s online to explain it to them.
The playbooks you’ll need are completely unique to your company. They can cover everything: how to handle a customer service interaction, how to set up your email signature, how to order swag… the list is potentially endless. And because a playbook can quickly become outdated, you should be selective about which processes you document and who’s responsible for updating them.
I highly recommend making this a function/manager responsibility. Every team should be responsible for deciding which of their processes they can commit to building playbooks for, and they should also be required to review and update them every six months. Framing it like this, managers should be able to predict how many playbooks their team can reasonably support — preventing them from over-documenting (hopefully!).
How to create and maintain a living handbook for your remote team
Who owns the handbook?
In times past, HR was responsible for the employee handbook. They would typically update the policies annually and send out a fresh PDF. This is no longer the way.
For distributed teams, it’s best to designate a single role or team as handbook handlers. This should be someone with communications training (ideally technical communications or internal comms) and experience working with both vendors and IT. This person will be responsible for making sure your knowledgebase is working correctly, integrating with key systems (Slack, email, project management…), and being kept up to date. They will monitor metrics for engagement, and remind people to update their information. They also support people who aren’t comfortable building documentation, helping them organize and draft their playbooks.
However, just because you have a handbook handler, that doesn’t mean they’re the only ones working on it…………….
PSA: ALLOW EVERYONE TO EDIT YOUR HANDBOOK
Sorry for using my big voice, but leaders need to hear this. Locking down information access is a bygone practice, and it will kneecap your team by serving them outdated, stale info. They’ll almost immediately stop using the handbook entirely, and will revert to inefficient 1-1 knowledge sharing.
For distributed, tech-forward companies, editable knowledgebases are the status quo. If you don’t give people permission to add and update information, this entire project will be fruitless.
During my time at GitLab, the company handbook accepted contributions not only from the internal team, but from anyone, anywhere. The handbook itself was also open to the world. Post-IPO, some information became internal-only, but much of the company knowledgebase is still open and public.
Managing user edit permissions for your knowledgebase
All the tools and processes I’ve covered in this blog include fairly robust user roles and permission settings, which will be key to making this work. After all, you want your accountants to be able to edit the information on budgeting (e.g.) — but you don’t necessarily want everyone else to edit.
There are two main approaches for this, which can be used interchangeably depending on your tooling:
Option 1: Let anyone suggest edits, but designate owners/maintainers who must approve changes to their sections
Option 2: Give specific people full permission to make edits, limited to individual sections.
GitLab is in the first category: anyone can submit changes, but only page owners can approve. There are typically 1-3 owners for any given section of the handbook. This is highly efficient (since anybody who identifies a problem can just submit the fix, rather than having a discussion and asking someone else to fix it). However, it can result in information bloat to a point where nobody has time to review and update everything that’s been documented over the years.
Most remote-first companies should use the second approach, giving teams or functions their own “space” to use how they like. This is slightly less efficient, but you’ll end up with more relevant, up-to-date information that evolves with the work.
No, you don’t need to build in public (but you should practice internal transparency)
Many of the early adopters of remote work were tech startups with roots in the open-source culture, and we believed (as I still believe) that information should be free unless it would be risky or harmful to share it. Right now, if you search for information on creating a handbook, you’ll see lots of companies advocating for making your handbook information public.
Nah. That’s your decision, and it should match your company’s culture. There’s no particular reason you need all your SOPs to be public information.
However, you should prioritize internal transparency, as a strategy for efficiency and trust improvements. This guide is oriented toward leaders who understand the value of transparency in a modern distributed organization. If your company culture is low on the trust-and-transparency scale, you probably shouldn’t be working remotely in the first place.
How to measure your handbook’s performance: key metrics
A handbook isn’t just a reference; it’s a performance asset. Measure it as such. Having the right KPIs can help you understand what’s working and what isn’t — and hopefully, you’ll also get a sense for how much time it’s saving or value it’s creating.
Direct metrics you could track:
- Overall number of pages: set a target range, so you understand if your information is too thin or ballooning out of control
- Views (rolling 7/30/365): look for dips in traffic specifically, though spikes can also be interesting 👀
- % of pages not updated (rolling 6-month): anything that hasn’t been updated in 6 months needs a review.
- % of teams/functions with published playbooks/SOPs: is everyone committing to sharing information? This can surface culture issues, manager issues, and/or siloed teams.
- Most viewed content: does this match what you want/need people to know?
The real juice, though, comes from the second-order impacts. What is your objective with setting up a powerful knowledgebase? How will you know you’re hitting the outcome you’re after? Some ideas:
- % reduction in repeated questions (e.g. in an #ask channel or HR form)
- % reduction in new hire onboarding time (e.g. a new team member is ready to step into their role within 2 weeks instead of 3)
- % increase in eSat or positive sentiment around company culture
- % change in tasks completed for roles with documented processes
- % change in self-reported productivity and access to information
If you’ve followed the advice in this guide, you will see these metrics move (though if you don’t, send me a note and yell at me about it so I can fix any bad advice).
What gets measured gets done, right? If your handbook isn’t helping, it’s just another document. Make sure it works for you.
Conclusion: what you can do right now to start building a great handbook
A handbook is a powerful tool that bridges the gap between remote operations and cohesive team culture. Though there’s a lot of information in this post, this process is not about adding more complexity: it’s about simplifying and clarifying processes, so people can just do their jobs. As such, it’s simple and easy to get started.
The 5-minute quickstart — do this today:
- Bookmark the handbook cheat sheet
- Set up a “bucket” (a shared folder for dumping information into)
- Block off some time with key stakeholders to start the discussion. Have them read this guide first.
This truly is a process that can start small. Start today, stay consistent, and your knowledgebase will evolve into the essential remote team asset you always needed.
