Do you really need a doc approval flow?

Have you caught yourself involved in an inefficient dynamic hindering a documentation project's agility? A chain of approvals, lengthy feedback, endless back and forth… Naturally, you want to make sure that the records are set straight, but we know that documentation, in general, is not a one-size-fits-all approach.

Before we dive into what's then a strategy that could change your knowledge base approach, let's see why documentation even needs to be approved and when this system got started.

The Origins of Wikis

The early concepts of knowledge base sharing can be traced back to the 1940s with Memex, a device that helped people with sharing documentation. And I mean physical documents. A few years later, in the 80s, Hypercard, a software developed by Apple, allowed users to create stacks of content and was the first time we saw the concept of non-linear knowledge sharing Fast-forward a few years later, and in 1993, Ward Cunningham launched the so-called "WikiWikiWeb," a space to facilitate collaborative discussions about programming patterns. The term "wiki" comes from the Hawaiian word "wiki wiki," which means "quick" or "fast," and was a nod to the concept of quick and accessible information and data.

Enough history now. Just think about this: Knowledge sharing has been a crucial step in developing technology and systems. Wikis have been a powerful tool that fostered collaboration, knowledge sharing, and growth and became one of the most influential concepts in today's data-driven environment. This page of history points to how the tension between keeping things dynamic, and locking and certifying  knowledge has always been present.

A closer example of our B2B arena is GitHub, renowned for its version control and collaborative software development tools, and which also incorporates a vital wiki component. GitHub's integrated wiki system plays a pivotal role. It lets developers create and update project documentation, collaborate with content, and link documentation and code repositories. This was critical for teams to be more comprehensive, up-to-date, and effective.

But, how can you rely on the veracity of this information?

To approve or not approve?

Following Github's example: This one uses branches or versions and pull requests to suggest changes and collaborate on content. This means that developers can spot an area of improvement in a wiki page, create a new branch, edit it, and then submit a pull request immediately. It's fast, collaborative, and, most importantly, accurate, since owners must review the changes before merging into the main wiki.

It's a pretty straightforward approval process, and as tech startups emerged, developer's workflows bled into other areas of team such as operations, and consecutievely how we create and maintain knowledge. This, also led to teams building knowledge base tools falling for the "status quo" of approval flows without really questioning wether non-engineering teams are familiar with this framework, if it's the most efficient way to manage knowledge and most importantly: how agile it is so that information is actually updated and therefore trustworthy for those consuming it,

And just like that that's terms like "commit," "pull request," and "merge" became part of the knowledge management universe.

Stability vs. Agility.

Now, let's stop for a moment and consider: Does the tried-and-true "approval process" for documentation hold sway in every team's context?

While GitHub's stronghold controls potential mistakes, it also imposes rules, that, while guaranteeing content's stability, it creates limitations. But, do teams need such a rigid warranty for all forms of knowledge sharing?

Indeed, processes like salary models and equity management, where leeway is scarce, this system fits the purpose. However, when we delve into the knowledge that's in your team's hold—handbooks, projects, meeting notes, internal FAQs and SOPs—the needs shift. Most of this information exists to help with daily queries and equip your team with practical solutions. It's all about fostering agility.

Think about it this way: Consider your sales playbook—a living organism that adapts to evolving market scenarios. Now, envision your projects, the very pulse of your organization. The need for dynamic and seamless updates isn't a luxury but a necessity. Considering this, does the traditional approval workflow still resonate and apply to all forms of knowledge?

Embracing Fluidity as a default: Slite’s Choice

At Slite, we champion a transformative mindset. We're committed to championing the cause of knowledge longevity, agility, and accessibility. This isn't just about embracing change; it's about redefining how we approach information in an era of distributed teams and boundaryless knowledge sharing.

Our stand is clear: Agility fuels growth. It's imperative that we optimize the flow of documentation to prevent stagnation and bottlenecks. The traditional rigidity of approval workflows, a relic of yesteryears, no longer fits the diverse demands of today.

This is where the concept of "verification" becomes paramount. Think of it as the modern-day sentinels that determine whether a document stands as a testament to trusted knowledge or requires refinement. In essence, our mission revolves around being the lifeblood of organizational knowledge. We're not merely advocating for change; we're building a revolution that hinges on trust through verification. It's about fusing the perpetually transforming nature of knowledge with the structural foundation of insight.

We are moving faster than ever, and your knowledge base must stay caught up. And fear not! Embracing fluidity doesn't mean you are giving up on precision, instead, look at it more as cultivating adaptability. What do you think? Are you in for a change in the knowledge-sharing paradigm?

‍