It should come as no surprise that Slab employees use Slab — a lot. Every day, we rely on Slab to collaborate on projects, document our ideas, and keep our knowledge fresh. The more we use it, the more we learn how to make it better for everyone (although, honestly, we'd use Slab even if we didn't have to). 😄
We're excited to share how we use Slab, the tool, to run Slab, the business. Before we dive in, a reminder — there are many ways to use Slab. (That's what we love about it!) This is what works for us, but a different style may work better for your team. If you have any questions about maximizing Slab for your use case, feel free to get in touch!
We'll get to our exact setup in a minute, but first, we wanted to share our high-level thoughts on creating a knowledge hub. Above all else, we think that a wiki should empower teams to access the knowledge they need to do their best work. This is our raison d'être, so naturally it informs the way we interact with our own wiki.
Our broader values guide us here, too. For example, our desire to "stay lean" is reflected in what we choose to document, and how. Of course, we're strongly pro-documentation, but too much can backfire, making it difficult to find what you need. We're also careful not to duplicate information across topics — it's much better to create a single post and assign it to multiple topics. And, as the old adage goes, we try not to use two words when one will do.
"Default to open" means that we use Slab to make our documentation as accessible as possible. We're receptive to input and we welcome the exchange of knowledge, so we use Slab to share our ideas, collect feedback, and engage in dialogue. All teammates can access every part of our knowledge hub, and nothing is siloed. That being said, there may be a time when we do want to keep some posts confidential. For example, our HR team might want to house sensitive employee information in Slab. Fortunately, we can easily privatize any topic we want — but for now, we default to open.
We're not afraid to "say no" — we're choosy about what information lives in Slab, and what information is connected to Slab. It's important to have a single source of truth, but we still use plenty of other tools that store information in different ways. Instead of trying to replace these tools, it's more helpful to integrate them. For example, we like to embed tables from Airtable, rather than attempt to re-create them directly in Slab. This gives us our tables more flexibility, and therefore makes our content more useful.
We do our best to "think rigorously" about the information architecture of our Slab. It needs to feel logical to and be easily navigated by all of our teammates, not just those who set it up. The last thing we want is for anyone to waste time hunting down information, so our architecture needs to make sense to everyone. We try to be as rigorous and intentional in our own documentation as we are in our product-building!
While this list isn't exhaustive — we could go on about our knowledge-sharing philosophies all day! — these ideas drive the way we use Slab on a day-to-day basis. Again, your mileage may vary, but our mileage has been pretty good so far. 😎
Our Slab is organized at the team level — meaning that each topic corresponds to one of our teams.
Rather than trying to apply a single structure across all teams, each one has the latitude to design their topic in the way that makes the most sense for them. This means that some teams meticulously organize every post within a subtopic, like our content team. See in the image below how our content team organizes their articles by subtopics (Work Smarter, Writer Louder, and Behind Slab). These subtopics correspond to the categories we use on our blog.
Other teams use pinning and post series to keep their content in order, and still others don't necessarily need their content to be read in a sequence. Some teams include dedicated read-mes or how-tos for navigating their topic, and some take a more learn-by-doing approach.
There are also a few exceptions to this one-team, one-topic structure — important high-level information also gets its own topic. Our Company, topic, for example, contains information relevant for all teams, including our Employee Handbook, a write-up of our values, all-hands meeting notes, etc.
If you couldn't tell by now, we think flexibility is very important. Everyone works and learns differently, and for every rule, there's an exception. We want to empower everyone to do what makes the most sense for them. There's a reason we designed Slab to be highly flexible! 😸
Learn more about setting up your own architecture.
Our team spends a lot of time in Slab — for some of us, it's the majority of our work day — so most features get used pretty often. But there are a few key tools that we just couldn't live without!
There are a lot of powerful ways to format content inside posts, including using block quotes, code blocks, and tables. But lately, our team has really taken to using hints! Hints are an easy way to call out important details in a post, such as instructions, good-to-knows, and warnings.🚨
Learn more about formatting options in posts.
Comments and mentions
Our work is highly collaborative, so we rely heavily on comments to leave notes or feedback, and on mentions to loop in teammates. Mentioning other posts also helps us ensure that we can quickly access crucial context that's stored elsewhere.
Learn more about using comments and mentions.
While we love all of our integrations, Slack, G Suite, and GitHub are among the most-crucial to our workflow. All of the tools that help us do are best work are right within reach!
Slack: As a distributed team, we use Slack constantly, and we rely on it to notify us of any changes or comments to posts we care about. This helps us close the communication gap — even if we're thousands of miles apart.
Dropbox: Our designers use Dropbox to store all of our feature mockups. Rather than have to open up Dropbox to find a specific design, we can search right inside Slab!
GitHub: Our engineers sync files from GitHub into Slab, allowing them to more easily organize and store their most important repos.
Learn more about what can be integrated with Slab.
We regularly work with contractors who need access to some knowledge we store within Slab — but not all of it. So we assign guest access to these contractors (like our blog illustrator). This way, they can dive right into our hub and make edits to posts, while we can retain control of what other content they can access. 🤝
Learn more about guest accounts.
Every now and then, we want to share a specific post with someone outside the team. For example, our support team created a series of public posts to help newly-onboarded customers with particularly complicated migration needs. In those one-off cases, it doesn't make sense to add guest users, so we take advantage of public posts. These allow people check out something that lives in our Slab without having to sign in or sign up.
Learn more about public posts.
While there are quite a few ways to measure the usefulness of your wiki, one thing's for sure — outdated, stale content is definitely not useful. That's why it's really important for us to keep our documentation fresh and up-to-date. Right now, our team is small and very hands-on, so this requirement is pretty much met with little oversight. We're constantly and proactively updating and editing posts. Our Activity feed looks like a news ticker, and our inboxes are always filled with updates! This gives us a good idea of what's fresh, and what needs to be checked on.
However, we know that this might not always be the case, and we'll eventually get to a size where some oversight will be necessary. That's why we built our verified posts feature! It's designed just for this purpose — to help team admins keep an eye on content that needs to be updated. Designated post maintainers will be regularly reminded to give their content a once-over, and once a post has been checked, it'll show a badge verifying that it's up-to-date. Freshness, handled! ✅
Learn more about post verification.
How can we help?
As much as we hate to sound like a broken record, it bears repeating — we purposely designed Slab to adapt to every team's needs, not just our own. This is a brief snapshot of how we use it, but there's no substitute for hands-on experience. The best way to learn how Slab can work for you is by...well, making it work for you! We're here to help — our wiki experts are ready and waiting, just a click away.