Monday, 29 January 2018

The knowledge cycle as you have never seen it before

We are used to seeing pictures of knowledge cycles, but there is one cycle you never see, and it's very important.


You can find very many versions of the knowledge cycle, and they all seem to work the same way.

They start with "Create" or "Capture", and progress through "Store", "Share" etc until they get to "Use" or "Apply. Some have as few as 3 steps, some have 8 or more steps, and the 4-step basic has even made it into the Stock Photo collections. However all these cycles work in the same way, as all of them are "Push" cycles.

By "Push Cycle" I mean a cycle that is driven by knowledge supply, and describes how that supply of knowledge works through various stages until the knowledge is used again. It is a supply chain model, and people use the cycle to put in place roles and processes to move knowledge along the steps in the supply chain.

However Supply is only half the story, and you need to look at Demand as well.

The diagram shown here is a cycle driven by knowledge demand - a "Pull cycle" - and it works like this.

  • The cycle starts with a problem, and the identification of the need for knowledge to solve the problem (the "need to know")
  • The first step is to seek for that knowledge - to search online, and to ask others
  • Seeking/asking is followed by finding
  • However generally we tend to "over-find". Unless we are lucky, or there is a very good KM system, we fInd more than we need, so the next step is to review the results and select those which seem most relevant in the context of the problem.
  • This found knowledge then needs to be integrated into what is already known about the problem, and integrated into solutions, approaches, procedures and plans.
  • Finally the integrated knowledge needs to be applied to the problem.
So why do we never see this Pull cycle in diagram form?


  • Is it because Pull (Demand) is less important than Push (supply)? Surely not! Most people would see them as equally important, and there is an argument that Pull is in fact a bigger driver of knowledge transfer than Pull
  • Is it because the Pull cycle is less useful than the Push model?  Surely not! If we can generate knowledge pull, and a demand for knowledge, we can spark knowledge supply. 
  • Is it because the Pull cycle is more difficult to work with than the Push cycle? Maybe this is one reason. Asking is less of a natural behaviour and more of a cultural barrier than sharing, so sharing may be the easier option. But ignoring barriers wont help you in the long run.
  • Is it because the Pull cycle is less measurable? The Push cycle is often linked with the creation of documents, and this is something that can be measured. Leaving aside the question about whether anyone is looking for these documents, and whether these documents are useful when found, it is easier to measure the first couple of steps in a Push cycle than it is to measure similar steps in a Pull cycle. However you can also measure searches, and measure questions in a community forum.
  • Is it because people only want one diagram? Yes, probably, but we know that KM cannot be reduced to a single and simple diagram; it is far too nuanced for that.
  • Is it because everyone else draws their cycles this way? Probably yes. But just because everyone else does it, doesn't make it correct or sufficient.

There are many places where this Pull cycle can be applied very well.

  • Each individual uses this cycle when searching for knowledge. Most of the steps are done in the individuals head, but it may be useful to talk them through with a manager or colleague,. 
  • You can apply the cycle within a Peer Assist meeting, and the format of the meeting can follow the entire cycle from asking the questions, to reviewing the answers, to integrating them into the forward workplan.
  • You can apply it within a Community of Practice forum. Someone asking a question on the forum could  be asked to give feedback on the answers they received, the knowledge they selected from these answers, how they integrated this knowledge into their plans and (ideally) how it helped solve the problem. 
  • You can apply it as part of KM planning. A project team can identify their knowledge needs, conduct a search/ask activity, then get together to discuss how they will select and integrate the knowledge they have found. 
Being more conscious and explicit about the Pull cycle gives you more ways to create and stimulate knowledge demand in your organisation, and helps drive a Knowledge Seeking culture

Please do not focus only on the Push cycle for KM - its only half the story. Make sure your KM Framework incorporates the Pull cycle as well. 

4 comments:

jackvinson said...

I like it, Nick. As I read the post and looked at the cycle, I could see a lot of places where it "breaks". I find information and apply it but don't think about the larger applicability or even share what I did with others (until they "pull" it for their own purposes). Or, as you suggest, I get overwhelmed with so many options in the Find leg that it's almost as easy to make it up myself or pick a reasonable approach at random.

I suspect the real break is between Apply -> Problem. We see this as a linear process from when I have a problem until I solve it without a larger system need (demand?) to somehow integrate that solution into the larger system so that it is available the next time someone has a similar problem. This is one of the biggest challenges I have seen with KM approaches that don't fit into the regular way of operating in an organization. When it's these Push systems, it is so easy to consider that a side process to my main job of getting stuf done.

Nick Milton said...

Thanks Jack

Phil Levett said...

Thanks Nick, I always enjoy your posts - they consistently challenge my KM thinking.

I like to think of the cycle as a single combined push / pull cycle. I think it's what you're suggesting in the single Peer Assist session. At our company we have three main active participants in the actual K -transfer; Knowledge Donators (team A), Knowledge Receivers (team B) and Knowledge Transfer Facilitators (KTF). For a given Problem or Task the following should occur:

1) Team A does a given task by APPLYING their knowledge

2) K CAPTURE SESSION: Team A discusses and CAPTURES their experiences (learnings) and shares them with the KTF. So this is Team A Pushing K and the KTF Pulling K

3) KTF REVIEWS this K, ORGANISES it then CURATES it for SHARING.

4) K SEEK SESSION: Team B seek this K from the KTF. Often a member from an experienced team (Team A?) is also invited. So this is Team B Pulling K and KTF and Team A Pushing K

1) Team B then does the same task by APPLYING their new knowledge .... and the cycle starts again ...

THE K CAPTURE and SEEK sessions are tied into existing meeting schedules (are in the flow of standard work). They are facilitated and scheduled by the KTF at key milestones in the workflow (ie at the teachable moment).

So my question to you - is it more helpful to think of these as two separate Push and Pull cycles or as a single integrated Push-Pull cycle? If I try to manage them as two separate cycles I find it much harder to propose and implement viable solutions

Nick Milton said...

Hi Phil - you are looking at the activity from point of view of team activity, and teams should include both push and pull as part of their work activity (as in the Shell "Ask/Learn/Share" cycle).

If you look at the cycle form the point of view of knowledge passing through a cycle, then a push cycle is insufficient, and needs to be matched with a pull cycle.

Blog Archive