In the previous post, we identified two core problems in a typical knowledge management setup: composition and discovery. Now we can examine what qualities should an ideal setup possesses.
If you wanna tell people about your company in a factual one-directional way, you write a book. But that is not what this is about.
A big part of organization knowledge is an ever shifting Truth. The org charges, the market changes, therefore the Truth charges along with it.
To arrive at what's true takes collective effort in discussions and debates among the org components. To inform is simply the last step (perhaps even an arrogant one).
Without it, an org is a fragile entity that cannot survive a few top people being hit by a bus. (That some org prefer that mode of power structure is another story. This is a system discussion, not a political one.)
First let's examine the flow what we're talking about: data > information > knowledge > wisdom.
This series has been largely about the arrow between information and knowledge.
A typical first instinct to come up one single storage of information and write everything there. We've talked about that and Gitlab too knows wikis do not work.
Rather information are scattered across emails, chats (Slack et al), files storages (Dropbox et al), codes repos, task managers (Jira et al) and more.
These are raw data that are valuable on their own, but even more so if put together.
But most notably they exist without deliberate effort on anybody's part. This makes the act of collecting information frictionless.
Therefore composing organization knowledge is about connecting these information silos, relating individual pieces with each other.
Story time
Let's illustrate that with a scenario. A product was conceived, built, launched and received poor reception from customers. We wanna find out what happened and why.
Rather than in-person interviews, relying on verbal account and unreliable memories, we have pieces of documents, images, emails, IM chats, etc that are topically mapped to this project.
Together they form a timeline of what occured. You'll be able to perform time travel in this project. You may find out that the team was high spirited in the beginning based on the diagrams and ideas thrown around. You also pick out a pattern right before the shipping. Conversations in chats were tense, disagreements unresolved.
From code repository activity you found that engineers were put on crunch time in the office during weekends (from attendance system), work quality was poor (QA results), morale was down (sentiment analysis on chats). You even know who exactly made this crunch decision.
Post product lauch, you surprisingly found decent feedback in your customer support system. However these feedback somehow did not reach the product manager. The PM was busy fire-fighting an internal conflict caused by a rival PM. Soon the opportunity window closed, the product didn't iterate quick enough to respond to the market and died an undeserving death.
Open systems are critical
It's not hard to imagine something like this built. Governments with unlimited budget probably has such surveilance systems in place.
But this is not a discussion about the how-to. It is a highlight on how most knowledge silos do not allow for that.
WhatsApp groups for instance are popular. But they are closed by design, valueable information within are unlikely to be captured by an org-knowledge system imagined here.
Conversely email is crude but open. They are typically owned by the org such that everything is indexable.
If the customer support system in the story above is done entirely on Facebook Messenger, then reconstructing the history will probably be very costly.
This is about constructing an ecosystem of an org that allows such a knowledge device to be built. Built in such a way that does not require top-down enforcement of formal, tedious documentation process. Knowledge is gathered organically.
The building blocks requires that each information silo be made to be open (via API or protocol) for cross examination to be possible.
Next
Now that we've addressed how to put together knowledge, or at least creating the conditions that allow for it, the next challenge is discovery.
If your org manage to construct this imagined knowledge repository, it's likely gonna be so vast that information end up looking like noise.
Without a discovery mechanism to extract meaningful signals from the noise, knowledge remain hidden.
We shall examine some ideas on that next.
Originally published here