Trying to scale the knowledge inside your noggin? All companies hit a common problem at some point—they need others to know what they know.

Internal processes like how to onboard enterprise customers, writing social media updates, what items are allowed in the staff fridge (there's always someone who puts fish in there 😒), and how to set up a development environment are all essential things to know. The best thing about writing them down is that you don't have to spend time explaining again and again. It's there. Just send them the link.

At some point you have to make a decision to start documenting your process. Most companies (us included!) start this far too late. Usually the founders are happy to explain everything multiple times to avoid the bureaucracy. But that doesn't scale forever.

In this post we'll go through some scenarios to explain how you can use a Wiki and a Knowledge Base to create better, repeatable projects. Many folks say you need to pick one or the other but at HelpDocs we've found we work pretty well using both Notion and HelpDocs to run projects.

We'll also go through the pros and cons of each type of knowledge center. And don't worry—we're not trying to shill you a Knowledge Base. We want you to do what's best for your team.

Plan together rather than alone with a Wiki

When you're starting a new project it can be tempting to push your ideas to the forefront. It's your vision and you want full credit. Trouble is it won't be as good if you work in a silo.

Planning gives everyone on your team an opportunity to contribute their ideas. You may find some ideas disturbing, some good, and some wonderful.

The truth is Knowledge Bases aren't good when it comes to planning out the new project. They're meant to be read by many rather than edited by many. This is where a Wiki truly shines.

Wikis are built for collaboration and so they're a great place to start organizing your team's thoughts and making a plan.

"Planning gives everyone on your team an opportunity to contribute their ideas. You may find some ideas disturbing, some good, and some wonderful."

Let's go through a typical example for the rest of this article.

You're a content manager looking to create a podcast and you're still figuring how to get started with it. You'll want to work out the theme of the podcast, the audience it's for, and how to distribute it.

You'll come up with a much better show if you get other folks on your team involved. It's totally collaborative and not authoritative at this point. You need somewhere to put your information but it's not set in stone.

You can gather content from experts around the web and paste it into your living document. You can create tasks for other members, set goals for the project, and generally flesh the idea out.

So a Wiki is pretty fantastic for gathering different types of content and getting everyone's ideas down. But what about when you're ready to start going ahead with your new project?

Start executing the project

Let's fast forward a bit and assume you've got a theme, an audience, and you know where you're going to host it and how you're going to promote it. You've gone through different ideas as a team and you used your Wiki as a living document.

Things got added, deleted, skimmed, and highlighted. Your new show is gonna be the best podcast in your industry.

This is where you'll wanna press pause for a second. Yep that's right—calm yourself. I know you wanna get cracking but you'll thank me later. Instead of going full steam ahead start to gather your knowledge. And this is where your Knowledge Base comes in.

Knowledge Bases are great at one thing and that's authoritative content. Authoritative content is information that a lot of people consume and only a few people write. There are the writers who know what they're talking about (the show producer, editor, and maybe designer) and then there's the reader (anyone who wants to know anything about making the podcast).

In your Knowledge Base you'll wanna write down a brief introduction to the podcast, the audience, and how you plan to promote it since you've got that nailed down. It doesn't have to be elaborate at this point and can be fired off in a few bullet points.

And you'll wanna keep your Wiki document alive at the same time. Keep your team informed by explaining things that are going well and things that could be going better. They may have some suggestions up their sleeves to make the process smoother.

"Knowledge Bases are great at one thing and that's authoritative content."

You've got your fancy microphone, the software, and the first guest. Before you hit record consider writing down everything you've learned so far like:

• What microphone settings you've got tuned in
• How you set up your recording software
• How you managed convinced someone to be your first guest 😬

You're now the leading authority on this thing. It's time to make it repeatable for others on your team. If you do this now not only will you be able to lazily follow your own advice but you can hand some of the tasks off to someone else.

Keep a rough tab on what you're doing

So you're just about to have a chat with your guest before you hit record. Now is not the time to be writing anything in your Wiki or Knowledge Base (you're probably a little nervous) but do keep it in mind.

You want to be able to hand off some of your work to others if things get off the ground so make sure to think about what you're doing so you can write it all down later.

Here are some ways to make sure you don't forget what you're doing:

• Keep a pen and paper handy. Rather than switching to different windows on your laptop keep a pen and paper there to jot down any quick thoughts.
• Have someone else with you. If you know you'd like someone else to help you with your project later on if everything goes smoothly bring them in from the start. They're much more likely to be able to help out if they know your process.

Having some quick notes or a person there will help you keep the steps fresh in your mind and the steps repeatable. Now it's time to start the show.

Write down your basic process right away

Your first podcast was a success! You had an understanding guest who helped you through the process. You stopped recording, got the podcast back from editing, and published it.

Now is the time to start writing your process down so you and your team can repeat it. You should have your Wiki page, any notes you took, and your barebones Knowledge Base article up.

This stage should be done within a few days of you executing your project so you can remember the small things that can make a big difference.

Start by writing down the main steps in an ordered list. This will help you flesh out the Knowledge Base article and turn it from collaborative in your Wiki to authoritative in your Knowledge Base.

Once you've written down the basic steps it's time to expand outwards.

"Start by writing down the main steps in an ordered list. This will help you flesh out the Knowledge Base article and turn it from collaborative in your Wiki to authoritative in your Knowledge Base."

Depending on how complicated the process is you may want to carry the information in several articles inside a category of its own. We recommend no more than 1,000 per article so if it's become unwieldy it's best to split it out.

You should also add a link from your Wiki to your Knowledge Base article. This way you'll have quick access to both 🙌

Expand your Knowledge Base article in detail

So you've got a draft Knowledge Base article based on your Wiki page, your rough notes, and the thoughts inside your head. Now it's time to expand on that and make it easy to follow.

For this podcast example we'd probably wanna split it out into a few articles. There's a clear path from planning to publishing:

• Planning a podcast episode
• Preparing for an episode: equipment, guests, and outlines
• Editing and uploading a podcast episode
• Promoting a podcast episode

Take your time to write these out. Try to use real examples and include links to any documents you made along the way.

You could include video and embed mini-tutorials of you working on the project. Something like Loom could work as you explain the more complicated workings of the project.

Finish off with any assets and review yourself

The last thing you'll wanna do is gather your assets so it's easier to follow and add them into your Knowledge Base article. This could include template files so people can duplicate them instead of starting from scratch.

If you have time now is a good chance to run through the whole process yourself. If you can't follow it it's not gonna be super useful for your team. You can then make alterations before it goes live.

Once you've done that it's ready to roll! Hit publish and follow the guide. You've done the work so now sit back, relax, and follow.

Why choose between the two?

So you've got to a crossroads. Should you create a Wiki or a Knowledge Base? I think you should use both to create better projects that are both collaborative and informative.

• Use a Wiki to plan and collaborate. No doubt a Wiki is awesome for collaboration. You can paste in ideas as a team instead of setting things in stone.
• Use a Knowledge Base for others to follow. Knowledge Bases shine over a Wiki when you have a lot of people consuming your content. Make a single article or category of articles which takes people from A to Z.

We've found using both has helped us plan, create, and execute better projects. Take it from us—we're the ones who make Knowledge Base software.