Remote leaders know how important it is to write stuff down - but are you doing it the right way?
Remote leaders know how important it is to write stuff down - but are you doing it the right way?
Your company wiki is like a Bible for your team - it's where you store knowledge and get answers you need to get work done.
Many businesses use a company wiki because they want a centralised hub of knowledge. It's populated with pages that team members can add to, edit and update as time goes on. Accessible to everyone, and owned by everyone, it puts information where everyone can find it. It's often called "a single source of truth."
But most of the time, company wikis are a confusing mess.
After years of working with teams as they create and then grow their company wikis (as well as improving our own wiki over the years), we've seen the same problems time and again:
The result is an overstuffed, outdated, and ineffective company wiki. Instead of making your team more efficient and empowered to ship quality work, the wiki leaves them with a dusty pile of old documents and no clue what to do next.
A company wiki that doesn't suck, on the other hand, is the following:
But when — and how? — do you start to build it?
The answer to the first question is: day one. In fact, from the moment you write the first business plan, you’ve created a core document for your knowledge base.
Make it a priority to document processes from the start. As a founder or CEO, this isn’t really an option. Same goes for product and engineering leaders.And every new employee needs to be given this mindset too.
If you don’t currently have a company wiki, we’re going to look at what needs to be in it shortly. If you do have one, but it’s not working, there are a few reasons why this might be the case.
A wiki is made up of discrete units of information - but you get to determine how to structure those units.
The primary ways to structure info in a wiki are hierarchical and content-based.
Hierarchical design nests smaller units of knowledge within larger units in a vertical structure. Think compounds > molecules > atoms.
Examples:
A big advantage of hierarchical design is that there is a pre-determined ranking system for your information units. Everything slots into place, and things are easy to find.
Content-based design, (sometimes called graph-based design), links related units of knowledge horizontally so that you can easily move from one discreet unit to another without ranking them in importance.
Examples:
One of the advantages of content-based design is that you can more easily change the relationship between units of information without breaking the entire architecture.
In Slite, Channels and Docs interact hierarchically, while Docs and Discussions interact based on the content of each.
We also have databases called Collections. Collections in Slite can include docs, discussions, people, and even other collections. Depending on the way you use a Collection, it can contain info that's hierarchical, content-based, or both.
Examples of info that's organized both by content and hierarchy:
When you combine hierarchical and content-based design in your knowledge base, you can quickly get an overview of all your team's documentation, while also creating connections between projects and pieces of information that evolve as your knowledge grows.
A company wiki contains everything from processes and policies, to project docs to freelancer contracts and personal updates. Here are some ideas and examples to get you started.
These should be the first things that every new hire reads, and the basis on which every decision is made. Your values outline what your company stands for, and your culture describes what it’s like to be part of the team.
It’s not easy to create a company culture code or a set of core values. These take significant work and internal reflection.
But they’re essential. If you can’t define your company’s fundamental beliefs, it’s going to be almost impossible to build the company you want.
The biggest practical benefit of having a company wiki is to be able to show everyone in the company how business is done. Employees don’t need to ask how to run a meeting or how to manage the CRM - it’s all there for them to see.
Make sure that every repeated company process is clearly explained. Even better, give examples that anyone can use whenever they need. A simple meeting minutes template or script for candidate interviews means that, if it’s an employee’s first time handling these tasks, they have a massive head start.
It’s easy to underestimate how much the long-term vision can mean to your staff. They’re all head-down working on their core tasks, and it’s not their job to worry about the next two, five, or ten years.
But you want to hire people who care about the future of the business. And you foster this by being transparent about the roadmap.
Put that roadmap where everyone can see it, comment, and give ideas. The more that each employee feels invested in it, the more committed they’ll be.
Of course, your wiki also needs to contain the day-to-day stuff that makes the company run smoothly. Administrative staff spend too much time fielding simple questions from the rest of the organization.
They shouldn’t have to constantly remind people how to log paid time off, where to send invoices, and how equity works.
A great wiki provides all the information necessary for you and your teammates to get your work done. Nothing more, nothing less. Unfortunately, most company wikis don’t work. In fact, the notion of wiki and handbook feels so outdated that Bonusly refers to their Employee Handbook as the Employee Un-Handbook. In the handbook’s intro they explain:
“Everyone has had the experience of receiving a weighty tome full of policies, disclosures and legalese on the first day of work. (...) At Bonusly we like to be agile (lowercase 'a') about everything we do. In that spirit, our handbook lays out our values and guiding principles (and a small number of progressive policies) -- in an open-source document that’s easy to read and understand.”
They’re actively making sure to not fall in the all too common pitfalls of the company wiki. Let's refresh on those pain points from the top of this article. A wiki that sucks has:
On the other hand, a great company wiki is:
If you've made it all the way down here, we might as well provide some tactical tips for using Slite to get the most out of your remote team wiki. Slite can help you stay on top of things with the following features.
The main units of information in Slite are Channels, Docs, Collections and Smart Tables. While we love flexibility, we've also made each immediately recognizable so it's clear what kind of information is being stored. Last but not least, all can be linked together - for navigation that follows directions, but makes room for discovery, too.
Every Slite channel and doc is shared with the whole team by default, except the channel called "My Private Channel." By defaulting to transparency, teammates can read, write, decide and do at their own pace, without limits. At the same time, you can protect sensitive information by toggling each doc's permissions.
In addition to sharing wiki content with your team, you can also share your wiki's performance. Analytics show data like doc views, reactions, last updated, and most frequent contributors.
Working remotely means messages are often lost in chat tools and email. Move work along by having Discussions next to your docs. Discussions must be closed with a decision, so that everyone is clear on the next steps forward.
Sometimes it's easier to get your message across without writing a word. That's easy in Slite. Record a video directly in Slite, or embed a Loom or Youtube link. And if you want to draw out some thoughts, you can embed a Miro board, Figjam file, or sketch directly in Slite with Excalidraw. Programmers can include code snippets.
Our Editor contains dozens of [/] commands for you to explore your visual creativity and share your work with your team.
The best way to ensure a company wiki's success is to include everyone in growing it. As much as we find hierarchical design useful, there shouldn't be a hierarchy of who gets to contribute. Everyone should feel comfortable working on the wiki from day 1, and tools like Slite make getting involved a breeze.
Laure Albouy is Slite's first marketing hire and in charge of Product Marketing. Her role? Making sure our users get the most out of Slite —including guides, product announcements, market research and more. Laure lives in Paris and is a pasta afficionada.
Aron Leah is an illustrator and designer, who can usually be found thinking up new ways to clear his mind over a cup of coffee and has yet to realise the irony in that. His work is informed by an enthusiasm for uncovering meaning and emotion to develop ideas.
.png)
