How collaboration can simplify

Collaboration adds simplicity in a complicated world. 

Simplifying through collaboration is the topic of a Ted talk by Yves Morieux, embedded below, in which he gives us 6 rules to simplify work. Watch the talk to get the context, but here are his 6 rules (with more explanation here)

  1. Ensure people in the organisation full understand what others really do. 
  2. Look for cooperation – reinforce managers as integrators, by removing layers so that managers are closer to the real work. 
  3. Empower everybody to use their judgement and intelligence. 
  4. Create tight feedback loops that expose people to the consequences of their actions. 
  5. Increase reciprocity, by removing the buffers that make us self-sufficient.
  6. Reward those who cooperate and blame or sanction those who don’t cooperate. 

Do these sound familiar? Rules 1,2,4,5 and 6 are all components of Knowledge Management, and Knowledge Management is needed to support Rule 3. Yves is not reinventing KM, but showing how a knowledge enabled, connected and collaborative organisation is like an adaptive nervous system rather than a rigid skeleton of roles and structures.

Yves explains that as these 6 rules are brought into play, organisations begin to be able to manage complexity not through adding more and more complex structures and requirements, but by allowing people to take ownership of issues and sort them out together, rather than passing them on to someone else.

Yves finishes his talk by explaining how CEOs can help support the 6 rules of complexity, and gives us this story, which should resonate with all KM practitioners

The CEO of The Lego Group, Jorgen Vig Knudstorp, says, blame is not for failure, it is for failing to help or ask for help. This changes everything. Suddenly it becomes in my interest to be transparent on my real weaknesses, because I know I will not be blamed if I fail, but if I fail to help or ask for help.

This is very similar to Elon Musk’s email to his staff. Both give the vision of an organisation empowered and obliged to seek knowledge from wherever it may be found. And this is the basis of Knowledge Management. 

View Original Source ( Here.

The Asker/Helper culture – why these are the core behaviours of KM

A recent McKinsey article, if you read it carefully, suggests that the core KM behaviours for group effectiveness are Asking and Responding.

Ask (always)The McKinsey article entitled Givers take all: The hidden dimension of corporate culture is a really interesting article, describing a study by Harvard psychologists of the US intelligence system in order to determine what makes intelligence units effective. By surveying, interviewing, and observing hundreds of analysts across 64 different intelligence groups, the researchers ranked those units from best to worst, and looked at what made the best ones so good.

Conclusions of the study are as follows:

  • The single strongest predictor of group effectiveness was the amount of help that analysts gave to each other.
  • Across these diverse contexts, organizations benefit when employees freely contribute their knowledge and skills to others (what McKinsey refers to as a Giver culture, where knowledge is freely shared, in contrast to a Taker culture, where it isn’t)
  • Giver cultures depend on employees making requests; otherwise, it’s difficult to figure out who needs help and what to give. In fact, studies reviewed by psychologists Stella Anderson and Larry Williams show that direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations.

So in fact the single strongest predictor of group effectiveness is the amount of “asking for help” that happens, and the Giving/Helping response. So it would be more accurate to talk about an Asker/Helper culture rather than a Giver culture.

It is possible to develop an Asker/Helper culture – the article talks about an exercise called a Reciprocity Ring, which is a face to face version of the Question-driven communities of practice we see operating so successfully as part of mature knowledge management programs. Peer Assist is the archetypal Asker process, which always generates a Giver response. Many of the standard Knowledge Management interventions act as culture change agents in their own right to promote the behaviours of asking and of giving.

So if you are interested in creating the KM culture which is “the single strongest predictor of group effectiveness” – remember that knowledge sharing is 75% to 90% of the time a response to Asking.

Aim for the Asker/Helper culture (as I suggest in this video).

View Original Source ( Here.

Feedback loops in the Knowledge cycle

Last week I described a “Pull cycle” for knowledge – let’s now look at the feedback loops in that cycle.

You can find description of the cycle here. This is a cycle based on knowledge demand (unlike the supply-side cycles you normally see) and includes the following steps;

  • 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.
In the picture above, I have added the monitoring and feedback loops to each step, which work like this:
  • After the behaviour of asking/seeking, you feedback firstly whether there was any asking/seeking (so the organisation can track the behaviours of knowledge seeking) and you monitor and feed back the topics that people are asking about or searching for. You can for example analyse questions in a community of practice, or queries to a helpdesk, and you can analyse search terms from the corporate search engine logs. These will give you some ideas of the knowledge needs in the organisation, which knowledge supply has to match. 
  • After the finding step you feedback whether  you found the knowledge you needed, or not. This feedback will help identify gaps in the knowledge base where the knowledge needs are not being met, and can trigger the creation of new knowledge assets of articles.
  • After the review step you feed back whether the knowledge was relevant or not. In reality this feedback will be merged with the previous step. 
  • After the Integration step you feed back on the quality of the knowledge you found. This feedback will identify knowledge assets or knowledge articles which need to be updated.
  • After the Apply step, you feed back whether the knowledge was actually applied. This will help identify the most applicable and useful knowledge assets and articles. 
  • Finally, after the problem solution step, you feed back how much difference the knowledge made, and how much value was realised through problem solution. This allows you to track the value of the entire pull cycle and the entire knowledge management framework
Many of these monitoring and feedback loops are well developed in the customer-focused KM approaches such as KCS (Knowledge Centred Support), but any KM approach can apply these as part of their own KM metrics framework.
It is through the feedback associated with the steps that you can tell whether KM is actually working.

    View Original Source ( Here.

    "You are obligated to ask" – Elon Musk’s email

    Even in the most progressive organisations, sometimes the boss needs to drive a “culture of asking.” Here is how Elon Musk did it.

    Image from wikimedia commons

    Musk’s email is quoted here, and seems to have been sent in response to a dissatisfaction with default communication and knowledge sharing habits at Tesla.

    There are 6 things I want to point out regarding this email, which I have highlighted in the text of the email


    1. Musk is setting the expectation for lateral communication and knowledge flow, rather than the vertical communication seen in many other organisations (which I describe as knowledge hedge-hopping).
    2. He makes his expectation very clear, and backs it up by spelling out the consequences (“Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company”).
    3. He places this expectation in the context of problem-solving and asking for help (“Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company”). Musk is looking to drive a culture of “open asking”.
    4. He makes this expectation very eplicit. It is not a request, it is an obligation.
    5. He separates out this behaviour of problem-driven asking from “random chit-chat”, and sees it as key to competitiveness.
    6. He recognises that the default “hedge-hopper KM” behaviour is driven by a natural human tendencies which needs to be “fought” in support of the corporate good.
    Here is the email quoted in the link above (the text in bold below was highlighted by me, not by Elon Musk)

    Subject: Communication Within Tesla 

    There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company. 

    Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding. 

    Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager’s manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else’s permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well. We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility. 

    One final point is that managers should work hard to ensure that they are not creating silos within the company that create an us vs. them mentality or impede communication in any way. This is unfortunately a natural tendency and needs to be actively fought. How can it possibly help Tesla for depts to erect barriers between themselves or see their success as relative within the company instead of collective? We are all in the same boat. Always view yourself as working for the good of the company and never your dept. 

    Thanks, Elon

    View Original Source ( Here.

    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. 

    View Original Source ( Here.

    The Knowledge Management Iceberg model

    The KM iceberg is a common image, but what does it really mean?

    The Iceberg is a very familiar model within Knowledge Management, seen in many slide presentations. I first used it myself in the public domain, in an article in Knowledge management magazine, 2000, entitled “Mining the deep knowledge – tapping into things you don’t know you know” (contact me through comments for a reprint) and I have re-used it many times over the last couple of decades.

    In the iceberg analogy,the documented knowledge of an organisation is like the visible portion of an iceberg, and the undocumented explicit knowledge (things people know that they know but have not documented) is underwater, but close to the surface, in the daylight zone where it is visible.

    The documented knowledge can, in theory, be seen and found easily, as it lies in plain sight.

    Similarly the undocumented explicit knowledge can be found and accessed if you can find the right people to direct a query to.

    However deeper down, out of sight, lies the vast mass of unconscious tacit knowledge; the bulk of the iceberg. This knowledge is invisible, inaccessible, and easily overlooked. These are the things that people don’t necessarily know that they know – the unknown knowns – and this is very often the deep-lying technical knowledge and mastery that is of real value to others.

    Before this knowledge can be shared and applied, it first needs to be made conscious. A process of realisation is needed, to move the knowledge into the conscious domain, and to bring it up into the sunlight.

    Much as data may need to be mined out of documents to be useful, so the unconscious knowledge needs to be mined out of the human brain before it can be made conscious and explicit, and then (if necessary) documented. This “brain mining” is a skill, which can be learnt and taught, but it is primarily a human activity that cannot be automated. It is however the highest value step in the entire spectrum of knowledge management activity.

    The mining tools we use to reach this deep knowledge are Questions, and any knowledge management system that does not somewhere involve some question-based processes will never reach the deep dark unconscious tacit knowledge where the real secrets of success and failure are to be found.

    View Original Source ( Here.

    When learners become teachers – how community roles shift over time

    Community of practice members may start by being learners and end up being teachers who still learn.

    Let’s look at patterns of behaviour in a Community of Practice forum, or discussion area.

    • When a novice employee is very new to an organisation or to a topic, they are usually very quiet in a community forum. They are still learning the basics, which they get from training and from the community knowledge base, and they spend 100% of their community time watching and reading community discussion. They don’t tend to ask questions on the forum – their questions are still fairly basic, and if they do ask, the answer is usually a version of “read the flipping manual“.
    • After a while, and maybe quite quickly in some cases, the employee starts to face problems and issues that are not in the manual. That’s when they start to ask questions of the Community, and begin to use the Community members themselves as a resource. They move from 100% lurking and reading, to (over time) mostly asking.
    • After a bit more time, the employees begin to find that they themselves can answer the questions of others. They have become practitioners, they understand the practice, and can share the lessons they have learned. This can happen relatively quickly as well – I remember interviewing one guy who was less than 2 years into the company, and a question came up on the community forum which was related to a special study he had just completed.  He answered this successfully, and reported how pleased he was to be able to “feed something back” to the CoP.
    • The more experienced members- now experts in their topic –  may take on a leadership role in the CoP, as core team members, or as subject matter experts, with accountability for teaching and for owning some of the Knowledge Assets of the Community.  However a good expert never stops learning. Only last week I saw, in a busy community forum, an expert asking for feedback, comments and advice on a document she had produced. Even the most advanced expert should spend some time asking, some time answering, and some time teaching.
    Now lets map some demographics onto the diagram above. 
    Imagine a far-eastern company, with many many young staff, and few experts. Here the bulk of the staff will be in the Red area in the diagram, with a few in the other segments. This CoP will act more like a Teaching CoP, with relatively little discussion and quite a lot of publishing.
    Imagine a western engineering company, loaded with baby-boomers. Here a large proportion of the staff are in the blue, yellow and green segments. The bulk of community activity will be about discussion and dialogue, rather than about publishing and reading. 

    As always, it’s more complicated than any simple model will allow, and there is no “one size fits all” approach, but different communities of practice may operate in different ways in different settings, largely driven by the experience profile of the community members. 

    View Original Source Here.

    Why Yammer’s default question is unhelpful

    If you agree with me that the greatest value in organisational online discussion comes through answering questions, then Yammer’s default prompt does not help.

    “What are you working on?” asks Yammer – as a work-related version of the Facebook question “What’s on your mind”.

    As a way of getting people to share work-related activity, that’s a reasonable question, and pretty soon you will find your Yammer stream full of statements like

    • “I’m working on a new proposal”
    • “I’m getting ready to go on holiday”
    • “I’m finishing the assessment report”

    For some people, that’s interesting connectivity, that helps them feel connected with co-workers. For others, that’s unwelcome Noise; stuff they didn’t need to know that distracts them from their own work. The risk is that the noise turns people off.

    This blog has long championed the use of Knowledge Pull behaviours, and Knowledge seeking.  We know for example that Asking is tougher than sharing, but gives instant results. We know that the more questions that are asked in a Community of Practice, the more successful it is. We know that 75% to 90% of knowledge sharing comes as a response to a request for help. We (or I, at least) believe that an internal knowledge market is best grown through demand rather than through supply. And also  that Facebook is not a good analogue for in-house social media.

    If you want to use a product like Yammer for knowledge sharing, then I can’t help thinking there’s got to be a better default prompt – one that drives Pull and not Push; one that develops the habit of Asking.

    Maybe something like

    “What knowledge do you need to help deliver your work?”
    “What can your social network help you with today?”
    “What question do you have for your network?”

    View Original Source Here.

    The role of Asking in Knowledge Management

    Most knowledge sharing in our private lives is driven by Asking. Let’s use this in work as well.


    Think about the last time you shared knowledge with one of your friends or family. Maybe it was this morning, or yesterday – maybe you shared advice, a tip or hint, or something you had found out that the other person did not know.

    I bet you shared this knowledge bacause you were asked.

    • “Where are the car keys?”
    • “What’s the weather going to do today?”
    • “Are you doing anything tonight”?
    That’s the way that private knowledge sharing seems to work; it follows the three rules below.

    When do we share?  Most often, when we are asked

    Who do we share with? People who ask us

    What is preventing us from sharing? Often, nobody is asking (see here to understand how to tell when sharing is broken)

    So how do we take these principles into the workplace?

    There are several ways in which you can introducing Asking as part of a Knowledge Management framework.

     The first obvious example is in Communities of Practice. The most important and powerful role of CoPs is providing a forum where CoP members can ASK questions of their peers. The forum allows the person who actually needs the knowledge to ask directly, and the answer comes from the members with knowledge to share.  Communities access the long tail of knowledge, and communities work better with a large element of “Knowledge Pull”

    The second case is in After Action Reviews. Here someone in the team, such as the team leader, ASKS a series of 5 questions, to elicit the knowledge of the team. This knowledge will be used by the same team to improve their practices, so the knowledge providers and knowledge users are the same team.

    The third example is in end-of-project Retrospects. Here the questioning is led by an experienced external facilitator. The process is an asking process – structured, quality assured, and aimed at answering (in advance) the likely questions from future projects.

    Asking is the most powerful way to drive knowledge transfer – Pull is more powerful than Push

    View Original Source Here.