Nancy was here. We know this because of the blog, Jeanne Walker’s Flickr stream and also the damn awesome events that Nancy ran.

• The Sydney Facilitators Network gig was excellent. As much as the world of facilitation drives me up the wall sometimes (“tell me what you think”), that crowd are up for anything. And the group and Nancy just fed off each other’s energy.
• The morning of the Sydney online communities gig was great. We had a small number of people from a reasonably homogeneous background and we just sat and chatted about important stuff.
• The Sydney afternoon just didn’t quite gel until towards the end. We had a very diverse bunch of participants and on reflection Nancy & I tried to overdesign the session. Sometimes less is more.
• The KMLF meeting and subsequent Chinese restaurant nonsense was good. In some ways more restrained than the Sydney Facilitators but still powerful.
• The Melbourne morning and afternoon online communities sessions were just great. The participants were totally engaged, the format gave people just enough structure and at the end we had to forcibly eject some people to make our planes. One point of contrition – I spent too much time fiddling with the video camera & pottering round the edges. Need to work on being more present.

Thank you to everyone who made this happen! 2010 will be interesting indeed…

I want to get Nancy back over here in 2010.

From the lack of posts here, it may seem that I’ve been slack. In fact I’ve been busy with paid work and the public outings that I have done haven’t necessarily involved presentations & notes. I thought I’d just note what these were:

• Sharon McGann & I ran a session at the Sydney Facilitators Network in August entitled “Living a Sustainable Life“. We wanted to explore that sustainability means beyond just recycling your potato peelings and people seemed up for it.
• I ran a session at Oz-IA 2009 using the Straits Knowledge Methods & Culture cards & also Arthur Shelley’s Organisational Zoo cards too. I enjoyed it – although the World Cafe card generated much angst (nay, derision) from the information architects assmbled.
• I was called in at late notice to run a session at the Ark Group’s Collective Intelligence event. I ran a reverse brainstorm: How can we ensure that our organisations do not use the collective intelligence present in them?
• I was a stooge collaborator with both Patrick Lambe & Cory Banks for their respective sessions at KM Australia 2009.
• I did some facilitation-y stuff with the joint NSW KM Forum / Sydney Sharepoint User group love-in. More here.
• I will probably be at the Tonkin Corporation’s Knowledge Management & People Development Conference next week, where I will be revisiting one of my fave topics.

If you enjoyed any of these events and would like to catch for a coffee then don’t be shy – drop me a line!

I’ve not done a lot of presentations recently. I’ve preferred to do something a little more “interactive”. So when the call for papers came out for actKM 2009, the last thing I wanted to do was a paper. Instead I was interested in exploring the edges of knowledge management. I wasn’t really sure how to do that but I had something in the back of my mind from the Mindell’s process work. This can involve exploring psychological “edges” using physical movement and other techniques. So I dipped my toe in the water and sent out a question to the actKM email list concerning disciplinary boundaries. The response I got back wasn’t particularly helpful and this indicated that I couldn’t do anything too confronting.

Then the thought struck me. Get the participants to draw maps. So that’s what I did. Six tables, six maps. In each case I asked them to map out knowledge management as an imaginary nation and then identify who else this nation might interact with (through trade, war or something else).

Some comments:

• “Finance” crops up as an ambiguous/hostile power is a couple of maps – and as the “Resource Shark” in another.
• Some of the maps are a little idealistic – how things should be rather than how they are.
• One of the maps positions KM’s neighbours as process-based – e.g. six sigma, BPM, Lean, TQM.
• One group had the occasional KM guru on the map – but up a mountain separate from practitioners.
• Technology is often mentioned but rarely given centre-stage.
• One group started identifying KM’s neighbours (e.g. Project Management, Organisational Development) without any prompting but others took a more KM-centric perspective.

What do you see?

Here are the slides & notes for a presentation I gave last night to the Sydney Sharepoint User Group on the topic of Sharepoint & Taxonomies. The presso is basically in 3 sections.

Slides 2-14: Introduction to Taxonomies

I started off by asking the audience how they might group wine together (or classify it) – the answers included colour, variety, vintage, region, bottle shape, sweetness. Then we had a look the way a wine shop orders them. The point here (apart from giving Brendan a bit of a plug) is that there are many ways to group things – and some of the most useful ones for users/consumers are not necessarily obvious from the object itself. Hierarchies & facets were then discussed via the systems of Dewey* (Dewey Decimal) and Ranganathan (Colon Classification) and some real-world examples.

The “we don’t need structure, we just need search” comment also got a mention – which resonated with a few people in the audience. The answer(s) to this include: i. taxonomies & metadata can make search better & ii. taxonomies & informtion mapping are about more than just findability. We ended that segment with Patrick’s taxonomy map.

Slides 15-25: Taxonomies in Organisations

This section could be represented by a 3 x 3 matrix – who is involved in taxonomies vs what they are doing. I split the “who” into 3 broad groups:

• Experts – and here I mostly mean taxonomy experts but it could also be subject matter experts.
• Machines – language processing / semantic software (but this could also include process automation software as well).
• Users – general people who just do, y’know, stuff.

You need to involve all 3 groups but each has their strengthens & weaknesses. And then I tackle 3 broad activities:

• Building a taxonomy (or folksonomy or ontology).
• Applying terms to documents.
• Consuming – which in this situation means doing things with documents based on their metadata. This could as simple as someone searching & finding something or some fancy processing based on an ontology.

Slides 26-37: Sharepoint

Sharepoint’s basic methods of managing metadata are:

• Content Types
• Site Columns
• Lists

This is a good start but Sharepoint has three main deficits:

• It doesn’t handle hierarchical relationships between terms in lists well – it treats each list as though it is independent.
• Metadata can easily get caught in site “islands”.
• It doesn’t do any of the fancy machine classification.

A range of third-party vendors have arisen to meet these needs – each offering very different functionality at varying costs.

*I don’t know whether to be offended or impressed by Dewey’s classification of Australia with extra-terrestrial worlds.

Fast Break was at Vibewire and featured 5 of us talking about Creativity, Connection, Collaboration, Commercialisation & (drum roll please) Conversation.

Here are the notes to support the slides (which I didn’t really use):

• A key challenge to innovation is noticing. Or the willingness to be surprised.
• Conversation plays a key role here – in conversation we can allow ourselves to be surprised.
• Lovely quote from Theodore Zeldin’s book Conversation: The kind of conversation I like is one in which you are prepared to emerge a slightly different person.
• Finally, 3 suggestions to improve the process:

1. Find people who are not like you to converse with. The more alien, the better.
2. Listen as well as talk.
3. Do something about it afterwards.

This was a presentation that I gave at Wiki Wednesday on 6 May 2009. Here are some notes:

1. The style of these slides is a blatant steal from Jye Smith’s current presenting style. Jye – sue me.
2. Slide 2 is a drawing that appeared in an edition of 70s punk fanzine Sniffin’ Glue. The metaphor here is that social software is basically punk rock and that punk emerged in opposition to the world of prog rock. Many Flash-based web sites feel like 10 minute guitar solos – i.e. technical masturbation.
3. You don’t need to be able to code to create a web site with a wiki. You can just do it.
4. Slide 4 is a picture of Indian tea cups. Some are made of clay. You drink them and then throw them away. They are designed to be disposable. They have a built-in obsolescence. On the other hand, plastic cups persist in our environment. Many corporate information environments seem to be full of trash that won’t go away.
5. We need to design our environments with this obsolescence in mind.
6. Example 1 – built very quickly, iteratively and now no longer used.
7. Example 2 – built very quickly to prototype an idea.
8. Example 3 – built very quickly, adapted and still in use.
9. 5 simple conclusions. The last point seemed to excite most interest  so the discussion focused on information lifecycle issues rather than the rapid prototyping thing.

This was a short presentation that I gave as part of the NSW KM Forum Future of Conferences event (background & presentations). I was talking about feedback.

The 3 questions that I asked everyone at the start were:

• Who here likes getting positive feedback?
• Who here likes getting negative feedback?
• Who here thinks that feedback is important?

Then I talked a little about the rationale behind the Rate My Speaker experiment. And then I talked a little bit about Twitter, with specific reference to this experiment by Andrew McAfee.

My final three suggestions were:

• We have to get better at giving feedback.
• We have to get better at receiving it.
• Feedback is not an end in itself but a platform for co-creation.

UPDATE: The video is now available courtesy of Oscar Nicholson.

I gave a talk to the NSW Chapter of the Institute of Management Consultants on social software (slides below).

The core of the talk was simple: social software is not complicated technology (although it may be complex), you just have to work out what you’re using it for. As it’s social software, that thinking has to involve a who and a why. You need not be limited by that first thought but you need a somewhere to start. In working out your starting position, it’s also important to think about the whether you’re just broadcasting or whether you’re after a conversation – as Denis B Hancock’s 2×2 sketches out very elegantly* (he’s talking about Twitter but he could be referring to any form of social software).

*Presenting to management consultants, I was contractually obliged to use at least one 2×2.

As promised, here is the post that support the workshops that I ran today at the E2EF event. Many thanks to Ross Dawson for inviting me and everyone who participated. The topic was policies and guidelines. There are four questions that need to asked here:

• Why do we need social software policies in the first place?
• How should we develop those policies?
• What should be in them?
• What next? This question deals with deployment and monitoring.

Why do we need policies?

Things go wrong and people do things they regret. Public mistakes with social software tend to be splashed across the newspapers. Mistakes inside organisations are more easily covered up but they can still result in lasting damage. Things that can go wrong include:

• Individuals fighting destructively in public. There should be nothing wrong with constructive debate but arguments and abuse can alienate people and ruin relationships.
• Individuals inappropriately releasing confidential information.
• Incorrect information being shared and acted upon.

Rarely are these acts carried out maliciously. Mostly it’s due ignorance and thoughtlessness. Policies should remind staff of the behaviour that you expect of them.

Policies also play another role – which is placating managers worried about social software deployments. The things that can go wrong listed above are often voiced as common fears by managers. Enterprise 2.0 is all about changing the balance of control and initiative in an organisation and this can scare people. Good policies reduce that anxiety.

How do we develop these policies?

How you develop your policies is as important as the policies themselves:

• Many hands make light work. You have hired smart employees. Enterprise 2.0 is all about collaboration. So why don’t you get your employees to help draft what these policies should be. IBM used a wiki to allow its bloggers to draft their own guidelines (which you can view here). Senior management can reserve the right to make changes of their own – either while everyone else is drafting or at the end. Of course this means that if you’ve involved people up front, you should think twice about throwing out everything they’ve done.
• Use what you already have. You should already have policies around internal comms, privacy & confidentiality, IP usage, etc. So use ‘em as the foundation for your social software policies. There should be no inconsistencies between these – otherwise people could get into trouble while trying to do the right thing.
• Use the tools. Wikis are very good tools for collaborative policy drafting.

What should be in them?

This may be the easiest bit. There are three areas that you will probably cover:

• Be sensible. If the wiki says “work in progress” do not assume that the information in there has been vetted. Use your judgement in what to post about.
• Be nice. Don’t abuse people. Use your own identity. Be constructive.
• Be legal. Don’t breach copyright. Don’t break confidentiality.

Have a look above at the IBM example or the ones for Intel & Powerhouse Museum. Most examples are about public use of social software but theycan be applied to internal situations. Beth Kanter has some sensible comments as does Joitske.

What next?

You now have your policy. If you have involved your staff earlier then this will make deployment much easier – because they will already be engaged. There are other things you may consider doing:

• Use specific examples in explaining the policy to people.We like the concrete above the abstract. “Andy posted dirty jokes in the comments field of Stacy’s blog. They are good friends so Stacy didn’t mind. So why might this have been a bad idea?”
• Focus on discussing borderline cases. Employees will generally know that selling confidential information to a competitor is bad but may need some help establishing where the boundaries are.
• Include a section on appropriate behaviours as part of any technology roll-out. If there is no formal training to be provided then at least flag the policy when staff first access the tool.
• Incorporating a session on the policy in training for new hires.

You’ll need to review your policies over time so build in timeframes for doing this (e.g. after a month, after 3 months, then every year). We give software releases numbers so why not policies?

An important idea that emerged out of today’s discussions was the importance of giving positive examples (& role models) not just negative ones. You don’t want to snuff out the inspiration.

That’s what I think. What do you reckon?