The Learning Organization And Why You Need One

Many people in management believe a learning organization is one of those things that are "nice to have" and will be gotten around to if there is time or money available.

Worse yet, many think the phrase represents just another useless fad and want nothing to do with such a concept.

I will assume the worse and try to sell you on the idea before telling you how to get there.

If the sum total of your company's expertise is no more than than that of a single employee —even if that employee is the genius founder— then your organization doesn't have much of a future. The world becomes increasingly complex as time advances and your firm needs to keep up.

So, what are good examples of learning organizations? Google, HP, Apple, Walmart, Microsoft are just a few of the companies that in one way or another may be characterized as learning organizations. Their balance sheets and market positioning attest to the value of the knowledge based shop. But enough of the preliminaries. Lets begin by defining a learning organization.

The beginning and end of a learning organization is the realization that knowledge is valuable asset that is as worthy of safeguarding as any other capital good. In fact, it is fair to say that knowledge is probably the most important asset, and I am not just talking about intellectual property or patents, which is more of a legal construct.

Having established that the valuation of organizational knowledge is the mark of a learning organization and the secret of its success, let us examine the ways you can make your organization a learning one. After much thought I realized that five action words pretty much sum up the attitudes of knowledge shop:
1) Document
2) Train
3) Audit
4) Preserve
5) Transition

Document
I have to be careful when I say "document" because many companies bury their employees in red tape and procedural straight jackets in the name of "documentation."

No, no, no! In fact, hell, no!

Documentation does not mean filling out forms in triplicate or writing thick hundred page reports with useless details that nobody will ever read. This is is actually a productivity killer.

The documentation that works is the kind that fits easily into the workflow and is not onerous. In fact the best way to get your developers documenting their work is to give them a say in which is the best way to document their work.

A easy exercise is to have developers perform a specific task which they document the best way they can think of. Then have them pass on their notes to another developer who is supposed to replicate the task using only the written instructions supplied by the first developer. Then ask the second developer to write suggestions to the first developer as to how he/she could improve the original set of instructions he or she got.

The best thing about this exercise is that after discussing the results you can put together a documentation guide that everyone will be motivated to use because they are sold on its usefulness. After that, it will be a trivial matter to decide what software to use if none has been chosen yet.

Train
In a true learning organization, all members should either train or be trained at least once every week. This should be written into the contract or the SOP.

Of course, this requirement should be flexible in every aspect. All forms of interactive knowledge transfer should be accommodated : group sessions, learning lunch pair ups, one-on-one cubicle tutorials, conference calls, any which way as long as it allows for note taking and questions.

Although blogs, wikis, instant messages and even tweets are good, they should not be allowed to take the place of actual interactive training.

Also, some amount of learning verification or testing should be worked into the process. This need not be too formal or extensive, but there needs to be a way to gauge what forms of training work best and which don't.

Audit
This is probably one of the most important and yet complex aspects of keeping an organization ahead in the age of information. In the NFL (National Football League) they call it "studying the game film."

Every release, major patch, platform change or post-deployment emergency should be audited internally. It is not only important to have a post-mortem when things go bad; there should be one when they go well too.

Retrospective analysis needs to become part of the workflow. This not only insures improved performance and better quality products; it also helps to solidify winning practices and avoid repeat failures. Think of this as insurance.

Retrospectives will not hold back the team if they are properly planned. Also, if one of the goals of the audit is to make the next release less painful, and the promise is delivered on, the team as a whole will gladly rally behind such reviews.


Preserve
If you have a winning horse, you insure it and feed it the best purina has to offer. You need to preserve proven practices and technologies that work for your team. If these are proprietary and have obvious commercial value, your legal department will probably make sure you do.

However, anything that can help your team and others in the future or around the organization should be preserved and/or disseminated. One way to do this is through a developer intranet knowledge base or wiki.

Care must be taken, however, to provide a proper way of cataloguing or searching this information. Also, it might be a good idea to separate or differentiate preliminary notes from actual finalized data.

Another very important way to preserve knowledge is through enterprise code libraries and APIs. However, no library or API should be allowed be catalogued without proper documentation and source code — this is extremely important especially in these litigious times.

Transition
A learning organization is dynamic and forward looking. This means that it is important to be always planning for the next stage or technology. Although I don't suggest that every new technological fad be followed, I don't think it is healthy for a shop to keep old code around for so long that it becomes too difficult or impractical to support — remember all that old code that needed updating when the year 2000 rolled around?

Be cutting edge, but not bleeding edge. Whenever possible, use the latest stable version of any technology you choose and plan for transition far in advance. Most importantly, go at a pace that suits your organizational needs not, your vendor's sales schedule.

Speaking of transition, technology moves are easier when design objectives are formulated in terms of functionality needed as opposed to technology to be used.

For example, instead of having as a requirement that says "the SAX API should be used for this task ", your stated objective should read something like "a serial access XML parser that is efficient with large data streams or documents should be used." If you do mention a specific implementation, do so parenthetically (as an example).

A learning organization stays ahead because it looks ahead without forgetting the lessons learned along the way. It harnesses (documents) and multiplies (trains) its experiential knowledge. It gets better with time because it maintains a proper feedback loop (audits). It performs optimally because it knows its strengths. It keeps around and sharpens (preserves) its best tools in order to reuse them for even bigger kills. And, lastly, it knows when to change horses (transfers).