Share it, don't just store it

Locked awayI stumbled upon this month-old post from Cory Banks that just strikes a major chord with me.  He says that Repositories are for sharing, not storing.

A recent thread on caught my eye. The problem of getting people to read documents got me thinking about some of the situations we are currently dealing with and I felt the urge to share.

Cory's post is a couple extracts from the discussion he mentions, but I really like the idea expressed in the title of his piece.  All those "knowledge repositories" out there are no good if people can't find or use the knowledge in them.  The whole point is knowledge sharing right?

And knowledge sharing isn't merely writing a document and assuming someone will read it.  Look at the vast majority of bloggers.  They write their articles, sure.  But then they publicize by producing a web feed and letting the world know there is an update (most blog software does this without the owners even knowing).  Many bloggers also categorize and tag their posts, so that they might show up on search engines and aggregators.  Some bloggers re-post links to their blogs on their favorite social networking site, so that their friends might see the article and read or forward the link along.  All these actions are after the fact of writing the article: it's all about seeking to share the ideas they've dropped into the article. 

Why don't we think of things the same way in enterprise knowledge repositories.  It has to be the responsibility of the people who create the materials to create useful titles, add tags and other relevant metadata to the materials.  And the software had better make it easy to email or post links to the documents to colleagues or to the intranet in general.  And, since this is enterprise we are discussing, it had better be easy to find the owner / authors of the materials, so any questions can be directed to the right people.  Our knowledge repositories allow for all these things, right?

I wonder how this same idea might connect to all the other kinds of stuff storage mechanisms we have in businesses today.  Is the storage because stuff needs to go somewhere (records retention), because it's paper and books (libraries and records retention rooms), or because we need to put it somewhere between creation and use (databases, document management, etc.)?  In all these cases the stuff needs to be found, but I think the reasoning and thinking behind the "find" action is very different.  With knowledge sharing and the old KM tale about "If HP only knew what HP knows," the job can't end with the act of creation.

[Photo: "Locked away" by PurpleGecko]

9 Comment(s)

Nick Milton said:

Hi Jack
Very true - findability is a key issue, which I explored in this blog post

However there is one more issue, which is that even with the most findable knowledge, nobody will find it if they don't look for it. Thre needs to be an equal emphasis on knowledge seeking, to that on knowledge finding.

Good stuff, Nick. I completely agree with the idea of findability, the new element to me was this idea that it's also the responsibility of the people who create stuff to make it findable too - not just the responsibility of the software you happen to be using. Maybe it was just the wording.

Really, of course, it is the whole system in which you are operating. People who create knowledge have to seek out prior art (both internally and externally), and they have to make it as available as possible. And those who seek need to have the tools and skills to go out and find things. More importantly, they need to have the inclination to go seek.

Good morning Jack,

Incentives and relationships are key to information sharing.

People happily share their expertise semi-anonymously in online forums with peers - they enjoy the social benefits, sense of community, and the non-threatening atmosphere. But as Dan Ariely, author of Predictably Irrational, pointed out there is a difference between social norms and business norms.

In the context of business, we behave differently and different rules apply. Employees are hesitant to share insight internally for a variety of reasons. Many feel the information might make them less valuable to their employer and more easily replaced. Others ask why they should bother and what is in it for them. Others still feel they are competing with fellow employees and contractors.

Like their bosses, they confuse the engine parts (their mind's knowledge) and the fuel (information). They fail to understand that the fuel is, by itself, without value. Fuel's value comes from its contribution to the host engine, and the way it is processed and used by the engine components to generate power (i.e. results, especially favorable outcomes).

On the relationship side...employees need to understand that sharing information is ok in organizations that recognize their value as unique value-producing components. And employers need to view information repositories as fuel tanks from which their employees generate power/value. Carelessly swapping, retiring or scrapping engine parts without fully understanding their contribution to power/value generation is a recipe for disaster. Select the best parts, maintain and respect them and they'll not only get you to the finish line, they'll help you win the race.

On the incentive side...what better incentives than performance- and outcome-based rewards tailored to the unique qualities and needs of individual employees? Employees who contribute by way of information sharing act like organizational turbochargers. A portion of their output is fed back into the engine to generate even greater power. Encourage employees to perform like turbochargers and provide the regular maintenance that enables them to operate at peak performance.

Melinda Catapano said:

Thanks for starting this discussion, Jack. And Joseph - I love your analogy to engine parts and fuel. You really got me thinking! Perhaps I can use this in our new ERMS training to help employees understand their responsibilities: repository documents are like fuel, which we want to share with other employees, who are like cars on the organization's highways? Great stuff!

Hi Melinda, and thanks.

You could use cars and highways, but I think employees/managers might find it easier to think of your organization as one large value/power generating engine, in which each of the employees is a critical component that contributes to the engine's ability to use fuel (information) to generate power (value).

It is critical that management also understand that not all employees are created equal..despite the fact that managers often see employees as easily swapped/retired just because the company maintains a "knowledgebase". The ability of each employee to help create value/power from information/fuel differs. And without a reliable and plentiful supply of quality fuel (all those documents, databases and metadata), the organization's performance suffers.

Ivan Webb said:

This reminds of the common job description that we had for literally everyone (staff, students, parents, visitors...) in my last school (now "retired").
- Know what is happening
- Work with others to improve what is happening
- Make it easier for the next person to do well

This raises the questions
- What are the obstacles to people using the data well?
- How might we address these constraints?

It has been my experience that every additional click, password and search significantly reduces people's use of data stored in any repository.

Thus there is a need to engage in an ongoing conversation with users. Not just about the data they need, but also about
- how and when and why they are using it and thus
- how it can be best presented for their use

In projects like these it quickly becomes clear that no-one know the answers to these questions before they are asked.

Ivan Webb

Jack Vinson Author Profile Page said:

Wow. Thanks all for this great set of thoughts. Inspiring.

And, Ivan, my current job description ends with something along the lines of "Do whatever is needed to ensure success." That makes the formal job description pretty unnecessary.

Atle Iversen Author Profile Page said:

Most companies probably need two types of repositories; one for storing (legal/process/records management reasons etc) and one for sharing ?

Combining them will only lead to information overload - a lot of useless (for employees) documents mixed in among the few really useful nuggets of knowledge that the employees need.

The key is, of course, findability, as both you and Nick point out. And this requires more work from people sharing their knowledge, as they have to tag and add meta-descriptions etc to make it easier to find. I guess the "Personal, Small and Big KM" separation is useful here ?

Comment to Joseph:
I agree with your comment, but please don't use the fuel and engine analogy.

Giving half of your "fuel" to others means that you have less, but sharing knowledge does *not* reduce the amount of knowledge you have.

However, you may not be as "valuable" anymore as someone else also knows what you know. In an organization where sharing is not properly appreciated, this means that your "value" is reduced as they are less dependent on you. I therefore believe that to encourage the sharing of knowledge the company (and managers) need to communicate clearly (and mean it!!) that sharing is *more* valuable than the knowledge itself...but this seems to be the hardest part....

Great post, great discussion

John Tropea said:

Atle agree the top down message needs to be - "sharing is *more* valuable than the knowledge itself"

People hoard as in current organisational design settings we reward individual action, and as said here the fear in being replaceable. But when we think about it the more I share, the more I become known. If I get kudos for sharing one thing, the org can't wait till I share the next. This doesn't mean recipients are as skillful as doesn't necessarily mean they have the know-how to come up with new things. But even if they do, there is also the other element that I have a reputation, I have passion, I'm connected, I'm approachable...people like nice people working for them.

As I said in my post

"When you share you are not just a dynamic performer, but you are also helping everyone else to be one as well, and that is reason for the company to actually hold on to you"

Blogging and microblogging platforms really hone in on the "What's in it for me?" factor as they are engaging, people have an audience, build a reputation. I don't know about you, but first thing I do in the morning when I look at my blog, facebook and twitter is to look if I have any comments or replies...if I'm representative of most people that tells us...we anticipate and are excited to see if people react to our sharing as we are social creatures and find this activity engaging

In the end we don't look at it as sharing, it's much bigger than that, we look at it as engagement. And the act of engagement over many interactiobs is how we built trust, which cascades into sharing as a by product.
eg. my wife doesn't consider that she is sharing on Facebook, it's more about connection and awareness (engagement) and how much we like doing that

@nickmilton I like your post, and I think this is a design thing

At work our document management system has a free module that is yet to be approved that allows for a comment stream on documents that are uploaded...I call this conversational metadata.
It's basically microblogging with activity streams.

eg. you add a document or a new version
- if I follow you an auto-post appears in my activity stream (I'm aware of this without you explicitly telling me)...I agree with @jackvinson with the onus on the owner, but here's an example of the onus on the receiver to follow that person...but really it's the system doing the work based on auto-posting people's gestures

- I can comment on that post, and what ensues is a conversation about the document...all the while others are watching or chiming in

This is awareness in the "flow", which is different to awareness of "stocks"

I think awareness of stocks is what @jackvinson is referring to where the author self-indexes the content...that way it helps seekers. But @jackvinson also covers awareness of flow where the blogger has a feed, posts their links to Twitter, blog post footers have share features, etc..

But at the same time seekers can use the microblogging network or a group space like a CoP and ask people questions. One of the biggest uses of our CoPs is:

Q: does anyone know where I can find, or do we have a spec on such and such
A: yes, we used one on a project last year, but our context can find it here

- this person may or may have not stored this spec in a repository, but if they did would people look for it, what is important is that you can ask for it

...when this person leaves the company....a forum post will tell us about this spec, but what if this forum post didn't happen, in this respect we would not know about this spec. So yes I think it's good we have on-demand/in-context sharing, but equally good is for people to proactively store stuff (the latter is the hardest bit)...and then telling people on top of it (not everyone is a blogger...but everyone can be a microblogger)

Flow - radar of awareness as it happens
Stocks - seekers asking or browse/search

Sure we can use email to signal to others, but while this is happening it's invisible to the rest...that's why I like the openness of platforms like Twitter over email for's just so much more amplifying

BTW - Not sure if I like fuel and engine metaphors when talking about people; with social computing I see it more organic or an ecosystem, where an object can be both a fuel and an engine.
eg. a blog post can sometimes be seen like a document (information-fuel), but it can also be conversation (value-engine) about a document, and perhaps that conversation can spore other documents, and other conversations

Leave a comment

Previous entry: So, how do you improve conference calls?

Next entry: The Heart of Change

Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn