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:
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’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.
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:
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:
Find people who are not like you to converse with. The more alien, the better.
This was a presentation that I gave at Wiki Wednesday on 6 May 2009. Here are some notes:
The style of these slides is a blatant steal from Jye Smith’s current presenting style. Jye – sue me.
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.
You don’t need to be able to code to create a web site with a wiki. You can just do it.
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.
We need to design our environments with this obsolescence in mind.
Example 1 – built very quickly, iteratively and now no longer used.
Example 2 – built very quickly to prototype an idea.
Example 3 – built very quickly, adapted and still in use.
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.
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.
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.
I made it to the second day of this conference on Information and Knowledge Policy Development this week. I was offering a session on Social media policies (Slideshare seems to be working now):
Notes:
Slides 1-4: This was the fun part. Participants discussed their responses to the situations on each slide in small groups and then shared their opinions as a whole. The debate was lively and I was impressed by the range of reactions to the first two situations- some were cautious, some gung-ho. The response to the final one was pretty unanimous – “NO!”
Slides 5-10 provided a break-neck overview of the social media space.
Slides 11-23 were simply examples (good, bad and in between) of different uses of social software, mostly by governments and mostly in the public space.
Slides 24-29 were the different approaches to public servant policies to be found in the US, UK, NZ and Australia.
Slides 30-39 listed 9 issues that you need to think about in establishing your policies:
Transparency – both in terms of the behaviour you want your staff to exhibit but just as importantly, you must be transparent in how your develop your policies with your staff – e.g. IBM developing a public blogging policy with its bloggers using a wiki.
Honesty – nuff said (I hope).
Pollination – with any luck your ideas, words, pictures and sounds will be carried far and wide and outside your span of control. Be prepared for this to happen – and encourage it where you can.
Links (on several levels) – the web is a link-rich environment. You should be creating and encouraging links between people & people, people & things, and things & things. These links not be perfect but messy.
Security – understand security risks but do not let fears about security become an excuse for inaction.
Privacy / Identity – encourage your staff to actively manage their online identities and to respect the privacy of themselves and others.
Archiving – think about the lifecycle of the information your social software activities will create.
Choice – don’t overwhelm people with too many tools all in one go. The right answer to the request to use a new tool is not always “yes” (of course, neither is it always “no”).
Creative Commons – it could be time to rethink your approach to intellectual property ownership to promote cooperation, collaboration and other good things.
