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. 

When knowledge sharing becomes collaboration

There is a step in the maturation of communities of practice when their focus shifts from knowledge sharing to collaboration

Working together, a photo by Hepcat75 on Flickr.

Collaboration is an unnatural act in humans.

We are tribal animals, and all our instincts lead us to see life in terms of "us and them". When we divide people into teams in our "Bird Island" experiment, for example, each isolated team naturally starts to compete against the others without any prompting from us.

The famous "Eagles and Rattlers" experiment showed how this competition, when strengthened, began to lead to destructive behaviour. We can see this behaviour in any society driven by competition for limited resources.

This is often the case in business. Divisions are in competition for budget and people, and as a result the familiar organisational silos emerge and strengthen. The Eagles/Rattlers experiment demonstrated that traditional forms of team-building - social events, movies etc - did not break these silos. Something different is needed.

Communities of practice can begin to break these silos. Initially Communities operate as a self-help mechanism, where people in one silo raise a question which people in other silos can answer. Through principles of reciprocity and "what's in it for me", knowledge begins to flow through the communities.

However there is a radical step in Community behaviour, when they start to focus, not on value to the individual, but the value they collectively can generate. In our Community Maturity model, this is the step from 3 to step 4 on many of the key variables, and is where communities move from being a mechanism for knowledge-sharing to a mechanism for collaboration.

Let me explain why this step is so important, by going back to the "Eagles and Rattlers" experiment.

In this experiment, the groups of boys in an American summer camp were divided into hostile tribes by giving them competitive tasks. However the experimenters were able to turn this around completely, and to develop a massively collaborative culture, simply by giving them collective challenges that each group could not solve on their own.

Simple step, massively powerful outcome.  The way to break silos is to give challenges no silo can achieve on their own.

The same thinking can be seen in the "T-shaped Manager" approach. Give managers collective targets, and they cease competing internally.

Communities of practice can take this step almost as an evolutionary process. I remember a Community meeting many years ago, when someone stood up - eyes shining - and said "guys, just think what we would accomplish if we all worked together on this. I bet we could cut costs by 50%!"

This is where a CoP starts to think less about one individual or team solving the problems on another, and more about pooling everyone's knowledge to make a step-change in collective performance.  That's when a sense of true collaboration begins within the Community - something that previously might have felt unnatural.

That's when you can hear the sound of silo walls collapsing

How a lurker benefits from observing collaboration

A lurker within the massively collaborative Polymath project explains the benefit he received.

Lurking Cat, by Filip Maljkovic, on Flickr

The Polymath Project is a collaboration among mathematicians to solve important and difficult mathematical problems by coordinating many mathematicians to communicate with each other. The project uses a blog, to manage conversation, and a wiki to build the solution. Mathematicians of all seniorities take part, the result is truly collaborative, and several papers have been published under the pseudonym D.H.J. Polymath.

A recent paper discussing the solution of the 8th problem to be solved by the Polymath community contains an interesting couple of paragraphs by an American Undergraduate maths student, Andrew Gibson. Andrew and his classmates are not yet experienced enough to contribute to the project, but they gained valuable knowledge and insight through lurking and observing.

As Andrew explains

"Shortly after Zhang announced his result and you (Tao, the coordinator of the Polymath community) proposed the project, my classmates and I began a small, weekly seminar with a professor devoted to studying some of the theory involved (analytic number theory, sieve methods, etc.), albeit on a much more elementary level that was within our reach.

Of course, the majority of the actual proof is still mostly over our heads but at least I feel as if I’ve gained a bird’s-eye-view of the strategy and, probably more importantly, how it fits into the larger field. (For instance, before any of this, I could never have explained the Bombieri/Vinogradov theorem or the Hardy-Littlewood prime tuple conjecture.) So for us the project was a great excuse to enter a new subject and has been immensely educational. 

More than that though – reading the posts and following the ‘leader-board’ (blog) felt a lot like an academic spectator sport. It was surreal, a bit like watching a piece of history as it occurred. It made the mathematics feel much more alive and social, rather than just coming from a textbook. I don’t think us undergrads often get the chance to peak behind closed doors and watch professional mathematicians “in the wild” like this so, from a career standpoint, it was illuminating. I get the sense that this is the sort of activity I can look forward to in grad school and as a post-doc doing research (...hopefully). I also suspect that many other students from many other schools have had similar experiences but, like me, chose to stay quiet, as we had nothing to contribute. So, thank you all for organising this project and making it publically available online".

I love the bit about  "academic spectator sport" and "watching professional mathematicians in the wild".

This is the benefit of a community deliberately "collaborating out loud" to an audience of more novide members - they get to experience the way the experts think and the way they collaborate on solutions. It's an intense learning experience for the lurker.

When collaboration does more harm than good

Collaboration is not always helpful, and there are cases where it actually reduces your chance of success.

The ideas in this blog post are from a very interesting paper by Martine Haas and Morten Hansen, who look at success data from bid teams to find out when collaboration actually helps performance.

They looked at a series of bid teams, assessed how much they accessed documents from previous bids (which they called "codified knowledge"), and how much they received advice from experienced colleagues outside the team ("personal knowledge"). They then looked at bid success rates, to give an objective measure of the VALUE of the knowledge to the team.

Now, we might assume that the more Knowledge a team accesses, the better their performance?

Unfortunately it is not as simple as that.

Results of the study

The graphs shown here are the authors' conclusions about how much in knowledge helps to improve bid performance, in varying circumstances. In each graph, the vertical axes represents increasing bid success probability, the horizontal axis represents increasing amount of knowledge used, the black line is "codified knowledge" (reuse of documents) and the purple line represents "personal knowledge". If the lines rise from left to right, then increased knowledge is linked to increased chances of success. If they fall from left to right, then increased knowledge is linked to reduced success. Read the paper to understand the evidence behind these.

The top left graph (2i) represents a team which is inexperienced (and so has a high need to learn), working in a situation where they do not need to differentiate the bid significantly, so can deliver a fairly standard proposal. In this case, the more knowledge they use, the more documents they copy and the more experts they refer to, the better their chances of success. Here collaboration is helpful.

The top right graph (2ii) represents a team which is inexperienced (and so has a high need to learn), but are working in a situation where they really need to differentiate the bid. Here it is a great idea to get input and knowledge from experienced colleagues, but the re-use of documents from previous bids is actually harmful to the chances of success. So here the right collaboration is helpful.

The bottom right graph (2iii) represents a team which is experienced (and so has a low need to learn), and who are working in a situation where they really need to differentiate the bid. Again, it is a great idea to get input and knowledge from experienced colleagues, but the re-use of documents from previous bids is actually harmful to the chances of success. Again the right collaboration is helpful.


The final graph at bottom left (2iv) represents a team which is experienced (and so has a low need to learn), and who are working in a routine situation where bid differentiation is not needed. In this case, they pretty much know what they are doing, and re-using any knowledge does more harm than good. Collaboration is harmful.

So what's the conclusion?

The conclusion is that collaboration, the re-use of documents or seeking input from others is not always going to help you, and in some cases it can hinder.

In most cases (3 out of the 4), the more input you get from colleagues the better, but also in  most cases (3 out of the 4), recycling documents from other teams will not help you perform better, and may even harm your chances of success.

So know your context, and choose a collaborative method that will actually help, not hinder. If you are experienced, and dealing with routine work, collaboratiopn may be a distraction you don't need.

4 levels of collaboration

Collaboration is one of those terms that always sounds good, but covers a wide range of possible behaviours. Here are 4 of those behaviours.

I believe you can define four levels of collaboration, based on what the collaborating parties offer each other.

Sharing documents and artefacts

The first and most basic level is where collaboration involves using the work products of other parties.  These work products could be in a shared library for example, and "the others" have no involvement apart from creating the work products in the first place. They may not even know their work products have been reused.  This collaboration is so basic,  you might argue that it's hardly collaboration at all.

Sharing ideas and opinions

The second level is where the you need to access opinion from others.  The opinion collection might be in the form of a survey, or open-ended feedback, or crowdsourcing vian an online ideas jam or brain storming session.  Once the others have provided their opinions, ideas or feedback, they have no further involvement in creating the outcome (the new strategy, the new approach, whatever it might be that needed to be informed by those opinions). Although they have an interest in the outcome, and would like to see their opinions acted on, they don't have any further involvement until the outcome is ready.

Sharing knowledge

The third level is where the business needs to access advice, knowledge and experience from others.  Collecting this knowledge might happen through a community of practice, or through a peer assist.  The others provide advice, provide guidance, are involved in questioning the business unit that originated the collaboration, and have an advisory role in creating the outcome. However the outcome is not primarily for them, it is for the originating business unit. So althrough they are involved in creation, they don't have equal ownership of the outcome.

Sharing work and effort

The fourth level is where the business needs actively to work with people from elsewhere as part of a short lived co-located team, or a longer lived virtual team.  It needs the skills and input and judgment and effort from the others, and the outcome is co-created with the others. All parties have equal ownership and equal involvement in the outcome.

Why you should not ask your senior managers to blog

 If you wish to introduce blogs as a knowledge management tool, it is tempting, but dangerous, to ask senior managers to take the lead.  Here's why it's dangerous, and what you should do instead. 

Let's assume

1) that you want to introduce Knowledge Management,
2) that you want to improve exchange and re-use of knowledge between peers in the organisation,
3) that you have chosen blogging as a component in the toolbox, and that
4) you would like this tool to be used widely by the knowledge workers for collaboration and knowledge sharing.

Perhaps your vision is that a project team could use a blog as a shared, recorded and comment-able "project log" for storing lessons as they are identified, or a community of practice could use a blog as a way to develop knowledge collaboratively (see for example this story on the use of blogs and wikis for collaborative problem solving).

It can be very tempting to ask someone senior to take the lead in blogging and to set an example for the organisation, and he or she will very often agree. Your KM sponsor, for example, might agree to lead by example.  But this will not help you in the long run.

The wrong model

The big problem with senior manager blogs is that they are not the example that you want to set or the model you want others to copy. They are different, and generally they are not focused on knowledge sharing.

• A director blogging is a bit like a director standing up behind the lectern and making a speech. It's heirarchical - it's "me preaching to all of you".  Is not really very conducive to two-way discussion or dialogue. Most of the directors blogs that I have seen have been one-way, with little or no comments. And if you want to know more about the topic covered by the blog, there are pressures against picking up the phone and asking the director for more details.  This one-way blogging belongs to Internal Communications and not to Knowledge Management. It is not collaborative, and its not an example you want to set as part of your KM program.

• Very rarely is does the blog contain knowledge (by which I mean concrete "how to" advice and details which will help the reader do their job better). The director is not communicating to peers.  Most of the directors blogs that I have seen have been general musings, or thought pieces. They may sometimes be of interest to the audience, but they're not going to teach the audience anything that helps them do their job better. It won't make a difference to the way people work. It won't add immediate value. Blogging which does not transfer knowledge to help people work better is not an example you want to set. 

• If you are a director, you care about style (with a few happy exceptions, of course). You want your post to be well crafted.  You may even get somebody else to write it for you.  It becomes formal, it becomes a publication, and not the start of an informal conversation that invites others to take part. That's not the blogging example you want to set; you would much rather have that sort of messy informal creativeness that leads to real knowledge.

• It becomes "something extra to read". Instead of providing a better alternative to existing mechanisms of sharing knowledge between peers, you have created something new to read which doesn't teach you anything that really helps you, but is just "yet another top-down communication from management". You are adding noise to the system.

Blogging per se - blogging for the sake of it - is not worth doing. Blogging to share knowledge and  collaborate is what you need, and this should be the first model you set.

A better way

A better way to introduce blogging is to take the already existing internal communication mechanisms within communities of practice or projects, and replace some of these with blogs. Take the ways people currently try to share knowledge, and improve them. For example -

• Maybe your community of practice has a quarterly newsletter, with a dozen articles. Replace this with a weekly blog, in order to get the news out more quickly, and in order to allow commentary on, and discussion of, the key items (which was never possible in a hard copy newsletter).

• Your community of practice may routinely send out email alerts about new lessons, improve practices, and other things that the community members really need to know about. Replace these Email alerts with blog items, which can be searched, can spawn comment threads, and which avoid the curse of "reply all".

• Perhaps your project manager sends out a weekly email summarising progress and learnings. Replace this with a blog, and ask people to comment on the learnings and the actions arising, and add other insights they may have.  This can be very useful for virtual teams.

Think carefully about how you promote blogging.

Start by modelling the outcome that you want to see, which is peer-level sharing of useful knowledge that others will use to improve the way they work. Think about the WIIFM for the reader, and make sure the blog gives them something they can use immediately to make their work better or their life easier.

Beware the seductive but potentially damaging option of the senior manager's blog.

How communities solve problems

I am reprising this blog post from 5 years ago, because I think it is a fascinating study of how communities solve problems - often very big and complex problems.

The story comes from New Scientist magazine and describes the results of a study into how mathematicians collaborated to solve a major mathematical problem.

The problem to be addressed is known as Polymath1, and the blog- and wiki -based approach is described here as follows

"In February, 2009, an international group comprising mathematicians ranging from amateurs to elite professionals converged on the WordPress blog of Cambridge mathematician Timothy Gowers in order to attempt to prove a mathematical theorem; a project Gowers called Polymath1. Their results surprised even the project's most optimistic participants. In six weeks, the group had managed to combinatorially prove the density Hales-Jewett theorem, yielding in the process a host of new mathematical insights".

The approach used by the mathematicians, and their use of blog-based online discussion, and the development of a collaborative wiki,  in many ways mimics how members of a community of practice may work together to solve a business problem, or to answer a problem of one of the members.


The Polymath project was a huge success for a collaborative approach, but equally interesting are the statistics shown in the diagram concerning where the contributions within the collaborative group came from. The diagram's vertical axis represents the number of contributions from each individual, the horizontal axis represents the "significance" of each contributor to solving the problem, and the size of the blob represents the professional seniority of each contributor, with small dots being "professionally junior" and big dots being "professionally senior".

The most interesting thing about this plot are the small dots in the "low volume, high importance" sector - the non-experts who made vital contributions to the collective effort.

These aren't the famous expert mathematicians, they are people such as Jason Dyer, a mathematics teacher in Arizona, which was able to throw light on one type of logic puzzle involved in the final solution. With tricky problems, its not always the experts that have all the answer. The diagram above shows that many people can contribute, and that the non-experts can provide crucial input (see here, here and here for more on the role of the experts in KM).

So what is the lesson for those of us working in Knowledge Management?

I think this data throws light on one of the choices we need to make, which is whether we create communities of experts, or communities of practitioners.

• Some companies like to create communities of experts, or lists of experts, who people can go to if they have a problem to solve. The thinking is that "the knowledge is held by the experts, so they are the default people to go to".
• Other companies like to create communities of practitioners, or lists of everyone working in an area, who people can consult if they have a problem to solve. The thinking is that "the knowledge is out there somewhere; it might be with the experts, it might not, so let's ask everyone and see what we turn up".

The former is like "phone a friend", the latter is like "ask the audience".

What the data from Polymath1, shown in the graph above, demonstrates is that the non-experts can make massively significant contributions, and that asking the audience seems to be, certainly for this type of problem, a far more effective strategy.

Contact Knoco for help developing your community strategy

the 5 levels of organisational networking.

We hear a lot about communities of practice in Knowledge Management, but they are not the only type of organisational network. 

Communities of practice are a very powerful component of KM, but the term can be used to cover a multitude of networks. In order to manage these networks well, we need to differentiate the different types so they can be given the correct resources and structure.

Here are 5 types. 

A team is a network of people put together to deliver a product or service to the organisation or to a customer. The team may be co-located, or virtual.  Membership of the team is by invitation, based on skills and experience. The limits of the team are clear - you are in, or you are out. There are clear job requirements, shared line management and the teams share a common goal/responsibility linked directly to organisational performance. The team lasts as long as the task, and the task is directly relevant to organisational performance.

A Practice Group aka Community of Purpose is a network of people from many teams, put together to ensure collective achievement of a stated strategic goal which is usually knowledge-related (for example to develop knowledge and capability in a specific area of business).  Membership is by invitation, based on experience, expertise, and the ability and motivation to influence change. The limits of the group/community are clear - you are in, or you are out.  They have a unifying purpose, a leader, common goals and collective responsibility, but the members are usually line managed separately. They hold a performance agreement with their sponsor, and members of the group are funded to take part (through timewriting codes for example). The group lasts as long as the strategic purpose remains relevant, and the group is one step away from organisational performance; they create and manage knowledge that teams use to perform.

A Community of Practice is a network of practitioners from many teams and departments. The purpose of the community is to create, expand and exchange knowledge & develop individual capabilities. Community members join the community to gain access to knowledge, and (with the exception of the leader and maybe the core group) are not funded to join and have no timewriting code for community activity. Membership is by self-selection based on interest or expertise for a topic, and the boundaries of the community are fuzzy; people are always joining and leaving.  Members self-select through passion, commitment and identification with the group & its expertise. The community needs a leader, a core group, and a charter, and will last as long as there is relevance to the topic & value in learning together. The community works best by solving members' problems and answering their questions, and is thus one or two steps away from performance - it provides knowledge to the members, who take it to their teams, who then perform.

A Community of Interest is a network of people with an interest in a topic, but who are not active practitioners. They join the network to be informed. Membership is open to whoever is interested, and people join and leave. The community provides access to information and and a sense of like-mindedness, and needs someone to coordinate it. These communities are several steps away from performance. A member may be notified of something, which prompts them to learn more, which knowledge they can take it to their teams, who then perform.

A Social Network is a network of people with social ties who operate through social interactions. They join the network to meet and communicate socially with others. Membership is open to anyone, and requires no coordination. These communities are several steps away from performance. A social network enables social ties, which may promote a culture of openness, which then enables communities of interest, practice and purpose to form more easily.

Networks may evolve from one type to another, and they are often "nested" - a community of practice, for example, may contain a funded core team which acts as a practice group, and may also attract members who are not practitioners bu just "interested" - a surrounding community of interest.

The point is that different types of networks require different formality, and if you want to manage them well, you need to know which type you are dealing with. 

What's the best thing to do with uncodfied knowledge?

Knowledge Managers sometimes assume that the best thing to do with uncodified knowledge - that undocumented knowledge that people still hold in their heads - is to capture it. Often however the best thing is to leave it where it is. 

Image from wikimedia commons

There are very many examples of cyclic Knowledge Management models where the cycle begins with "Capture", or at the very least, contains "Capture" somewhere within it.  This is a result of a default assumption that to manage knowledge, it must be codified. "We must make our tacit knowledge explicit" Knowledge Managers say, confusing tacit with uncodified, and explicit with codified.

However very often, the best thing to do with uncodified knowledge, whether it is tacit or explicit, is to leave it in the heads of the people until it is needed by others.  Capturing and codifying knowledge is labour-intensive, difficult to do, and even more difficult to do well. You can only capture a small fraction of the knowledge someone has in their heads - the rest is either too difficult to explain in words, and the knowledge-holder may be unaware of much of their knowledge (we refer to this deep knowledge of which the holder is unaware as the Unknown Knowns, or the unconscious competence).

Similarly there may not be a need for all of that knowledge to be captured. There is no point in capturing knowledge if it is not needed by someone else. If we documented all the uncodified knowledge in an organisation - downloaded the contents of every head onto paper or into files - we would have a fantastically comprehensive library of which only a tiny shelf in one corner is likely to be read.

Better then, in many cases, to leave the knowledge where it is, until it is needed. Provided that the person who needs the knowledge can,  at their time of need, find the relevant expert and have a conversation with them, then that knowledge is safe and secure.

Safe and Secure, that is, so long as you you follow the advice below.

1. Only leave the knowledge uncodified if there is limited demand for it.

The primary problem comes when you leave uncodified those areas of knowledge which are in high demand. In such cases, having to ask the expert for advice all the time just adds load to the expert. Such high-usage knowledge is worth codifying; the effort spent in codification and capture far outweighs the otherwise overwhelming demand on the expert's time. It becomes easier to refer the enquirer to a Frequently Asked Question site or other knowledge asset, rather than have to answer the same questions and hold the same conversations over and over again

2. Only leave the knowledge uncodified if the expert is guaranteed not to forget

This means that the knowledge must cover topics which are in constant use. If an expert is not constantly using their knowledge, then they need to store it away in their long-term memory, which is a poor knowledge store. Even the best experts forget over time, if the knowledge is not regularly used.

3. Only leave the knowledge uncodified if the expert is guaranteed to stick around

If there is any chance at all that the expert will retire, or quit, then codify and transfer that knowledge as soon as you can as part of your Knowledge Retention and transfer program.

4. Only leave the knowledge uncodified if the practitioners - expert and novice - are connected. 

There is no point in leaving the knowledge in people's heads, if those people cannot be found. Tacit knowledge remains an asset to the organisation if the people are connected; connected in communities of practice, indexed in a know-how directory, and connected through collaboration and discussion software.

If these four caveats are in place, then often the best thing to do with the knowledge is leave it in the heads until you need it. 

Too much collaboration?

Let's collaborate by Ron Mader on Flickr

Collaboration is one of those words that is often taken as being overwhelmingly positive, and something everyone should do. But is it?

With the exception of France, where a "collaborateur" is still a dirty word, the concept of collaboration is usually seen as a very good thing. When people cooperate and collaborate across borders and organisational divisions, we expect good things to happen.

But as with most generalisations, this is only partially correct.

I have already reported how Haas and Hansen, in a study of a large services firm, identified cases where collaboration helps, and other cases where collaboration hinders success. Not all collaboration is good - some of it is a waste of time or creator of unneeded confusion.

And now here is an interesting article by Rob Cross, Reb Rebele and Adam Grant on collaborative overload, which points out that requests for collaboration are seldom evenly distributed, and often the collaborative load falls on relatively few employees. They say, for example, that up to a third of value-added collaborations come from only 3% to 5% of employees, and that these employees often feel overloaded, disengaged and disaffected as a result, and can become bottlenecks rather than enablers.

Cross et al suggest ways in which this issue can be addressed; once the overloaded collaborators are identified, you can either give them ways to filter out, or shut off, requests for help, you can use redesigned office space and/or collaboration tools to make collaboration less of a burden, you can spread the load, and you can look for ways to reward collaboration.

There is another way as well.

If

• 3% of the staff are in huge demand as collaboration agents, and
• their collaboration efforts are adding value to others, and 
• this value outweighs the value of their own work (which it may well might, but you need to check)

then give specific collaboration roles to this 3%. 

Roles such as Community of Practice Leader, CoP Facilitator, Knowledge Owner, Knowledge Manager, Knowledge Librarian - all of these can be excellent roles for the ace collaborators, which will fit and recognise their own drive to collaborate, make them happier and more fulfilled, and add value to the organisation as part of a Knowledge Management Framework. 

We should not assume that collaboration is always over and above your dayjob - collaboration can *be* the dayjob.

Take the road more travelled in Knowledge Management

One of the systems design principles behind the IDEO in-house collaboration system is to "Take the Road More Travelled". This means building a tool that works, as much as possible, the way people are already used to work. 

Main street Omote sando by Ari Helminen on Flickr

As IDEO say -

"if a tool requires people to go out of their way to use it, adoption will always be a challenge, no matter how wonderfully designed. Wherever possible, strive to integrate tools into existing work processes -- bring the system to the user rather than the other way around. For example, the IDEO blogging system didn't take off until the team added a program that sends digest emails with new content from the blogs each employee has subscribed to"

If people are used to receiving notifications through email, then link your system to email. Don't expect people to develop a new work habit just to be able to share knowledge, because they won't.

As Samuel Johnson famously said, "Mankind has a great aversion to intellectual labour; but even supposing knowledge to be easily attainable, more people would be content to be ignorant than would take even a little trouble to acquire it".

So remove the need to take trouble. Lower the barriers to entry to your Knowledge Management system. Take the road more travelled.

The Collaboration conversation

---

collaboration, a photo by mbp on Flickr.

A couple of weeks ago, APQC hosted a very interesting and insightful twitter conversation in which I took part, on the topic of Collaboration.

It's very difficult to provide deep thinking in 140 characters, so I would like to take the opportunity to explain some of my answers in more detail. The Questions raised at the conversation (Q1 to Q7 below) are followed by my tweeted answers, and then by some more explanation. You can find the whole conversation here, including answers from other participants

Q1: How do good organizations define collaboration?

A1 Collaboration is one of fuzziest words in KM (already a fuzzy topic)
A1 One client said “a deliberate approach to working together and sharing learning on agreed commercial priorities across borders”
A1 The term is often used in undefined manner. lack of clarity can cause frustration with managers who view collaboration as “clutter"

It's one of those terms which nobody can argue against, but which nobody has really defined. The boundaries between collaboration, cooperation, alignment and teamwork are very fuzzy. Is working on a virtual team collaboration? Some would say so, some would not. Is putting your work products online for others to find, collaboration? Some would say so, some would not. If you are approach to drive collaboration in your organisation, one of the first things you need to do is define the scope. The definition in the second of the answers above is one of the ones I like best - the nature of "working across borders" separates collaboration from teamwork.

Q2: What do your executives want collaboration to accomplish?

A2 Often they don’t know! But collaboration should not be an end in itself
A2 1,000 heads are certainly better than one, but you have to define - "better at what"?
A2 The end should be sustainable commercial success. Collaboration should be a business choice

More than once I have hear of senior managers and company presidents saying "we want to become more collaborative", as if collaboration is an end in itself. It isn't. You collaborate in order to achieve something which you could not achieve alone, and in a business context, this should lead to a better business result. Collaboration for its own sake can often be counter-productive - see the study of collaboration by Hansen and Hass which shows that in some circumstances collaboration actually hinders rather than helps

Q3: When do people most likely want to collaborate?

A3 When there’s something in it for them (or when assigned to a collaborative team). Collab needs 2-way benefit
A3. Alternatively, when everyone else is doing it – power of peer pressure
A3. People don't actually want 2 collaborate every day. Often they don't need to
A3. Never underestimate the principle of local value - people must get out more than they put in

I see three cases where people want to collaborate. The first is if they are assigned to a collaborative team, and given the role, the time and the challenge of working together with others to create something. The second is where they get direct benefit, for example when they can draw on the knowledge of others to help them solve a problem or plan an activity. The third is where they gain indirect benefit through helping others. By helping others to solve their problem or plan their activity, they gain profile and reputation, and "make a deposit in the favour bank".

However, just as collaboration is not an end in itself, and some collaboration hinders rather than helps, not everyone needs to be collaborative all the time. There is a reason we work in silos - silos help get teh work done. They provide focus and structure. Part of the trick of becoming an effective collaborative organisation is knowing when to collaborate and when not.

Q4: How can SharePoint be a positive or negative for collaboration?

A4 IMHO SharePoint is the lowest common denominator of the collaborative world
A4 For practically any collaborative task, there's a better tool than out-of-the-box SharePoint (with the exception of document version control)

SharePoint is ubiquitous nowadays, and came with the promise of being collaborative software. Again, it all depends on what you mean by collaboration, and provided you are dealing with Information, document control and multi-authored documents, SharePoint is fine. If you want to go beyond that level of collaboration, then certainly in the past SharePoint has been very limited. Organisations have turned SharePoint 2007 into an effective collaboration tool after massive amounts of customisation, but out-of-the-box functionality has been very disappointing, when you compare it to purpose built collaborative tools such as Confluence and Jive.

I would say that overall the ubiquitous presence of SharePoint has been negative to collaboration. It reminds me of the first few visits I made to Azerbaijan, when every car on the street was a soviet Lada. Certainly you can drive a Lada, but as driving experiences go, you would be far better off in a Range Rover or a Mercedes.

This may all change with SharePoint 2013. I don't know it well enough yet to comment fully, but certainly the wiki functionality, at least, seems far better.

Q5: How important are tools like Wikis, CMS, and Repositories to good collaboration?

A5. Depends on what sort of collaboration you are talking about. Wikis are good for creating a collaborative product
A5 the best collaboration comes through conversation, not through documents.

It is the Behaviours that make for good collaboration. The tools can help.

For me, repositories and CMS enable the absolute base level of collaboration. Putting your documents into a shared repository is barely collaborative at all - its more a form of cooperation than collaboration. Wikis on the other hand can become truly collaborative if they

Collaboration requires more than a single tool, and more than a toolkit as well. Like all forms of behaviour, collaboration needs a collaborative framework, of which tools play a part.

Q6: What snuffs out collaboration?

A6 Internal competition is the worst offender
A6 Lack of empowerment is a second - why collaborate if you cant use the results
A6. Collaboration is also often seen as “not real work”
A6 Lack of time is only a symptom of wrong priorities. if it were a priority, we would find the time.

I have talked many times on this blog about the damaging effects of internal competition. There are of course many cultural issues that can snuff our competition - we recognise 10 dimensions to a learning culture, which gives us 10 ways to kill collaboration for a start - but the two others I mentioned are important. I have been working with a company recently which has set up some excellent collaborative structures, but staff hit a brick wall when trying to implement what they have created. In this company, and in many others, collaboration is therefore seen as something "extracurricular".

The "lack of time" argument is often quoted as one of the top cultural barriers. But in fact, it's not a question of time, it's a question of priority. Capturing and sharing and resusing knowledge needs to be seen as part of the job, not an add-on, and just as much a priority as many other management aspects of the way we work.

Q7: What are key collaborative skills organizations can develop in employees?

A7 Collaboration is not a skill, it’s an attitude. Develop the attitudes
A7 Humans know how to collaborate when they want to, we have done it since childhood 

 There are such things as collaborative skills, but the problem that faces most organisations is not unskilled collaboration, but lack of collaboration "full stop". I would not encourage a company to focus on the skills, until the attitudes and behaviours are in place. The skills can then be developed, especially through teh use of

When Communities of Practice grow up - how focusing on a common goal drives collaboration.

---

Working together, a photo by Hepcat75 on Flickr.

Collaboration is an unnatural act in humans.

We are tribal animals, and all our instincts lead us to see life in terms of "us and them". When we divide people into teams in our "Bird Island" experiment, for example, each isolated team naturally starts to compete against the others without any prompting from us.

The famous "Eagles and Rattlers" experiment showed how this competition, when strengthened, began to lead to destructive behaviour. We can see this behaviour in any society driven by competition for limited resources.

This is often the case in business. Divisions are in competition for budget and people, and as a result can set up the familiar organisational silos.

Communities of practice can begin to break these silos. Initially Communities operate as a self-help mechanism, where people in one silo raise a question which people in other silos can answer. Through principles of reciprocity and "what's in it for me", knowledge begins to flow through the communities.

However there is a radical step in Community behaviour, when they start to focus, not on value to the individual, but the value they collectively can generate. In our Community Maturity model, this is the step from 3 to step 4 on many of the key variables.

Let me explain why this step is so important, by going back to the "Eagles and Rattlers" experiment.

In this experiment, the groups of boys in an American summer camp were divided into hostile tribes by giving them competitive tasks. However the experimenters were able to turn this around completely, and to develop a massively collaborative culture, simply by giving them collective challenges that each group could not solve on their own.

Simple step, massively powerful outcome.

The same thinking can be seen in the "T-shaped Manager" approach. Give managers collective targets, and they cease competing internally.

Communities of practice can take this step almost as an evolutionary process. I remember a Community meeting many years ago, when someone stood up - eyes shining - and said "guys, just think what we would accomplish if we all worked together on this. I bet we could cut costs by 50%!"

This is where a CoP starts to think less about one individual or team solving the problems on another, and more about pooling everyone's knowledge to make a step-change in collective performance.  That's when a sense of true collaboration begins within the Community - something that previously might have felt unnatural.

That's when Communities "grow up".

Why in-house collaboration is so difficult

---

"Why in-house collaboration is so difficult" is the title of a really interesting piece by Andrew Campbell, originally published in the UK Financial Times in 2006.

Andrew looks at various standard reasons for the failure of collaboration, such as Not-Invented-Here, or "new skills in old structures", and instead, based on his own research, that there are several common reasons why Collaboration fails.

• Synergies may be a mirage
• Collaboration between departments may confuse the departments' primary purpose
• Big investments may be needed before synergies are delivered, and the investment may outweigh the value delivered. Opportunity costs are too great.
• There  may be no mechanism to decide which practices are "best"
• There may be buried rivalries
• There may be incompatable IT systems

Andrew's recommendation, which echoes the warnings of Morten Hansen, is simple.

1. Get very clear on the size of the prize
2. Find out why collaboration is not happening (an Assessment or culture audit will help here)
3. Determine whether you have the skill to unblock the problems
4. Calculate the cost of collaboration (resources, time, distraction, loss of accountability etc).

Like anything else in Knowledge Management, collaboration is not an end in itself - it is only a mechanism to add value.

Work out the value proposition, and maybe in-house collaboration will not be so difficult after all.

When collaboration helps, when collaboration hinders

---

This is a very interesting paper from Martine Haas and Morten Hansen, which takes a scientific and statistical view of collaboration, and whether it actually helps performance or not.

Haas and Hansen looked at a series of bid teams, assessed how much they accessed documents from previous bids (which they called "codified knowledge"), and how much they received advice from experienced colleagues outside the team ("personal knowledge"). They then looked at bid success rates, to give an objective measure of the VALUE of the knowledge to the team.

Now, we might assume that the more Knowledge a team accesses, the better their performance?

Unfortunately it is not as simple as that.

The graphs shown here are the authors' conclusions about how much in knowledge helps to improve bid performance, in varying circumstances. In each graph, the vertical axes represents increasing bid success probability, the horizontal axis represents increasing amount of knowledge used, the black line is "codified knowledge" (reuse of documents) and the purple line represents "personal knowledge". If the lines rise from left to right, then increased knowledge is linked to increased chances of success. If they fall from left to right, then increased knowledge is linked to reduced success. Read the paper to understand the evidence behind these.

The top left graph (2i) represents a team which is inexperienced (and so has a high need to learn), working in a situation where they do not need to differentiate the bid significantly, so can deliver a fairly standard proposal. In this case, the more knowledge they use, the more documents they copy and the more experts they refer to, the better their chances of success.

The top right graph (2ii) represents a team which is inexperienced (and so has a high need to learn), but are working in a situation where they really need to differentiate the bid. Here it is a great idea to get input and knowledge from experienced colleagues, but the re-use of documents from previous bids is actually harmful to the chances of success.

The bottom right graph (2iii) represents a team which is experienced (and so has a low need to learn), and who are working in a situation where they really need to differentiate the bid. Again, it is a great idea to get input and knowledge from experienced colleagues, but the re-use of documents from previous bids is actually harmful to the chances of success.


The final graph at bottom left (2iv) represents a team which is experienced (and so has a low need to learn), and who are working in a routine situation where bid differentiation is not needed. In this case, they pretty much know what they are doing, and re-using any knowledge does more harm than good.

So what's the conclusion?

The conclusion is that collaboration, the re-use of documents or seeking input from others is not always going to help you, and in some cases it can hinder.

In most cases (3 out of the 4), the more input you get from colleagues the better, but also in  most cases (3 out of the 4), recycling documents from other teams will not help you perform better, and may even harm your chances of success.

So know your context, and choose a collaborative method that will actually help, not hinder.

Can communities of practice become too big?

---

This was a question I was asked recently - whether there is an upper size limit for Communities of Practice. This person wanted to set up an internal Community of Practice within a very large organisation, with potential membership of 40,000 people (it is a VERY large organisation), and they wanted to know whether such large online communities of practice were feasible, or were too big.

I had to think for a long time about this.

Then I remembered the community of School Leaders in the UK, and the excellent publication from the National College for School Leadership "100,000 heads are better than one (lessons from the worlds largest online learning community)".

Now I don't know if this really is the world's largest, but I can't think of a bigger example. The National College are responsible for developing capacity, capability and knowledge in the School Leaders of the UK, and they do an excellent job. They provide education, accreditation, guidance, conferences, a network of mentors and coaches, and a superbly developed online facility, with Q&A forums, personal pages, reference libraries, e-learning material, featured individuals, and a back-office of facilitators and supporting staff. They have over 100,000 people registered with them, each of them working in a leadership capacity within the schools and childrens' services of the UK.

When you look in detail at their online site, however, the picture gets a little more complex. Rather than a single community, there seems to be several sub communities. There is a community for new head teachers, helping them to learn rapidly, there is a very active community of School Business managers, there is a sub-group for Transition Stage leaders (leaders of Nursery schools), and so on. Within these online communities, not every member is active every month. The College recognises a group as "Buzzing" when 10% of the members visit in a month (more on this next week) - so even for a really active subgroup of 10,000, there might only be 1000 people visit in a month. So any one member may only visit on average just over once a year, but there are enough members to create a really active community, and to form a very valuable resource for the members when they DO visit.

So super-large online communities of practice are possible and a CoP of 40,000 looks entirely feasible. However

• it will need a lot of facilitation and back-office support
• it will need an excellent online site
• it will almost certainly split into sub-communities
• participation rates per member may be low, but
• this may not matter too much.

Solving problems through blogs and wikis - lessons from Polymath

---

I blogged a while ago about the Polymath project; an experiment in collaborative solving of major mathematical problems. Recently I read again the description of the project published here, and have some interesting conclusions to share with you about this sort of collective problem solving.

According to Wikipedia,

The Polymath Project is a collaboration among mathematicians to solve important and difficult mathematical problems by coordinating many mathematicians to communicate with each other on finding the best route to the solution. The project began in January 2009 on Tim Gowers' blog when he posted a problem and asked his readers to post partial ideas and partial progress toward a solution. This experiment resulted in a new answer to a difficult problem, and since then the Polymath Project has grown to describe a particular process of using an online collaboration to solve any math problem.

So far, at least one major mathematical problem has been solved, using primarily  a combination of blogs and a wiki.

Polymath uses two types of blog

• Blogs hosted by mathematicians, where particular aspects of the problem are addressed in the blog comments
• An administrative blog, which summarises progress, and hosts administrative discussion.
• The wiki provides write-ups of the work done on the blogs. Comments on the blogs are the working process, the wiki is the summary of the outcome.

There are a number of ground rules for participation in the project, for example

• no working independantly on the problem without discussing progress on the blog
• discussions should be polite and focused
• any publications will be under a Polymath pseudonym representing the collective input

There are also some administrative conventions, such as the following

• Any blog post is not allowed more than 100 comments. This convention forces the leaders to summarise, and then restart, progress
• There are two leaders, both eminent mathematicians, whose main roles were to set the ground rules and conventions, and provide frequent summaries, highlightimg the relavenat comments and guiding the next steps.
• Comments are divided into numbered comments (comments which make a direct contribution to the solution of the problem, and which are numbered for reference by other comments), and other comments, mostly about the process or administration of discussion ("metacomments").

One of the big challenges found on the project was the difficult of bringing newcomers up to speed. As one of the leaders says, "A number of people have commented that it is difficult to catch up with the discussion if you come to it late. We should try to start each thread in a way that makes it as self-contained as possible". Any problem-solving process using this approach needs to develop an effective way to bring newcomers into the process, as the majority of contributors to the Polymath outcome were those who joined in the first week.

Polymath has proved to be a great success.  In just over 6 weeks a collective group of distributed individuals accomplished some highly non-trivial mathematical feats. The scale of the collaborative approach was large compared to most collaborations in higher math. It is relatively uncommon for a mathematics publication to have more than 3 authors, let alone 40. Many of the crucial steps in the problem solving process were from relatively junior (based on publication count) mathematicians. These are the small red dots on the lower right of the diagram above, in the blue cloud marked "low volume, high importance." Polymath1 was a group solution to a problem, with recognised experts working shoulder to virtual shoulder with relatively junior mathematicians, to solve a big problem in a short time.

I think there is a lot we can learn from this experiment, when it comes to building collaborative groups within industry, specifically

• the role of leadership
• the need for ground rules and conventions
• separation of substantive comment from metacomment
• separation of discussion (on blog comments) from conclusion (on the wiki)
• the need for regular summary and refocus, and
• the need to cater for late joiners

Four levels of collaboration - the role of "the others"

---

I am continuing to work this week on the topic of collaboration, and looking at different methodologies or structures for collaborative work. Looking at it from the point of view of the part of the business that requires collaboration, I'm beginning to think that maybe there are different levels of collaboration, related to the different levels of involvement of the "other parties".


I am starting to see four levels here.

The first and most basic level is where collaboration involves using the work products of others.  These work products could be in a shared library for example, and the others have no involvement other than creating the work products in the first place. They may not even know their work products have been reused.  This collaboration is so basic,  you might argue that it's not collaboration at all.

The second level is where the business needs to access opinion from others.  The opinion collection might be in the form of a survey, or open-ended feedback, or in the form of some sort of online ideas jam or brain storming session.  Once the others have provided their opinions, ideas or feedback, they have no further involvement in creating the outcome (the new strategy, the new approach, whatever it might be that needed to be informed by those opinions). Although they have an interest in the outcome, and would like to see their opinions acted on, they don't have any further involvement until the outcome is ready.

The third level is where the business needs to access advice, knowledge and experience from others.  Collecting this knowledge might happen through a community of practice, or through a peer assist, or through a virtual peer assist.  The others provide advice, provide guidance, are involved in questioning the business unit that originated the collaboration, and have an advisory role in creating the outcome. However the outcome is not primarily for them, it is for the originating business unit. So althrough they are involved in creation, they don't have equal ownership of the outcome.

The fourth level is where the business needs actively to work with people from elsewhere as part of a short lived co-located team, or a longer lived virtual team.  It needs the skills and input and judgment and effort from the others, and the outcome is co-created with the others. All parties have equal ownership and equal involvement in the outcome.

Collaboration processes - a first pass guide

---

We read a lot about collaboration, and there are very many guides to the use of collaboration technology.

However there does not seem to be so much available concerning the use of collaborative process, or collaborative structure. Recently, in work for a client, I have been looking for a guidance structure for collaborative process, and came up with the matrix on this page.

Does it work? Your comments welcome - this is pretty much a first pass. An explanation follows.

Firstly, I am defining collaboration here as "working together on a common issue, across organisational and/or geographical boundaries". So "working together in a co-located team" is treated here as teamwork, not collaboration.

Secondly I am looking only at process/structure, not at technology. There may be many technology solutions that could support any one process or structure.

Thirdly I am looking at multiway collaboration, and so am excluding one-way publishing in all its forms, including blogging.

The two questions which define the matrix are

1) what are you trying to achieve through collaboration?

• working together to deliver a common product or objective?
• seeking knowledge and advice from others to guide your own objective?
• seeking opinion and data from others, to inform your own objective

2) Can you do this face-to-face, or does it have to be virtual?

The first question really talks about ownership of the output, and the degree of involvement of the collaborators in the solution.

The outcomes are as follows

• What we call "knowledge exchange" - a diverse group working face to face to create a common product
• Virtual work groups and virtual teams - the virtual equivalent of ftf workgroups and teams.
• Peer Assist (real or virtual)
• Communities of Practice
• Knowledge Cafe
• "Crowdsourcing" techniques such as surveying, polling and online brainstorms

Have I forgotten anything?

It's not always experts who have the answers

---

The figure shown here was published in  the excellent New Scientist magazine this week.

It shows the results of a study into how mathematicians collaborated to solve a problem, which in many ways mimics how members of a community of practice may work together to solve a business problem, or to answer a problem of one of the members.

The problem to be addressed is known as Polymath1, and the "blog and wiki"-based approach is described here as follows

"In February, 2009, an international group comprising mathematicians ranging from amateurs to elite professionals converged on the WordPress blog of Cambridge mathematician Timothy Gowers in order to attempt to prove a mathematical theorem; a project Gowers called Polymath1. Their results surprised even the project's most optimistic participants. In six weeks, the group had managed to combinatorially prove the density Hales-Jewett theorem, yielding in the process a host of new mathematical insights".

A huge success for a collaborative approach, but equally interesting are the statistics shown in the diagram concerning where the contributions within the collaborative group came from. The diagram's vertical axis represents the number of contributions from each individual, the horizontal axis represents the "significance" of each contributor to solving the problem, and the size of the blob represents the professional seniority of each contributor, with small dots being "professionally junior" and big dots being "professionally senior".

The most interesting thing about this plot for me, are the small dots in the "low volume, high importance" sector. These aren't the famous expert mathematicians, they are people such as Jason Dyer, a mathematics teacher in Arizona, which was able to throw light on one type of logic puzzle involved in the final solution.

With tricky problems, its not awlays the experts that have all the answer. The diagram above shows that many people can contribute, and that the non-experts can provide crucial input.

So what is the lesson for those of us working in Knowledge Management?

I think this data throws light on one of the choices we need to make, which is whether we create communities of experts, or communities of practitioners.

Some companies like to create communities of experts, or lists of experts, who people can go to if they have a problem to solve. The thinking is that "the knowledge is held by the experts, so they are the default people to go to".

Other companies like to create communities of practitioners, or lists of everyone working in an area, who people can consult if they have a problem to solve. The thinking is that "the knowledge is out there somewhere; it might be with the experts, it might not, so let's ask everyone and see what we turn up".

The former is like "phone a friend", the latter is like "ask the audience".

What the data from Polymath1, shown in the graph above, demonstrates is that the non-experts can make massively significant contributions, and that asking the audience seems to be, certainly for this type of problem, a far more effective strategy.