Sunday, December 23, 2018

How to capture knowledge

Very simple: Don't!

In my Opinion you shouldn't capture knowledge – you should set it free!

Why are so many people keen on capturing knowledge? I spend most of my time trying to set knowledge free. That’s what my clients pay me to do.

To take an example (once again) from software development: what's the use in writing a local guide to unit testing, when there are literally thousands of well-crafted pages on that topic out there?

This is somewhat related to the question of whether you try to control circumstances or build capabilities – having a few specialists make the organization as a whole more fragile. And documentation doesn't create value when it is written – documentation creates value when it is read and understood.

There is this dialogue I witness every now an then which illustrates one of the bigger problems with the idea that information has to be captured - it goes something like this:

"Spreading knowledge" 1985

  • A: Why didn't you use the new approach?
  • B: There is a new approach? I didn't know!
  • A: But there's an article on it in the newest loose leaf update to the SOP (standard operating procedures)!
  • B: *rolls eyes*

"Spreading knowledge" 2016

  • A: Why didn't you use the new approach?
  • B: There is a new approach? I didn't know!
  • A: But I wrote an article about it on the wiki!
  • B: *rolls eyes*

Back in the days putting three ring binders with standard operation procedures in all offices and sending out monthly updates didn't do the trick of disseminating information.

And while I really love what Ward did for the empowerment of the people trying to collaborate on making information accessible, having a wiki alone doesn't help in the distribution of information either.

Does documenting really help? Especially documenting the result of a lengthy thought process? Do we understand the nature of relativity, just because we “know” that E = mc² ?

Sometimes I see people pondering over the creation of some documentation for hours. If it takes hours for people to create the documentation, then how much time should one allocate for people who read this documentation to understand it’s authors intents? About the same time it took to write it down? Half the time? A quarter of it?
Or maybe it takes twice the time of writing the documentation, because really understanding it requires at least a modicum of application.

So here’s my suggestion:

Each time something important is published in your project (e.g. on the Wiki) consider the time it would take people to understand it and – gasp – hold a session of that time and explain it to them. Keep the article. Keep it as a reference and make sure it is accurate, but don't expect people to know something just because it has been written.

In my mind I hear you argue: “But we can't afford that much time!” – Well, if you can't afford that much time, then how can you expect people to have taken it?

till next time
  Michael Mahlberg

No comments: