When I read, I have a tendency to mark up my books with notes and to write down key passages and thoughts in a notebook (and this blog on occassion). In the notebook, I try to draw connections – in time, space, etc – because everything is, after all, connected in some way. I’ve recently been thinking about making some sort of database that would allow me to collect and relate all this information in an easy to retrieve and browse format. Luckily for me, someone else has already done something similar and made it available for all to see and use.
I learned of the Timeline Index from the post Timeline Index – People, Periods, Places, Events from Jim McGee. Much like my notebook, the index is a collection of links to sites about various subjects. The advantage of being on the web, of course, is that each entry can be categorized – in this case using the 5 W’s of who, what, when, where, which – and searched. The index is collaborative and depends not on some central figure but everyone who uses it to keep it updated and interesting.
I can hardly wait to dig into the site and see what they’ve got and what still needs to be added. I’m also going to add it to the list of sites I recommend to kids for doing school research.
In my last post I put down some thoughts about how blogs could be used as a form of tacit knowledge capture since it documents the thought process in the development of many different ideas, many times in pursuit of a “finished” product. Catching up (who am I kidding? I’ll never catch up) with my reading this evening I found Knowledge Jolt with Jack: Your blogging obligaton, which in turn pointed to Mospos: Blogging to become legal obligation?.
A couple of key quotes:
the starting point is that «knowledge belongs to the company». If I understood correctly, this means that a recruited employee should specifically state the different aspects of the experience he brings to the company within the knowledge domain he was hired for and then relinquish all rights to the knowledge developed thereafter in this domain, whether explicit or not (a.k.a. «background information» in joint ventures). If the employee happens to leave the company to work elsewhere, he can be exposed to legal action if he is found to be using any form of knowledge acquired in the previous company, whether explicit or tacit.
On a practical note, this has quite simple implications. Let’s ask ourselves what happens when an employee leaves a company to develop his ideas in another one. Well, if it is proven that he withheld information from his former employer to do that, he should be sued. But if he had this great idea and shared it in the company, but nobody cared (happens all the time!), is there a good reason why he shouldn’t be allowed to leave and maybe start a company with this idea?
In the end, it might well be that the best interest for both parties is to have every employee keep written logs –one per community- of everything they do. The employee can then use the blog records to prove that he did not withhold information from the company. If he cannot, well, too bad for him.
Aside from this one aspect of knowledge in companies, the post has analysis of the whole concept of who owns knowledge in a company, how/if it should be controlled, etc. The implications of this specific case is unique (for now) to France, but is good food for thought for anyone interested in these questions.
From the wikipedia definition of tacit knowledge is this short paragraph:
By definition, tacit knowledge is not easily shared. One of Polanyi’s famous aphorisms is: “We know much more than we can tell.” Tacit knowledge consists often of habits and culture that we do not recognize in ourselves.
In a brief conversation through blog posts and comments, Lilia Efimova and Richard MacManus talk about the “unfinished” feeling that goes with blogs and how it affects work on “finished” products. A couple of quotes:
From Lilia in What if…:
Although often I escape into blogging when I don’t feel like working on a larger, “finished” pieces, I guess I really need those pressures to produce something finished to take an extra effort for synthesising “always unfinished” into something “finished”.
From Richard in Weblog Reading And Writing: Always Unfinished?:
Having written an article for Digital Web Magazine (and I must get around to writing another one), I can confirm it takes at least a couple of weeks to ‘craft’. Whereas with my weblog, although generally I write carefully crafted long-form posts, it’s still of-the-moment and a lot of times it’s an ongoing theme I’m exploring (ie it’s not “finished”).
As both Lilia and Richard imply, the writing (and reading) of blogs is a way to collect and organize (and reassess as needed) various thoughts and ideas as they are formed and processed. Sounds like tacit knowledge to me.
One of the biggest challenges I’ve come across in how best to use technology is the process of developing documents that have many authors, or collaborative authoring. A typical process goes something like this:
- Someone is assigned as configuration manager
- The initial draft is created and sent, usually via e-mail, to all reviewers/contributors
- Comments/changes are sent back to cm to be incorporated
- loop until complete
Not only is a cumbersome process, it quickly fills up e-mail inboxes as several versions of a document go flying back and forth.
As its title suggests, Michael Angeles’ article Using a Wiki for Documentation and Collaborative Authoring looks at how wiki software can be used to make this process more efficient and effective.
I had my first experience using a Wiki for project documentation when I participated in the formation of a professional association. The group was geographically dispersed, and after our first face-to-face meetings, it became clear that we needed a platform to supplement our email meetings and conference calls. We quickly set up a Wiki, and it became everything from the white board to capture our post-meeting ideas to the documentation repository for our initiatives. Wikis proved to provide a lot of publishing functionality to this organization with little financial investment. Since we had limited financial funds as a start up, this seemed the perfect fit for our needs.
The remainder of the article provides essentially a case study of how wiki was used in support of a specific project. Well worth the read.
Can you really know something if you didn’t learn it?
I was sitting in a meeting the other day in which a group of engineers was giving a presentation on some analysis of a system they are working on. The slides were well done and had a lot of “information” on them. As I was looking at the slides later, I realized that I could easily digest and retain the explicit knowledge that the slides represented, but that I had absolutely no idea of the tacit knowledge that was created by the engineers in the process of preparing this presentation.
I’ve long considered explicit knowledge to be not much more than information (at least from an individual perspective). The content of these slides is, to me, information that I can use to further develop my own knowledge of the content. If you were to ask me a question about the system, I could tell you the information that was on the slides. I might, if I had good notes and recall that day, be able to tell you a little bit about how the information was derived.
I would “know” the information, but would I really know anything “about” the information?
Some similar thoughts from Frank Patrick in It’s More Than the Numbers:
It’s the logical analysis of situations — the understanding of cause-and-effect that results in what the numbers are saying — that lead to “improved business decisions.” … What helps round out the sufficiency is the application of logical analysis to provide a context for the quantitative analysis. You can’t run a business “by the numbers” alone.
Saw Practical Wisdom this morning. Denham discusses the new book Deep Smarts in which the authors “explore the cognitive and competency practices that enable swift decisions, explain master level experience and examine ways to transfer these exceptional skills.”
A couple of articles discussing the limitation of Learning Management Systems (LMS):
Learning Management Systems: The wrong place to start elearning (elearnspace)
The real issue is that LMS vendors are attempting to position their tools as the center-point for elearning – removing control from the system’s end-users: instructors and learners. Unfortunately, beginning learning with an LMS is often a matter of wrong tool for wrong purposes (which results in failed elearning implementations, ineffective learning, and unnecessary expenses). Implementing an LMS as part of a holistic learning environment gives the end user flexibility and control to move in various paths (driven by learning needs, not by LMS design).
E-Learning Adventures Beyond the LMS (Parkin’s Lot)
Learning software vendors still doggedly pursue their vision of reusable learning objects that integrate via a central standards-conformant LMS. Meanwhile, trainers who really want to encourage experience-sharing and dynamic learner-created content are scrambling to understand blogging, RSS, and peer-to-peer networks.
Much the same thing I remember from the “early days” of the KM craze, when it was all about software this, technology that – technology for technology’s sake. Technology for its own sake is meaningless. It is how people can use the technology to connect to others that makes them valuable.
For the past couple of months I’ve watched my son, Ian, prepare for his first trampoline meet, coming up this weekend. It is an amazing example of the use of negative feedback in the learning process. You try something, figure out what you did wrong, try it again, until you’re happy with how it feels. Of course, you have to do this for each of the 6 or 7 elements of the whole routine and then you have to put all the elements together into a complete package. Pretty much the learning process for anything.
I’ve been thinking a lot about noise (in the information/communications sense) lately, and it struck me that what Ian is doing in his training is a deliberate process of noise reduction. Anything that happens when he is trying a specific element, or the whole routine, that isn’t part of that element or routine is noise. By reducing, and hopefully eliminating, this noise, he is getting to the point of pure “signal.”
At that point, it is tempting to claim success. But what would be the fun in that? Once you’ve eliminated all the noise from one routine it is time to add in some more noise and notch things up a level. Then you go through the whole process again.
The same is true in any individual or organizational endeavor. This is, in fact, the whole basis of innovation: take what you already know, add some noise to the mix, and reduce the noise so you get not back to where you started but to a whole new level.
Knowledge management is often talked about as the management of knowledge that already exists. I think that noise management may be a key part of creating that knowledge.