An Approach to KM and Learning that Embraces Complexity

Several of my Knowledge Management colleagues have pointed me to George Siemens’ site Knowing Knowledge, and his upcoming self-published book of the same book (to be made available as free pdf’s as well). Much of what George says really resonates with my KM experience. His approach appreciates that many of the systems that KM is applied to are complex ones, and do not lend themselves to hierarchical, top-down, ‘designed’ and centralized solutions.

The four ‘stages’ to his approach are:

Analysis and validation of existing organizational structures and activities
Ecology and network design and creation
Adaptive learning and knowledge cycles to meet developing needs of organizations
System review (a “meta-analysis”) and strengthening to ensure an ongoing spiral of increased competence.

This approach is an evolutionary, iterative one rather than an imposed one. It responds to needs as they emerge rather than pre-supposing what they are. It demands a deep knowledge of the current state (which requires going out and talking to and observing people on the front lines to see what is really happening in their use of information and technology, and appreciating what they need and how they learn). It is a continuous process rather than a disjoint series of projects and ‘releases’. It is focused on developing competence and capacity, rather than just increasing the volume of information flows. For all of these reasons it is superior to the methodologies that have been Standard Operating Procedure in KM for more than a decade.

The illustration above from Siemens’ site exemplifies this approach’s adaptability. It is cyclical, two-way, and accommodates the needs of both managers and front-line staff. Here’s how Siemens’ explains it:

Change pressures arise from different sectors of a system. At times pressure is mandated from the top of a hierarchy; other times it forms from participants at a grass-roots level. Some changes are absorbed by the organization without significant impact on, or alterations of, existing methods. In other cases, change takes root. It then causes the formation of new methods within the organization.

Initially these methods will be informal, as those aspects of the organization nearest to the change begin to adapt. Overtime, the methods significantly impact the organization, resulting in the creation of new structures and new spaces (an alignment to the nature of change). These structures and spaces then create new affordancesóenabling the organization to change and adapt. The new affordances then create a new cycle of change pressures.

This, and not the way described in the corporate policy manual, is the way organizational change actually occurs. Change is a consensual process: If changes (e.g. the use of a new process or website) are mandated by management but don’t ‘make sense’ to those who actually have to effect the change, those people will find ways to not change, and will find workarounds that are effective in spite of the nonsensical mandates of management. Only when there is a consensus that change is valuable will it “take root”. The four change enablers in the graphic above actually operate almost like a pendulum: The demand for change (usually from customers, sometimes from management, sometimes from front-line workers’ learning and adaptation) precipitates ‘affordances’ (possibilities, ideas, alternatives and potentials) which, in turn, if they can achieve consensual traction, precipitate structural, systems, and infrastructure change within the organization, which, in turn, finally produce new methods and processes — different ways of doing things in the organization.

Those new methods and processes reciprocally create evolutionary structural, systems and infrastructure changes to accommodate them, and these ‘institutionalized’ changes reciprocally create new ‘affordances’ (possibilities), and the realization of the opportunity (i.e. the exciting possibility in the eyes of customers, workers and management) raised by these ‘affordances’ reciprocally create new pressure to change. Through several iterations (swings of the pendulum) all four elements converge on a new stasis, until new change pressures restart the change process.

In this article, Siemens elaborates further on how the traditional ‘presupposed problem and imposed solution’ approach to KM ‘simply’ does not work in complex environments, where problems and appropriate solutions constantly emerge and co-evolve. Here are some extracts:

Changes are still being interpreted through existing beliefs of how we should structure our organizations, and what it means to know and learn. When people first encounter distributed tools, the first attempt at implementation involves ìforcingî decentralized processes into centralized models. We then end up with LMS for learning, learning object repositories to manage our content, corporate lock-downs on instant messages, and district-wide bans on social networking tools…The desire for centralization is strong. These organizations want learners to access their sites for content/interaction/knowledge. Learners, on the other hand, already have their personal spaces (myspace, facebook, aggregators). They donít want to go to someone elseís program/site to experience content. They want your content in their space…

The desire to control and manage communities (the notion that control equates to better prospect of achieving intended outcomes was, as usual, evident) struck me as being a bit at odds with how things need to happen for online spaces to prosper…When we try and create Communities of Practice (CoPs) online, we take the same approach ñ come to our community. I think thatís the wrong approach. The community should come to the user.

Most individuals have started to create a scattered identity and presence. I have pieces of my thoughts scattered across numerous articles, website, podcasts, and presentations. I donít really want to join a CoP. I want the connection values of communities to be available to me in my own online space and presence…

We have a mindset of ìknowing before applicationî. We feel that new problems must be tamed by our previous experience. When we encounter a challenge, we visit our database of known solutions with the objective of applying a template solution on the problem. I find many organizations are not comfortable suspending judgment. The moment a problem takes an initial known shape, the solutions begin to flow… Applying solutions to problems is an order-creating attempt. This is, I think, a very natural process. We all engage in it..Perhaps, in a learning sense, part of the concern here is our views that order doesnít exist unless we enforce it…. Itís difficult to accept that order and meaning can emerge on its own (think chaos theory)…

Instead of trying to force these tools into organizational structures, let them exist for a while. See what happens. Donít decide the entire solution in advance. See the process as more of a dance than a structured enactment of a solution. React as the environment adjusts. Allow feedback to shape the final product. Let the process bring its own lessons before applying structured approaches. Perhaps a learning experience exists in the knowledge/information that emerges…Relaxing on control is vital for sustained knowledge growth, sharing, and dissemination.

The views that we must know before we can do, and that problems require solutions, can be limiting in certain instances (especially instances of high complexity or uncertainty ñ see Snowdenís knowledge ontology). Knowing often arises in the process of doing. Solutions are often contained within the problems themselves (not external, templated responses). And problems always morph as we begin to work on them.

You can appreciate that such an approach is enough to give both management and ‘project leaders’ apoplexy. Both groups want change initiatives to be controlled, and to have a clear beginning and end, a prescribed measure of ‘successful’ implementation, and closure when that measure is (or is not) achieved. Siemens’ approach is open-ended, continuous, and evolutionary. That’s why the evolution of the solution (and the simultaneous co-evolution of understanding of the ‘problem’) must be self-managed by the stakeholder group — they know enough and care enough to steward it through the lengthy and continuous evolutionary, emergent process (a process that is inefficient but very effective), long after the ‘design team’ and the ‘IT implementation team’ have lost patience with the changes.

For KM ‘solutions’ to be self-manageable, they must be very simple and intuitive (or, as Einstein put it, “as simple as possible but no simpler”.

So suppose you’re a Knowledge Director and you want to help the people in your organization use knowledge more effectively. What do you do? Here’s a few ideas of my own:

Conduct personal productivity improvement ‘cultural anthropology’ observation sessions with users. You’ll find out how they learn, and what they really need, not what they think they need (or management thinks they need). A lot of what they need will be highly individual, and you’ll probably find it doesn’t need a ‘solution’, just a bit of demonstration of what already exists that they don’t know about, plus some personal content management coaching. And as you observe more and more people you’ll start to see patterns of unmet collective information and technology needs.
Then, rather than designing solutions for these unmet collective needs, create the simplest possible framework for solutions to these unmet needs to evolve, empower the group that has indicated they need and care about the issue to experiment and iteratively change the tool or solution as their understanding of the need and its possible solutions evolves. It is possible that rather than stabilizing, the lightweight ‘framework solution’ will continue to evolve indefinitely, or the need may disappear as circumstances change. Only if the solution stabilizes and there is sufficient critical mass of users, content and technology to justify it, should the stabilized solution then be formally re-designed to make it more elegant, user-friendly, standards-compliant, efficient and powerful.
Focus on KM initiatives that enable sense-making (making content more valuable by providing better context), and peer-to-peer sharing, rather than the archiving and ‘broadcast’ dissemination of ‘available’ content. These are the applications that, in complex environments, users find most valuable. Most users are pretty clever at getting the content they need, and, as Siemens says, the last thing they want is to have to go to your site, no matter how elegantly designed, to get it — they want it accessible to or delivered to their site, space, or hard drive, their way, when they want it. If it’s hard to find or access, make it easy for them, and then let them do it. Otherwise, don’t fuss about the format or site architecture of ‘raw’ information content — you’ll get much further helping them make sense of it, and helping them send it peer-to-peer, than by creating elegant, beautifully designed websites to house it.
Likewise, rather than ‘creating’ communities of practice and elegant sites and tools to empower them, focus on peer-to-peer expertise finding and connectivity applications, and, once people with common interests and imperatives have found each other, provide them with the simplest and most flexible possible tool to self-manage that community. And again, only if the tool’s evolution stabilizes and there is sufficient critical mass of users, content and technology to justify it, should the stabilized solution then be formally re-designed to make it more elegant, user-friendly, standards-compliant, efficient and powerful.

I’ll be looking forward to the publishing of Knowing Knowledge (tomorrow) and will be writing further about it once the pdf’s are available.

In the meantime, what do you think of Siemens’ idea that KM is all about a “spiral of increased competence”? And what, beyond the ideas described above, could organizations do to precipitate such a spiral?