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

If you want motivated people in your organization, they have to be able to screw up the business

... at least temporarily.

There has been a lot written about the possible ways to get people to buy into the overarching goals, visions and target of their organization. More and more I get the impression that one important part is missing.

Of course it is important that everyone “knows the whole picture” and that ”vision is made clear to everyone” and so on.

The important thing that’s missing –at least in my opinion– is this litte thing called “making a difference.” People in an organization have to have the feeling that their actions actually do make a difference. When the effective difference of ones work being done well or not at all is effectively zilch –e.g. because after completing the work it still takes half a year before it has any effect on the outside world due to company procedure– the person delivering the work probably doesn’t experience much effectiveness.
In the long term this can lead to low self-efficacy which in turn increases the probability of disconnecting from daily life. In more pronounced cases this even can be a way to burnout and depression or inner resignation.

One of the biggest differences between environments where motivation is high and those where it isn't, in my experience, is how much effect peoples’ actions have on the outside world.

The Manifesto for Agile Software Development very clearly states

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

While the Essential Kanban Condensed says

Encourage acts of leadership at every level

and

Manage the work; let people self-organize around it.

To get this in one of those “agile transformations” I suggest that it is a key element to make sure that each individual contributors contribution actually does contribute. In a tangible way. After all: if my actions don’t have any real effect, why should I perform them at all?

On a related note: I think “agile transformations” is a misnomer. What you actually want to do is to make your business more flexible and move it away from the Tayloristic approach which doesn't fit the reality of today’s knowledge work and towards modern models like networked organizations, the leader-leader model or similar concepts.

till next time
  Michael Mahlberg