How do you organize information in your company? Who has access to it, and is it easy to find what you’re looking for? Is there a standard process for reviewing and updating information? For many companies, the answers to these questions are murky at best.

As Pliancy’s Knowledge Lead and one of Pliancy’s early employees, I’ve been involved in multiple iterations of our internal knowledge base (or KB for short). We’ve created hundreds of articles to boost the learning experience and answer questions for our internal teams. Getting started with a KB is not easy and takes time and effort.

When all is said and done, it makes a difference when everything comes together and the readers—the internal team—have resources to look back on for their success.

What Is Knowledge Management?

Knowledge management is exactly what it sounds like—collecting, coordinating, and maintaining information for a group or organization. This can include both technical knowledge and operational knowledge.

A central repository for information, known as a knowledge base, is a vital component of knowledge management. Company knowledge bases can be external (public, client- or customer-facing) or internal (private, for employees and team members). Though our KB is primarily for internal use, many of the principles below will apply to both internal and external knowledge bases.

Internal knowledge bases aren’t only useful for the employee onboarding process; they’re a treasure trove of self-service information for longtime team members and new hires alike. KB content can include cheat sheets for new employees; training materials for new managers; benefits info such as plan summaries and time-off policies; historical reference materials; and client details for cross-functional collaborations.

The Pliancy Knowledge Base

Our knowledge base currently has over 800 articles on topics varying from our benefits package to information security. It’s managed by a team of two, and over 80% of it was written by the very professionals who use the information. The content is regularly reviewed and updated for accuracy, has a better than 95% employee adoption rate in any given month, and is heavily leaned on by leadership whenever we need to disseminate information.

I’m proud of what we’ve built. Do we get it right all the time? No, of course not. But through more than a little trial and error, we’ve learned what we want to build, what works for us, and what doesn’t.

As daunting as the task may seem, you don’t need a dedicated Knowledge team to start prioritizing knowledge management at your organization. You just have to commit to a few simple principles, then dive in.

How We Built Our Knowledge Base—And How You Can, Too

If you’re reading this post, I suspect you’re in one of two positions:

• you’ve had it with your company’s random docs and folders, each filed according to a cryptic and unknowable logic, and you’re building a brand-new internal knowledge base, or
• you have a KB that’s struggling to gain traction, perhaps because the information has already become stale and is of questionable value.

Whatever brought you here, we probably agree on the importance of high-quality documentation that our team members and clients can rely on. The reality is that KBs are hard to build and even harder to maintain—but that doesn’t mean it’s impossible.

The Three Pillars of a Good Knowledge Base

When founding an internal knowledge base, embrace accuracy, organization, and formatting.

Accuracy: Aim for Accuracy Above All

No information is often better than incorrect information. Misinformation in a knowledge base can spread throughout an organization quickly. Prioritizing the quality of your information will help minimize the risk of “bad” information taking root.

Organization: X Should Clearly Mark the Spot

You can’t use information if you can’t find it. Functionality is the name of the game, and this boils down to grouping content logically and consistently. There are a million different ways to design this system. Pick what works best for your company and, more importantly, stay true to that system. (In other words, don’t make changes to your KB’s organizational system or hierarchy lightly.)

Formatting: Looks Aren’t Everything, But They’re Not Nothing

Well-formatted—and consistently formatted—information is easier to understand and more enjoyable to consume. Content should feel similar across the KB, regardless of authorship. Examples to consider include how articles are structured and the overall tone of all content. As with organization, consistency is key regardless of your choices.

It seems remarkably simple, but I’m sure many of us have worked at companies where one or all of these items are afterthoughts at best. When that happens, the cracks show up fast.

Choose Your Preferences & Stick With Them

There’s an entire conversation that could be had about which documentation software is best, which integrations to use, which organizational structures are the easiest to navigate, and the most appealing way to style instructional content—but that often boils down to preference.

Similarly, there are a lot of user-friendly ways to order and present information. When building a KB, the trick is to make decisions early and stick to them, whatever they are. No matter what choices you make, accuracy, logical organization, and consistent formatting are foundational and exist in their own realm, independent of our opinion-laden ideas.

Let the Experts Lead the Way

To capture information in its most accurate form, the people who know the most should write the most.

Usually, the people using information know more about it than a technical writer ever will. For example, let’s consider the good ol’ automobile engine. Interviewing mechanics and writing about engines will teach you a lot. But a mechanic will have a nuanced understanding of their craft, even if they stink at describing it to laypeople, that a writer couldn’t attain from research alone. You can’t get the context dialed in without being down there in the engine’s guts, turning screws, and knocking things around.

If you need to document the procedure for changing a water pump on a V8, and a mechanic tells you they want to write it, why get in their way? That’s exactly what a lot of organizations do, simply because the expert is unlikely to be concerned about taxonomy or a meticulously defined style guide. But what’s more important: accurate information with all the gotchas included, or avoiding a bit (or even a lot) of editing later on? Hopefully you know by this point that I suggest biasing for accuracy every time.

Empowering Your Team Members to Share Their Knowledge

If you’re lucky, maybe you have a subject matter expert on staff; someone who used to work on the front lines of your company or industry before they got tired of making an honest day’s wages and decided to start writing about it. You can, and should, lean on their expertise (shout out to my Knowledge partner, our Technical Content Producer, and former consultant, Rich Friedland).

Knowledge Management Is a Team Sport

Even if you have a Rich of your own, you’re still trying to document a vast domain of knowledge. Documentation and content work may include support for teams as varied as finance and engineering. In this paradigm, empowering your teammates to author documentation is essential to creating a robust and sustainable KB.

Knowledge management isn’t a solo endeavor: it’s a team sport. You need colleagues to identify what’s important, experts (and/or technical writers) to write that documentation, and a knowledge manager to make sure the information is both locatable and presentable.

Safekeeping, Not Gatekeeping

Knowledge management exists, in part, to preserve institutional knowledge. It is a precious resource that should be preserved and guarded as such—that’s why we value safekeeping over gatekeeping.

Curation woes are the most significant consequence of not gatekeeping. Well-meaning folks can misunderstand what’s valuable to the company from a knowledge curation perspective. This creates static in the KB, but it’s a hazard we acknowledge and resolve as we’re able.

In our internal knowledge base, I estimate there are about 50 articles that might not be needed. This represents only about 6% of our total content. Given the choice, I’d much rather have 750+ necessary, quality documents with 50 duds rather than a scant 200 docs and no static.

Don’t Recreate the Wheel

A company knowledge base should focus on unique information that isn’t available anywhere else.

Any information available on the first page of a Google search is not knowledge base material. A KB’s job is not meant to be a gigantic one-stop-shop for all information. Regardless of whether a knowledge base is internal, public-facing, or both, its content should be information that is specific to your organization. Unique company information might include how your product works, what your health benefits are, or the iron-clad rules for your company’s hyper-competitive Halloween costume contest.

It can be tempting to document third-party tools. But unless Excel’s documentation is missing a critical piece of info that your team crucially has to have, don’t waste your time.

Do’s and Don’ts of Knowledge Base Articles

Here are some examples of topics that should and shouldn’t be included in a knowledge base:

Include

• Benefits information
• Your company manifesto
• Company-specific policies and best practices
• How to install your super sweet software
• The workaround for that bug in super sweet software that melts computers
• The top-secret code to the dumpster out back

Avoid

• How to install [ubiquitous software everyone uses] on Windows
• Any docs for a third party
• Passwords and sensitive information
• The history of your industry since 1900

Building Your Knowledge Base: Start Small, Start Today

You don’t require a technical writer or professional content slinger to start building a great KB. You only need a deliberate process that places accuracy at the top of a triangle, with organization and formatting falling in line underneath.

On behalf of technical writers everywhere, I think I’m contractually obligated to say: hire us, please. (Most of us are English majors with families that we’re honor-bound to wave all non-unemployment-office paychecks in front of.) But just between you and me, reader? You can get away without hiring a technical writer for a little while, especially if your resources are limited. As long as you have a knowledge management strategy and someone to keep you in line with the three pillars of KBs, I like your chances.