This ensures the content of your knowledge base remains accurate. Post Maintainers and team members who have contributed to a post are notified of any changes made to that post. This makes it easy for team members to know who to ask for clarification or follow-up. Everyone who visits a Slab post can see who is responsible for that post, as well as anyone who has contributed to it. Inside our Blog topic, we’ve pinned the essential posts team members should read - and arranged these posts in the order that team members should read them in.Įvery Slab post has a designated maintainer. Teams can also pin posts inside Topics, and arrange these pinned posts however they want. The description for this topic is Discuss new content before it’s published to the official slab blog. For example, our team has a topic called Blog. Teams can add a description for each Slab Topic (much like Slack channel descriptions) explaining the purpose of the topic. Now, compare this to the topic structure we use at Slab. Yes, this gives these individuals more control over the structure of their documents - but it destroys the intention of your team wiki, which is to be the single source of information for your company. To get around this, many people duplicate Google docs, for example, and save these duplicates on their own Google Drive space, outside the confines of the team wiki. Team members conform to an existing structure that may not align with their preferred method of organization. Not everyone on a team agrees on exactly how and where documents should be stored. Duplicated postsĪ standard folder structure is also restricting. This stifles collaboration and compromises the accuracy of team wikis. If an engineer needs clarification in a code-review document, who do they reach out to? Document editors don’t provide that kind of context.Īs a result, teammates hesitate to ask for clarification or suggest changes. Once a teammate opens a document, they have no idea who to connect with to ask a question or suggest a change. As a result, it’s not uncommon for teammates to save documents in the wrong place, or unknowingly create a duplicate version of a document they never found. And still, without context, there is no surefire way of knowing what type of content belongs in a folder. This wastes time and frustrates teammates. Teammates make assumptions - or spend time parsing through the folder contents - to get the context they need. Take a look at the image below as an example:īesides the name of the folder itself, there’s nothing telling team members what type of content belongs there. These folders work fine for someone working alone or in a small group.īut when a growing number of team members contribute more content to your wiki, the lack of context associated with the standard folder structure gets confusing. They become problematic when multiple teams across a company contribute to and search for shared knowledge.īelow we break down the issues teams inevitably face when they use document editors like Google Docs, Dropbox Paper, and Quip for their internal wiki.ĭocument editors use a standard folder concept to store and organize content. In other words, document editors work great for writing blog posts and school essays. These limitations exist because document editors prioritize personal writing and editing over team reading. And while not every team needs a dedicated tool for documentation, every team should know the limitations they’ll experience by using document editors like Google Docs, Dropbox Paper, and Quip. Using a tool specifically designed for internal documentation can help. As a result, most internal documentation tools becomes stale, underused, and irrelevant. These limitations (like poor organization and unreliable search capabilities) frustrate users and slow down productivity. Teams realize the need for documentation, but aren’t thinking of how their documentation tool will scale alongside their businessīut over time, most teams find the issues associated with these tools outweigh their benefits - particularly as these teams scale.Most companies already use (and pay for) at least one of these tools.These editors are familiar to most people, meaning they can be easier to adopt across an organization.Many teams initially gravitate toward these more general purpose document editors for logical reasons: And there are tools like Google Docs, Dropbox Paper and Quip designed primarily for word processing. There are tools like Slab, designed explicitly for team documentation. They often choose the wrong tool to get the job done. Teams have dozens of options to choose from for their internal documentation.
0 Comments
Leave a Reply. |