Monday 28 July 2014

Care needed when "working out loud"

There is a lot of interest in "Working out loud" and "narrating your work" at the moment. Here are 4 things you need to watch out for, to ensure this approach adds value to the organisation.

"Working out loud" (WOL) is, at first sight, a simple and attractive idea. Social Media and group-ware enable us to narrate what we are doing so that others can be aware (and so avoid duplication and offer insights), and to put our work products in common areas so that others can re-use them and build on them.

Indeed, tools such as Yammer encourage WOL, by prompting you with the question "What are you doing today?"

However there are a number of ways in which WOL, taken superficially, can go badly wrong, as shown by a case study at the end of this post.

Here are 4 pitfalls you need to address.

1. WOL must address demand as well as supply - Pull as well as Push.

Although WOL greatly increases knowledge sharing, the goal of Knowledge Management is not Knowledge Sharing but Knowledge Use. KM is ultimately about giving people access to better knowledge that will solve their problems, and setting a culture whereby they want to find and use that knowledge.

Knowledge re-use requires knowledge demand, and not just supply.  People need to be actively seeking and asking, as well as actively telling and sharing. Any unbalanced market, where supply exceeds demand, leads to a crash in the value of the commodity (in this case, knowledge). Conversely where demand exceeds supply, the value of the commodity rises. Demand stimulates supply; supply does not always stimulate demand.

WOL can fail when it becomes only a mechanism for Telling - telling people what you are doing, telling people what you have done - a supply mechanism only.

If WOL is going to work, it needs to refocused as Asking Out Loud, or Questioning Out Loud. A sharing culture needs to be replaced by (or augmented by) an Asking Culture.  In-house Yammer should be asking "What do you need help with today?". This way WOL becomes a demand-side mechanism.

Remember Shell's maxim of "Ask, Learn, Share" and remember that they prioritise them in that order.

Don't replace "Ask, Learn, Share" with "Tell, Tell, Tell"

There is often an assumption that telling what you are doing, and sharing work in progress, tacitly invites commentary, and is a proxy for seeking and asking. If you are doing something wrong, the assumption is that someone will correct you without you having to ask. The reality is determined by culture, and in many cultures around the world people hesitate to correct someone unasked, or to offer unsought feedback.  If you want commentary then Ask, don't just Tell.

2. WOL creates "just-in-case" knowledge, not "just in time".

WOL, applied incorrectly, becomes a set of answers looking for a question. You narrate your work "Just In Case" someone is interested. You store your work products "Just In Case" they are of use to someone.

However we know that KM is most effective when it operates through "Just In Time" rather than "Just In Case". People don't know what they need to know, until they need to know it (this is one of the demand-side principles of Knowledge Management), and when they need it, they need it NOW.

There are cases where Just In Case knowledge is valuable, namely when you are sure that such a case will recur, and that people will come looking for the knowledge. In situations like this, knowledge is "because we will" knowledge. Such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work produces will not be as useful.

3. Noise drowns out signal.

Imagine you are one of 100 people working out loud. Your piece of knowledge might be useful to one of those people. For the remaining 99%, it is noise.  You are putting the onus onto the user to filter out the signal, rather than removing the load from the user. Given that re-use is the biggest challenge in KM then anything that adds barriers to re-use is counter productive, and that includes the noise to signal ratio.

Unwanted knowledge is of no value - it is just noise (until the time when it IS wanted, of course). Wanted knowledge - sought knowledge - is of immediate value.

You can reduce noise by working out loud within communities of practice.  This is a way to focus your sharing - narrating only within a community of people doing the same sort of work as you, who therefore are more likely.  Even better, reduce noise by sharing what is essential and useful.

4. What you are doing, and what you have produced, is not the same as what others should do or produce.

Until you have finished a piece of work and tried the result in practice, you don't know whether what you did was the right thing to do. Any piece of work - a bid, an intervention, a project, a product, a business plan - can only be judged by whether it achieved its results. Therefore narration of work on its own is of little value to others, just as sharing work products is of little value to others. What you should be sharing is the results of reflection on your work; the things you should have done, the things you would do if you were to do it over, and the things you recommend others do.  This is more like coaching out load than working out loud.

And beyond this - if knowledge is, as described above "because we will" knowledge, then such knowledge should be synthesised into knowledge assets tailored to the needs of the user. Just creating compilations of work products will not be as useful; you end up with a mass of material to wade through, some of it out of date, some of in contradictory, some of it wrong.. If knowledge is important, then it requires some investment in synthesising results, insights, and the current best work products, in order to create the best resource base possible for the knowledge user.

When WOL goes horribly wrong.

Here is a story about a company that takes the ideas of "Public sharing" to excess. They were not strictly Working Out Loud, as much of what they shared was finished product rather than work in progress, but their Knowledge Management approach was very much "Tell, Tell, Tell" with little evidence of Learning and no evidence of Asking. They were "Telling out loud" what they had done.

This company had introduced
  • A blogging platform for all staff
  • Incentives for blogging and publishing. Directors and other senior staff were taking the lead, people ranked each other's blogs, and star bloggers were given prominence and recognition. Blogging was therefore pursued enthusiastically
  • A platform for publishing work product articles, again linked to recognition. 
  • Many blog posts were repeats of these articles 
  • A wiki platform. Much wiki content was repeated on blogs, or duplicated the contents of articles. There was no synthesis of knowledge on the wiki; no creation of Knowledge Assets.
  • A discussion forum, used for announcements. Many of the posts were notifications of new articles.
  • A microblogging platform, mostly used for narration, and for notification of new blogs, articles and wiki pages 
Activity levels were enormous, driven by powerful incentives. The re-use rate for this mass of material was miniscule -  less than 0.7%.

The net cost to this large organisation was about 42 mandays per day in publishing, checking, reading and maintaining material that will never be re-used, and will seldom be read. There would be big savings in abandoning the system entirely.

This company was fantastic at knowledge sharing and lousy at knowledge re-use. They "Told out loud" to deafening levels, and lost value as a result.

What to do instead

  • Ask out loud and Question out loud, so others can Answer out loud. Aim for a culture of asking. Ask before doing. Fill in the knowledge gaps that you are aware of before you start your work, then ask others whether there is anything else you are missing.  
  • Share your knowledge and insights, not your actions and products. Reflect in your teams about how effective your work was, and share the results of the reflections. Share what you think others should know, not what you yourself did.  Coach out loud.
  • Aim for "Just in Time" knowledge and "Because We Will" knowledge, rather than "Just In Case" knowledge.
  • Narrowcast your questions and your knowledge to those most likely to need to know, within the relevant communities of practice.
Above all, avoid the pitfall of "Tell, Tell, Tell"


Anonymous said...

Hi Nick - I'm taking this as a cautionary note on my rather bullish blog last week on the value of working out loud :-)

And some good tips at the end of the post - particularly on the need to question out loud and coach out loud (which means in both cases you get to share the process and the insights they generate more widely).

One comment however - if I'm working out loud it's not mainly to inform others or to share "just in case" knowledge. The main benefit for me in working out loud is finding other people who are interested in what I'm doing and who might be able to provide inputs or share relevant practice. It also gives the people who my work is intended to help a chance to let me know how I'm doing and what they need. Working in an organization where there are often overlapping uncoordinated initiatives it's also a way of letting people know what we are doing so they can make common cause rather than go it alone - and perhaps more cynically they can't then say we didn't tell them or give them a chance to join us.

It could indeed be a challenge if everyone started working out loud and we were drowned out by noise and we would need better filters. However in my workplace we seem very far from that and I'd prefer more noise to deafening silence.

Nick Milton said...

Hi Ian - its not just your blog post - I have been brewing this one up for a while.

Definitely there is value in working out loud as a means of identifying potential duplication, but if you want inputs and advice, would it not be easier to ask?

Anonymous said...

When I share things internally and I'm looking for inputs and examples I do usually include specific asks - but I think explaining what I'm doing rather than just asking a question makes any exchange more valuable and inputs more directly relevant. Similarly explaining how inputs have been incorporated (or even why they haven't) also shows better how inputs are valued and helps close the learning loop.

Anonymous said...

These are all useful points. Thank you.

I would love to have the problem that people are sharing too much information about their work. Terrific! Then I would refer to your post and make some meaningful adjustments.

For now, people share in email and meetings if then. To create the KM programs you rightly promote is a bridge too far for most organizations and their employees. Working out loud (sans the absurd metrics used in the case you cited) is one possible onramp to the more sophisticated, valuable KM practices you write about.

One more comment is that working out loud provides immediate feedback and connections that fuel intrinsic motivation. It's a lot easier to nudge people towards sharing when they can quickly experience the value to them as individuals.

I love your work and hope to apply it some day. Getting people at my firm to work out loud makes that much, much more likely.

Nick Milton said...

There are four ways in which you could structure your "request"

1) Can anyone advice me on this?
2) Can anyone advice me on this? Let me explain why I am asking ...(add details of what you are doing)
3) I an doing this. Has anyone done this before and can offer advice?
4) I am doing this.

1 and 4 generally fail, and any approach to WOL that takes option 4 is plunging into the pitfalls described here. Options 2 and 3 are far better, and personally I prefer option 2 as it leads with the question.

Nick Milton said...

PS Ian I get your point about "things are so quiet, a bit of noise is preferable to silence" but I would still suggest your noise be question-lead from the start. If you think its hard to develop a supply of knowledge, its 10 times harder to develop a demand. Start by modelling what you want to see - a desire to learn rather than a desire to tell.

Nick Milton said...

Thanks John.

Here's an exercise for you. Look at what's coming out through "working out loud" at the moment at DB. Count the proportion of interactions/posts/messages that are "Push" - i.e. are a statement, a link, or a description of what someone is doing. Count the proportion that are Pull - i.e. are a request or a question.

To have a sustainable value adding situation, you really need more pull than push, ot at worst a relatively equal balance. If you have more than 80% or 90% Push you have fallen into one of the pitfalls mentioned here.

For a great illustration of "Pull-based WOL" see the video embedded in this post

Anonymous said...

I did the exercise, we're not close to having more pull than push, and I think either you're wrong or we're talking about wildly different things. :-)

Rather than launch into a long comment, here's a question to help me understand better.

People's use of Twitter is heavily biased towards push. In many ways it's an extreme example with lots of noise. Yet despite that, many people get a lot of value from Twitter including discovering people and content. Are you saying people should wait for a question before they post on Twitter?

Thanks for entertaining the question!

Anonymous said...

"1 and 4 generally fail" Any data on that? :-) My own experience is that 1 and 4 work quite well in eliciting contribution from others, including people that aren't in my network. This is particularly true at work as opposed to on social platforms. Now I don't think it's because I'm particularly awesome or influential. :-) We have dozens of "working out loud profiles" at work where individuals find "1 and 4 work" over and over and over again.

Either our experience just happens to be wildly different or we might be talking about different things(?)

Nick Milton said...

Some data on #4 in this blog post looking at Linked-in behaviour which shows that the vast majority of posts that lead with a statement generate no discussion. Those which lead with a question are more successful at generating discussion, and the discussion within the dataset which proved most long-lived both led with a question and was actively moderated by the asker.

No data on #1 other than long experience of people asking short unqualified questions and sparking a series of unrelated answers (people answering the question they want to answer, which doesn't really help address the original problem). Hence my suggestion to "question the question" here. When we offer training to CoP facilitators, we spend a lot of time on "how to ask a good question".

Maybe we are talking about different things, but lets keep exploring, as in my experience a Push-heavy system, although very active, may not be delivering what you need it to deliver.

Do you have any data of your own to share?

Blog Archive