top of page

How to Build Effective Internal Wikis?

  • Writer: Nitish Mathew
    Nitish Mathew
  • Aug 23
  • 7 min read

Updated: Sep 13


Library with tall shelves of nonfiction books, categories visible in a bright space and a calm, organized atmosphere symbolizing order.

Does your company's Notion/Confluence look like the messy second-hand bookstore below or the well-organized library with relevant new books, cataloged correctly and easy to discover?


Crowded bookstore with stacks of books on the floor and shelves symbolizing mess and disorder.

If it is the latter, you are not alone. Managing unstructured data in internal documentation remains an unsolved problem in most companies. Quality of unstructured data such as internal docs has become a hot topic, thanks to the Gen AI revolution, as they are an input for various use cases such as internal helpdesk, HR queries, business context for software logic etc. Effective documentation is a foundational piece of all management. Without on-boarding guides, operational manuals, corporate processes written down, you cannot run anything effectively and efficiently. It doesn't need advanced technical sophistication. It is something anyone with a practical approach to management, decision-making authority and disciplined execution skills can do.


What can you do?


Here are some ideas and practices that worked for me across various roles:


  1. Have a single system like Notion/Confluence/Coda as your corporate Wiki.

    There is usually a profusion of tools with significant overlapping capabilities in every company. In addition to that, vendors release new features all the time that increase the feature overlap (understandably, to become the single-source for everything, and reduce their replaceability). An average company may have Slack for communication, GitHub for software, Jira + Confluence and the Google or Microsoft enterprise suites for documentation, email, calendaring etc. Start with communication guidelines along with, or before, you tackle documentation. It doesn't matter which one you pick as long as it is a single one. This could be hard in complex organizations and is a responsibility of the leadership team. It is impossible to satisfy everyone. Have the discussions, debate earnestly, make the call, and get on with it.


    In addition to designating a tool as the corporate standard for Wiki, consider turning off similar features in related tools. For example, if you keep Slack Canvas turned on, even if you don't market it internally, you are implicitly telling people that it is OK to use it and now it becomes another Pandora's box.


  2. Designate owners

    A designated team or person has to be given the authority to own and drive the implementation, so they can be held accountable. Everything we consider trustworthy and useful, from Wikipedia, the Wall Street Journal, to the Nature Journal has an ownership and governance structure. If it is everyone's problem, it is no one's problem. You need owners for sections in the lower levels of the structure as well. If you are one of the leaders using a chosen system, take control of your section and keep at least that section well-organized.


  3. Lock down the first three layers of your organizational/team Wiki tree structure

    Think about the difference between any grocery store chain run by any corporate, anywhere in the world, and a neighborhood garage sale. Imagine if you go to your grocery store and the milk is at a different location everyday. So, keep those groups stable so people get used to navigating the structure. This is possibly the single-most important step that can reduce chaos and set an example for the pages deeper in the hierarchy.


  4. Thoughtfully limit the number of sections at each level

    There are 16 top level sections in WSJ.com as of Aug 22, 2025. Someone decided that number and what the content should be. Make that decision for your Wiki. These decisions are data points that is metadata and conveys relative importance of things. Use that capability to communicate what is truly important. If Values and Principles are important, put them up high. You are sending an explicit message that behaviors are important in addition to technical expertise.


    ree

    Thoughtfully limiting subsections improve readability in addition to providing context to human readers and the opportunity to discover related content.


    ree

    Search for Best Practices for Confluence, Notion, Coda etc. and you will find useful documentation the vendors would love for you to use, like the examples in the screenshots below, to get the most out of their products. Please spend time to read them and coach your team, ideally as part of the launch. It is shocking to see how fast things can get totally messy without providing any direction.


    Confluence Best Practices
    Confluence Best Practices
    Notion Best Practices
    Notion Best Practices
  5. Train people on quality for written content

    Set standards for clear writing. Getting your team to spend an hour on a course like Business Writing Principles can improve the quality of your content, in addition to helping people develop skills that will help them in their career. A well-structured Wiki with hard to read content is not useful.


    These may sound too basic or unnecessary. Spending time on coaching writing skills has generated immense value in leveling up the people I led. Writing well is a skill that is important for people in all functional areas for career progression. In a future where English may become the most common programming language, the most effective programmer may be the one who can clear understand the requirements and prompt the LLM!


    While tools automate creation of documentation with AI, use it only to polish things. Writing helps you think better, understand the material and help discover new insights. See Writing to Think and Putting Ideas to Words. The goal is not quantity. It is quality. Your thinking, translated into writing, should be powering AI; don't outsource thinking to AI.


  6. Eliminate redundant and outdated documents

    Purge unused and deprecated pages mercilessly. You do not keep stale food in your pantry or expired medicines. The same logic applies to your knowledge repository. Having clear owners are key for this. How do you think libraries keep buying new books while not expanding their building space? They sell old and unused books to make space for the new and useful. You pay a hidden cost of confusion, passing incorrect information even if storage costs are low. Cost of keeping knowledge stored in video recordings embedded in Wikis can be substantial and elimination of the old can translate directly to savings. Most tools have ways to set expiration or review dates, automated archiving of unused content etc.


  7. Do not repeat yourself

    Ensure that the same content is not repeated in multiple tools. That is a recipe for confusion. For example, don't try to explain complex business logic in both a Google Doc and a Notion page. If you used the Google Document for design discussions, simply lock the document down and add it is a link in the Notion page. To drill a bit deeper, say for an application, there are status codes for transactions. If the product engineering keeps adding new transaction types all the time, and the master source is a tables in the data warehouse, don't add them as a static table on a Notion page. If you want to add it for general information that there are transactions and status codes, put a screenshot of the tables, add the as-of-date and provide a link to the table's catalog information so people know where to get the latest data.


  8. Think through how the Wiki fits in the overall communication strategy

    Documentation starts with the need to communicate things for now and for the future. Anything that is written down in course of work in organizations, that can be read by humans or indexed by search engines, can be considered documentation. Slack/Teams/Google Chat messages, Google/Word documents, Jira tickets, Confluence Pages, GitHub code, Wikis etc. come under it. You should consider the broader communication ecosystem when deciding your Wiki strategy.


    Be specific in what tool you want people to use for what function, keep it 1:1 and stick to it. Each async communication tool like email, Slack etc. have their own advantages and disadvantages. Email, particularly if you are not sending it to a distribution list, is not searchable and will be accessible only within people's inboxes. When they leave the company it is gone. If it is something other people need to know, it is on colleagues to forward it on as a FYI. If you use Slack, please check out best practices like this and stick to them. My general rule of thumb is to use the tool for what is best at, and do not use any other features. For example, commenting in Google Docs is excellent but using Slack for back-and-forth is very lossy as contexts get mixed up in threads. Ideally, you have less number of tools, but very few organizations have the discipline and maturity for that.


  9. Make it stick with daily actions and showcasing success

    Spend time everyday to make it part of the operating culture. People adopt innovation when it solves problems for them. For example, when someone outside the team asks a question on the background context of a finance data pipeline as they have an urgent request from an external auditor, don't respond to that email with the information. Create a new Wiki page in the appropriate location, spend the time you would have spent typing the email, to create the document, and send the link to them. Continue the conversation as comment threads in the document if they need follow-up or drill down to more detail. After you complete the effort, you have a comprehensive document that can be reused for any number of purposes, including audit.


    You do not stop with one. Keep responding to emails with links, moving discussions to threads in documents and people start seeing the value. Engineers will notice how documenting new pipelines, as they build them, saves them a ton of time in back-and-forth emails. What is even better is that with enterprise AI search tools like Glean, all that content is now available for self-service!


    Similar to the phrase "You never want a serious crisis go to waste", don't let any success go unused. There is nothing like real examples of success to inspire adoption. Communicate the successes widely and repeatedly so people join the movement.


    This type of culture change takes time - usually months. Be patient. Be persistent.


  10. Start small, partner with others and work with the culture

    Don't overthink it. A documentation strategy can be a simple one-pager that you think through and write down guidelines, standards and everyday expectations. If you want to tackle more than your area in the company, you want to partner with your internal communication team to help drive the effort. Though it sounds simple, you will need to develop significant skills in leadership, communication, influencing people at all levels to make lasting change. You need to think about the existing culture of a place, why it came to be, what people generally like to do before you attempt any drastic changes.


Use the above ideas as a start. Experiment in your organizations. The techniques made a substantial difference in the effectiveness of the organizations I have led. People will thank you for improving their sanity and productivity.


Photo Courtesy:


Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page