Should you centralize your documentation?

Should all company process documentation be centralized, live in one location, and in one tool? This is a question I receive on a regular basis and have put a lot of thought and research into, to best advise your specific needs.

In an ideal world, not only does a company have all of its processes documented, but they are all located in one place so people can easily find or edit what they are looking for.

As you know, we do not live in an ideal world, and when a company has ANY process documentation, it is often fragmented in a mix of locations such as several knowledge bases, Google Docs, project management tools, spreadsheets, personal drives, desktops, notes apps, and more.

To get the information you need to complete your work, you may have to spend an hour looking in a variety of places for answers and then book a meeting or message someone in real time to get the information that isn’t documented or findable in order to fill the gaps in your knowledge. 

Obviously, this is not efficient for anyone involved. As Spekit explains, information chaos means lost time; employees waste 3-11 hours a week on average searching for knowledge and communications. This chaos can also lead to the loss of company knowledge and duplication of each other’s work.

In a podcast with Mike Simmons, he spoke about how even small companies can struggle with non-centralized knowledge. He spoke about how he and his business partner and wife write notes differently, and these differences or methods make it difficult to sort, find, and share them with each other, especially non-digital notes like Post-its.

Centralizing process documentation into one location or tool is a worthy effort, though there are pros and cons to consider, which are discussed more clearly in the latter part of this article.

But first, don’t assume you have to take an “all or nothing” approach.

Even if you’re able to narrow down the information locations to 2 or 3 places, as long as they are places where people know where to look for which information they are seeking, that approach can still be better than your current chaos.

For example, housing the company-wide general processes in one location and storing specialized team processes in another location. Or having most of the process documentation in one location, but one team of super users/creators (such as developers) has their daily/team processes in their own knowledge base. 

This hybrid approach can work well if you’re linking those locations together inside the documents, and if the documents are all viewable and searchable to whoever needs them. This approach is much better than if everyone is navigating through 10 random possible locations looking for process knowledge (if they haven’t given up looking for information because of these frustrations!). This can also be a more manageable starting point when you’re rounding up various documents, videos, and other files across company systems to create combined documentation that thoroughly explains a process.

Niklas Begley at Doctave has a great article about how Google and Twitter improved their documentation culture. Though it focused on developer documentation and not internal company-wide process documentation, there are transferable lessons in these examples. Each of those case studies is discussed further below.

Google case study

The article recaps Riona MacNamara’s talk about her documentation improvement work at Google, where, in the before-state, surveys discovered that 48% of Google engineers cited bad documentation as the #1 productivity issue. Documentation (docs) was considered everybody’s problem, but nobody’s job, as there was no incentive to work on docs. And numerous past efforts to organize and improve the docs didn’t work. They were spread out in wikis, documents on different drives, or offline on whiteboards or physical notes. 

The previous top-down and bottom-up efforts didn't work since they were trying to impose the solutions upon the developers.

What worked was talking and listening to the developers, to discover their three main pain points: 

1. Docs don’t exist
2. If they did exist, they can’t be found (137,000 Google sites were indexed, but 90% of them had fewer than 1 visitor a month, with similar stats for the wiki.)
3. If docs exist, there is no way to know if they're trustworthy

As you can see, centralizing would possibly only solve the second problem on that list. So, don’t assume centralizing by itself will be the answer to all your documentation problems; make sure it is part of a comprehensive knowledge strategy or content strategy.

Part of Google’s solution was technical: building their knowledge base within the same tool the engineers use to write code (their “home base” in a way) so they didn’t have to leave that tool to write their documentation about their work. 

A big lesson from this case study is to not only pick a core platform, but also make the platform or knowledge location predictable to find. 

Twitter Case Study

The Doctave article also does a case study on Twitter’s improvements, from a talk by Simeon Franklin and Marko Gargenta. At the beginning of their project at Twitter, the docs were located all over the place (60K wikis, Google Docs, open source alongside code) with no rules or normalization of what docs should look like. There was no discipline to structure the docs for a better user experience. Developers were already committed to their own processes and tools, so, similar to Google, the solution was to make the documentation process as close to those existing processes as possible. 

This case was different since the writers of the documentation were often a team of technical writers and not the developers who were the users of the documentation, but the choice of the centralizing knowledge platform was optimized for the larger audience.  Even if it made it more difficult for the technical writers, a small team, to adopt the workflow, it was much easier for the thousands of developers to use the documentation when it was added into their own tools.

Another one of Google’s solutions related to centralizing processes was to have a minimum viable doc in the chosen main tool.

Within that document, the text points or links to all the related docs in the other tools that other teams use. 

An additional benefit of putting the documentation for developers inside the developer tool was that moving the home for the docs told the team that the docs are now their problem to fix. Docs didn’t seem like the responsibility of another team that owns the tool, like HR for an intranet, for example. Developers felt more ownership and ended up treating the docs like they treated code – there is no dead code, so there are no dead docs.

UX research repository case

Sarah Cunningham-Scharf and Emily DiLeo hosted a webinar about why research repositories fail. While this webinar was focused on UX (user experience) research documentation, there are lessons that can be applied to process documentation. 

People often say they can’t find information, and everything is a mess, so they need a repository (one place to store information). Emily counters this belief with: No, you need a knowledge management strategy. Simply having the tool won’t solve the problem.

They discuss the tension about the knowledge being accessible, visible, and organized. These are each different goals that should be thought about separately, and unfortunately, it’s unlikely you’ll find a tool that will solve all three problems at once. 

Visibility and accessibility may be more important to solve for because of the adoption hurdle of getting people to use the system, but this means you need to have documentation first.

She describes this 'after-some-documentation' state as being farther along in the research maturity journey, when you’re pushing it out to meet the users where they are. 

Emily answered a common question related to centralizing information, about how to meet people where they are and not duplicate a lot of your efforts, and a similar question about how to keep information in multiple locations accurate and synchronous. This is related to the debate over choosing one location for documentation or having separate knowledge repositories that are in each team’s “home base.” Unfortunately for many people's hopes and dreams, Emily said the answer is that you might have to double some of your efforts. (Though see the ‘minimum viable document’ strategy from Twitter above to help minimize the double work.) Emily compares this problem to the issue of an archivist who says to put all assets in a safe storage place, then take out a COPY to use and edit it. So you are touching it twice, but it may be a short-term pain and long-term gain (including version control of those copies).

Emily also mentioned that the company will likely change knowledge bases/repositories a lot, similar to how other software changes a lot at many companies. You want to be able to migrate tools easily. She also mentioned choosing tools that integrate with each other when possible, to minimize changing information manually in multiple locations.

Centralizing is discussed as being more possible in the future when a platform exists with an easy-to-use user interface like Spotify for all teams, though there still could be an adoption struggle to get people to use it. She says it is so hard to centralize, but if you can do it, it is super effective. So don’t give up hope!

Pros of centralizing knowledge:

• Everyone knows the general platform or URL to go to to find information
  • There is a clear starting point to answer their question or learn something
    • Knowledge Owl did an internal project on improving their knowledge base and found that 5 out of 7 people wanted to keep a single comprehensive knowledge base rather than separate/bespoke knowledge bases, for search/findability and ease of use. “People were worried that having multiple [locations] would make it even more confusing to know where to look and increase the amount of time it took to find the answers they needed.”
  • People will spend less time searching for information and more time doing impactful work 
  • There will be fewer tickets or questions submitted if they know where to find the info without asking you (so you spend less time answering repeated questions)

• Training on the usage of one tool is easier than multiple tools
  • Training users/viewers, creators, editors, or other roles in knowledge management
  • Easier training and usage lead to higher adoption of documentation practices

• Increased transparency of information and the impacts of shared or cross-functional processes
  • There will be fewer issues with process changes causing unintended upstream or downstream effects, if people can see the centralized information
  • Collaboration will be easier and more frequent if teams know who to contact when a related process changes
  • Categorizing or dividing shared company-wide info from team-only processes is still possible with good organizing rules and naming using a shared vocabulary
    • Example: At Remotish, we called a company-wide general category “ops for everyone” since “general” doesn’t sound very important. If it doesn’t sound important, people are not likely to use it. We were also an operations agency, so we were trying to encourage everyone to think of themselves as ops people. And then there was an "ops for ops" category, to separate that ops-specific team work from the general company-wide category. We also had subcategories within these, which were more descriptive, like “project management,” for example.
      
      
• It’s easier to ensure everything is up-to-date when it is in one place
  • Compared to siloed information on various drives and platforms you may not know exist. And information in people’s heads!
  • No need to duplicate process documentation updates in several locations
    • An example from a podcast interview I did for Travis Scott talked about how my last company streamlined and consolidated information by having some public, customer-facing articles in the knowledge base instead of siloed decks, website pages, and internal articles. This is a philosophy we were always trying to follow, so we didn't have to update the same information in multiple tools and documents for sales, for service, on the website, or for company email templates. Instead, it would live in the knowledge base documentation article/wiki, and any other place that needed to refer to it could use a link to that article, then we just have to update that one wiki instead of multiple places. The sales process in general may have been another example until we moved that to be even more transparent on our website. That is a case where the company’s external-facing website was better than the public knowledge base article, since the highest number of people searching for that info are the people visiting the website.
  • Another way to look at this benefit is having more control over ensuring the processes are correct, if they are all visible in one place (also version control)
    • An article from Synaptica states that “centralized content and processes allow for tighter control over knowledge retention through the establishment of internal policies and procedures tied to corporate content platforms. While such structures may make it more difficult to access across multiple devices (though not impossible), it ensures streamlined processes for controlling and retaining organizational knowledge.”

• There is a greater chance that knowledge will NOT be lost when employees leave, since you can see in the one system whether or not their job processes are documented (and keep them accountable for creating and updating this documentation, even if it’s just at the last minute before their departure)
  • The Synaptica article also states, “Lacking a centralized knowledge management program–including processes and procedures for structuring and managing content–leaves this knowledge inaccessible, varied in form and structure, and subject to sharing outside acceptable practices. The amount of knowledge that can be found locked away in laptops, distributed platforms like Google Drive, Dropbox, or Box, or other platforms not managed by the organization, is staggering. How does one even begin to address knowledge management policies such as knowledge transfer if the knowledge is inaccessible, or, more likely, completely unknown?”
    
    
• If no teams are currently using/creating documentation, centralizing may put everyone on equal footing, learning the same tools and workflows together

Cons of centralizing knowledge:

• Lower adoption or usage when some people may have to change habits, if the central location is a new tool or location for them, but it is not new for other people in the company
  • The people who have to change their habits and use a new tool may resent the people who do not need to change their habits
  • Context switching is hard, for people to go to a new tool or location when they are doing their work
  • If one team is using one tool/location and using it well, you may not want to disrupt that success by making them change tools
• It’s harder to integrate one central location into every ‘home base’ tool of every team, to deliver the documentation in their normal flow of work
• Findability of the exact info you’re looking for can be harder, with so much information to sift through in a central location
  • It can be difficult to organize and keep it organized so that the search function will serve up the correct information 
  • Knowledge Owl says poor curation or search is one reason a knowledge base isn’t adopted, when there’s ‘too much’ unstructured knowledge in one place. This means both search/organizing/navigation and also keeping the docs up-to-date are extra important, otherwise:
    • “This leads to all sorts of wikis and staff pages where people capture what they think is accurate information, or desperately try to find out who is responsible for what. Portals and repositories spring up everywhere, containing duplicated or complicated information.
      • 85% of employees said they turn to Google instead of using their employer’s knowledge management system (KMS). 
      • In contrast, 30% of employees regularly use their employer's KMS.
      • They find it much easier to fire off a quick email to colleagues or search on Google. Knowledge management initiatives fail. 
      • There’s no easy way to manage knowledge internally, but a robust understanding of your processes and the daily routine for your employees is essential.” 
• It can be difficult to give everyone the correct permissions for each role involved in documentation.
  • If people have to constantly request permission to view articles sent to them in links, after leading to a ‘You don’t have permissions’ screen,' for example, they are going to get frustrated and stop looking or asking for info
• People may be more scared that their process information, or the documentation they write, will be visible to the whole company to judge and comment on (related to confidence)
• People may think HR or another company-wide team is the only one responsible for updating and improving the documentation, whoever the centralized tool owner is

Benefits of using a few documentation locations (2 or 3, a hybrid approach):

The Synaptica article states, “Smart organizations may use a hybrid model. A hybrid model allows organizations to take advantage of decentralization, including ease of knowledge creation, access, distribution, and technology management. Similarly, the organization can also retain the characteristics of centralization, including access by all employees, structures such as taxonomies which reflect the organizational principles of the business, and a unified search across all content.”

Daniela Hauser, Business Process Improvement & Automation Specialist, said, “I think centralization is often misunderstood. People often think it means cramming everything into one tool, board, or spreadsheet. In reality, it means using a few core tools that seamlessly connect to manage the business. Centralizing documentation is always beneficial because the whole goal of sharing knowledge is to make it accessible to others. We achieve that by storing everything in one place. That could be the same tool the team uses for project management, for example, or a different one.”

Some benefits of this approach include:

• Better accessibility/visibility for teams for their specific daily processes
  • It may be easier to integrate documentation into their daily workflow or 'home-base' tools that their team already uses, compared to trying to get them all to adopt a new tool, or compared to getting one tool to integrate into many tools
    • Especially when different teams use different home bases, like engineers use Jira, but other people use the CRM or a friendlier project management tool day-to-day 
  • As a Spekit webinar and blog states, different teams have different content needs
• Adoption may be higher if communication is clear about what information to look for, and where 
  • Example: Company-wide processes in one place, their team process in one other place. 
  • Harv Nagra, Host of The Handbook Agency Ops Podcast and Ex-Agency Ops Leader, said, “I do think if it's particular to a specialist team only, then it is okay to link off elsewhere if it's a more ideal space for them – like your example with engineering teams (they also tend to love Confluence which I think is absolutely hideous and happy to steer clear from). But all company-wide resources, and anything other teams should be / need to be aware of, should be in the central knowledge base.” 
  • Knowledge Owl suggested maybe splitting out a “company handbook” and vision/mission type of information from the general process knowledge base, if anything should be split off at all
  • Linking articles to the other locations, as hyperlinks within the text of the document, can help with findability in different locations
    • See the Twitter case study above for the solution of having a minimum viable doc in one shared location
• People may feel more ‘ownership’ and responsibility for keeping docs complete and up-to-date if the docs are in a tool they feel they own
• It may be easier to customize the navigation and organization of the knowledge to each team’s needs using a few different tools or locations compared to trying to make a universal navigation for the whole company
• Searching may work better, and finding information may be easier when all the company information isn’t populating in the search results
  • It may be easier to organize the information architecture for each location
• Having 2 or 3 clearly communicated places to look for information is likely a lot better than the 10+ places and mysteries and calls and Slack questions and…. whatever the current state of the documentation mess is that you may be dealing with
  • You can also better audit what documentation exists and what needs to be created if the locations are narrowed down to 2 or 3 places, compared to more than 2 or 3 places
• If your company is starting documentation while you’re small (good for you!), centralizing may be easier to start, compared to a big company with 10K+ existing resources to wrangle. Then, besides breaking up articles into smaller articles for new roles as time goes on and the company grows, it might make more sense to store some specialized documentation in the tools those new and larger teams use daily, as the ratio of the types of roles creating and using documentation changes
• Companies that recently merged from acquisitions of other companies may take a phased approach to centralizing documentation, since likely the employees from different companies had different home bases, for better change management, while people still need the information to complete their daily work
  • Make it clear when to use a central knowledge base and when to still look at the company-specific knowledge base, and the timeline of changes for that

So, should you centralize? 

(I am considering making a quiz similar to this one to help answer this question, once I receive more feedback on the information in this article.)

Where to start centralizing:

Similar to many change initiatives, start with user research and auditing where your company and team is right now, the current state. Similar to the above cases of Twitter and Google, talk to people about their current behaviors and what their struggles and frustrations are related to documentation and completing processes. Evaluate the needs of the organization. Then create a knowledge management strategy, which may include some degree of centralizing information depending on your goals.

As Emily DiLeo said in her webinar, people assume her work is building knowledge bases, but that’s only maybe 20% of the work. 80% is people skills work. You have to figure out what you want and where you want to go first, before deciding on a central repository location (or two). You need to create a knowledge strategy first, which involves surveying the landscape:

1. Find current knowledge that exists, the current of knowledge that flows through the company (ask how do they find and access info now?) and current ‘systems’ they are using for it (that system may be ‘asking someone for it’) 
2. Find out who the stakeholders are for knowledge management and map the stakeholders (document them)
3. Have honest conversations with your team about who may be the champions and blockers of documentation
   1. Learn how to do strategic relationship building to make sure this documenting effort works. 
4. Find a way to package the insights up and deliver to stakeholders to show the value of the work right away
   1. Find out what matters to the business right now, go to your archive (location of documentation), and find everything related to that. Package the info up in a way that makes sense and deliver it to stakeholders

You may also want to refer to this blog related to the steps for creating a content strategy: evaluate, plan, design, build content, get feedback, communicate and train, make it a habit, keep it fresh, and drive adoption.

As I mentioned in a podcast with Travis Scott, if you’re just getting started building a knowledge base, don't get intimidated by HubSpot’s or other large established companies' knowledge bases. Keep in mind they've probably been building both the articles and the update/infrastructure processes for 10+ years and likely have a whole team of people working on it, compared to the more common scenario of one person trying to start documentation (or one person leading a centralizing effort) at their company. 

And if you have NO current documentation, you should work on creating or updating some of those articles first and get yourself and others in the habit of updating. Then you can more easily migrate current information into centralized locations later. As Emily DiLeo states in her webinar, you need to capture what the team is currently doing effectively first. The information they may not be writing down, their insights, and not just the steps of the processes. I call this the history or context, which is what any kind of AI tool can’t often capture by itself when recording you completing your process. Make sure this additional information is going somewhere in the documentation in a structured way.

Resources:

Cited in this article:

• Spekit webinar and blog on creating a content strategy
• Doctave blog on How Google, Twitter, and Spotify built a culture of documentation
• Conference talk from Riona MacNamara at Google about The Knowledge: Towards a Culture of Engineering Documentation
• Conference talk from Simeon Franklin and Marko Gargenta about TechDocs at Twitter: Creating the Culture of Documentation
• Great Question webinar from Sarah Cunningham-Scharf and Emily DiLeo on Why Most Research Repositories Fail (and How to Ensure Yours Succeeds)
• Knowledge Owl blog on: Get our docs in a row, part 2: Needs assessment results
• Synaptica article on Knowledge Management, Centralization, Decentralization
• Knowledge Owl blog about: Can a business ever have too much knowledge?

Additional:

• My blog on improving documentation systems
• Where should content live? Product Documentation vs. Knowledge Base (though product documentation can differ from internal process documentation, some shared principles apply)
• Building navigation for your doc site: 5 best practices
• Navigation tabs for different audiences

• Spekit blog on challenges with content documentation
• Guru blog on change management for knowledge centralization
• Juno Journey blog on knowledge centralization
• PHPKB blog on Centralized Knowledge Repository - Its Importance, Benefits, Implementation, and Best Practices
• Inclusion Cloud blog on how the centralization of knowledge helps AI agents search it

• Harvard Business Review article about information overload, with solutions at the end related to revamping their intranet/knowledge base
• Arthur De Kimpe writes about Rethinking Your Documentation So That People Actually Read It, including platform migration advice
• Tim Jordan writes about how to tackle a major knowledge base revamp

Contribute

You can reply to the LinkedIn post or email me with any insights on centralizing vs not centralizing, or when to centralize information, or related topics or questions you’d like to see added to this information. 

If you'd like to discuss this topic one-on-one with me and with peers, consider enrolling in the live workshop related to documentation systems, or the full course on documentation which also includes that topic.