When an icebreaker isn’t just an icebreaker

I was invited to present a workshop as a guest speaker for a team off-site, recently. It was an express introduction to knowledge management and the group I presented to were enthusiastic about knowledge, even though they hadn’t yet implemented any KM programs. This particular group of people are managers in different roles across the IT operations team. There are a couple of challenges for them to work with: their team is distributed around the country, and they work in a traditional industry that could be subject to fallout from an ageing workforce.

When I do a knowledge management workshop, I like to start by getting everyone’s name and job title. There’s nothing new in that, and it’s more helpful to me than them, especially when they already know each other.
But I also keep three columns of numbers.

The first is how long each person has had that specific role; the second is how long they’ve worked in that organisation; and finally, how long they’ve worked in the same industry—that could be IT, or the business of what their organisation does.

I like this opening exercise because, not only does it give me the cues I need to remember who’s in my workshop, but it demonstrates the amazing amount of collective experience that’s in the room with me. That industry experience, together with the years of experience in the context of the organisation, informs the decisions each person makes in their role every day.

This realisation really highlights the potential of knowledge sharing in an organisation like this one.

How to interview your experts

Today’s post comes from Michael Domanski and Sean Murphy. Michael is a software developer and Sean is an entrepreneur with a history of business development and customer support. Together, they are bringing tools for knowledge management to small teams. Learn more about Knowledge Flow.

What’s the most unnerving thought when interviewing a high profile expert?
Just imagine how depressed you would be after securing an interview with a subject matter expert and then conducting an interview that is a mix of stuttering and banal questions. I had tons of angst myself when I started conducting interviews. It’s not easy to interview an expert, mainly
because of the depth of their knowledge. It gets even harder when you realize just how precious their time is. To make my experience even more stressful, I knew at some point some of those people may become my
customers. Thus, I not only needed information, I also needed to make it look as if I knew what I was doing.
Since there’s little information (very little) about this subject on the internet, I decided it may be a good thing to share
some lessons learned. Let’s jump in.

8 tips to guide you through interviewing your experts

1. Research the subject matter and people you want to contact
Your interview always should have a main subject. E.g. if you were to talk to a SEO expert on the matter of recent
changes to Google algorithms, research as much as possible on your own. This background will enable you to
ask questions that are informing to your readers and provide new or niche insight into the subject. Also, pay
attention to the background of the person you interview. Ideally you want to have a list of people to interview that you
have almost personal relation to.

2. Rules of engagement
I usually contact people via email. It’s almost a given that experts get a ton of email every dail. At this stage you
should know them well enough to write an email that will interest them enough to contact you back. If you don’t
think you can write a good email, read “Writing that works” by Kenneth Roman (make sure it’s the 3rd edition). Do
write a personal email, e.g. when I wrote to Adii Pienaar from WooThemes, I’ve included a small personal hook,
which got a brief discussion over email and a comment: “Nice email, got my attention”.

3. Draft an interview agenda
You know the subject, you know the person you’re going to interview. Now, with your target length of time for the
interview in mind, draft an agenda of the key items that you want to discuss. I usually write it and then review it with
my co-­interviewer. We discuss it and then send it to the interviewee in advance so that they can prepare. My advice
is to always have someone have a look at it.

4. Have a co-­interviewer
The main reasons I can think of for having help is:

  • Fluidity. If you are out of questions for the moment he can take it from there.
  • Notes. I added tip on taking notes and having help makes it much easier. One of you asks the
    questions, one analyzes the answers and takes notes.
  • Brief and debrief. You can discuss the agenda and discuss what you have learned.

5. Prepare the environment
There are two types of settings for an interview. First type is “in person’ interview. It has the obvious benefit of you seeing the person you’re talking to. This gives you more clues about the feelings someone can have about the subject. On the other hand, those types of
interviews are expensive. They require you to secure a proper space and time to get there. You should never do an
interview in a space not private enough. I personally don’t believe in “coffee shop” interviews. The list of
distractions in such places is very long and you want the undivided attention of the person you’re asking questions.
Second type is the remote interview. Skype and gotomeeting are two most used tools for this kind of interviews.
While the interview can be much harder, ­­you can only hear the other person and see facial expressions or body
language­­, it has some logistic advantages. The whole setup is dirt cheap and the time spent on getting there is exactly 0 seconds. It’s also very useful when interviewing people over long distances.

6. Take notes
Take note of key words and phrases that your interviewee uses and pay attention to any term they repeat. Try to
write down things as they’re being said. You can draw your conclusions later. This is easier if you work with a
partner. ­That way, you won’t have to worry about losing the thread of conversation (believe me, it’s hard to take good
notes and follow the conversation at the same time, pay attention to how a good lecturer structures their

7. Keep it on course
If you said the interview is going to take 30 minutes, be ready to end a few minutes before. A good guide is the
subject’s energy and engagement. If they seem happy, you can go over the promised time. If they’re showing fatigue,
try to wrap soon. It’s important to avoid data overload. ­If you ask too many questions, it can be hard to process them coherently. Having a planned agenda, with some questions and a general thread of thought will help you a lot.

8. Summarize
In case you got something wrong, at the end of the interview be ready to show or read a short summary to your
subject. While this is not as good as a thought-out follow up, it gives you the confidence, that at a high level, you
have the same view of the problem as the expert you’re interviewing. This is the end of the interview, but this is not the end for you and your partner. After the interview you debrief on the
situation, what you have learned and what you think is important to take note of. I also try to mention any
conclusions that seem obvious to me and that I drew based on the interview.

After the debrief I work on the formal summary of the interview. This may seem like a lot of work (and it is) but it’s
very significant since:

  • it enables you to confirm your conclusions with the expert
  • it makes you think hard to create a coherent picture and wrap it into words

Personally, I believe this is a step you should never omit. Even if you eventually end up not using what you have
learned, you will have a good notion of why it’s not useful. You will also be able to follow up with your subject and, if
you collaborate on it with your partner, you’ll be confident you haven’t overlooked obviously important information.
Fear of missing important information or the nuance of an insight are two reasons why I always email the
summary to the interviewee. Most experts are used to not being understood completely right away. Because of that,
most of them will read and correct what you got wrong. This is very similar to taking an exam and submitting your
answer. It’s crucial to perform this step, since you are going to base your action, or lack of it, on the conclusions
you deduced from the interview.

If you’d like to read more about conducting interviews, I recommend starting with this blog post. Having that in
mind, the set of rules outlined above is solid enough to get you through most interviews with very good results.­ I’ve been
using it now for two years, and it’s been tested by Sean (for a much longer period of time). Yet we’re still
curious what you think of it, so don’t hesitate to send us your feeedback.

When documentation is against the religion

Last week’s KM Australia congress in Sydney had a different vibe to last year. (Here’s the storify.) There were quite a few different faces from 2012, a few of the same ones, the weather was better. The room configuration was different, and maybe that’s all it was, but a small part of me thinks it was because one of the presenters was a chief technology officer. At last! A knowledge management case study from an IT executive.

James King started by explaining the nature of his organisation and the DevOps environment that his team works within. Of course, the Agile Manifesto says developers value “working software over comprehensive documentation”, and that’s where James got the first objection to his plan for better documentation to avoid rework. His response was that the Agile Manifesto is a piece of documentation in itself, so clearly, some documentation has value.

And so, the story continued with the introduction of Agile tools, like storyboarding, to the product support and knowledge management process. Instead of documentation being engineered along with releases, it was produced on demand through the normal support transactions. Without mentioning the words Knowledge Centred Support, James was in fact describing a simplified implementation of KCS, which I confirmed with him afterwards.

Just this morning, I saw a tweet that reminded me of James’ presentation.

You see, the great thing about KCS is that it accepts knowledge has an imperfect nature. It has built-in mechanisms for improving knowledge on the fly. Indeed, why spend hours over-engineering documentation for software that frequently changes and may never be read in full?

itSMF Knowledge Café

Melbourne laneway café

Last week, the NSW branch of the itSMF held a knowledge café for the first special interest group session of 2013. Paul Bodie and I facilitated the session together with a group of 18-or-so service management professionals. We explored both the Gurteen approach to knowledge cafés and the original version that was developed in the 1990s.

For our Gurteen session we formed three tables—if we’d had a couple more people we would have split into four tables of five—and we began by discussing a single topic: The most successful service improvement programs include…

We had two table changes, each after 10-15 minutes of conversation, where 2-3 people would shift and continue the topic discussion with others. The topic discussion concluded with a group conversation where participants shared insights that surfaced during their smaller group discussions. Executive sponsorship of improvement programs was a key theme but we also identified that our topic may have been too broad. Taking notes was discouraged but a few of us couldn’t help ourselves. 😉

Our second session was in the style of a World Café. Again, we had our three tables, but this time, each on had a different question to explore.

1. What worked well and what could have been improved in the previous knowledge café process?

2. How could you use the knowledge café in your workplace?

3. How could a knowledge café session leverage social media?

We ended up having a knowledge café about knowledge cafés. How meta. 😉 Lots of interesting threads emerged, like is it actually a knowledge café if you involve remote people through social channels? And the answer is no, really, because a knowledge café is all about the comfortable, cosy setting drawing out the tacit knowledge related to the question being asked. I could call this frictionless knowledge transfer in one respect, because a layer of technology can add awkward delay issues and it strips emotion and tone.

A café-like setting (or a pub atmosphere) isn’t available in most workplaces, so the ability to take this sort of exercise off-site was a popular preference.

We had participants suggest that a timer be displayed so we would know when the end was nearing so we could be sure and say what we might not have got around to saying yet. We also thought providing people with the topics beforehand would be helpful, as well as giving them the opportunity to post their own preferred topics anonymously.

It was a great afternoon and I think everyone took something away from it to hopefully adapt for their own teams and environments.

7 Ways Self-service is like a ShamWow

Like late-night TV, the mind can go from the sublime to the ridiculous when it’s dark and quiet. And so here I am with 7 reasons why self-service forums are like a ShamWow.

1. ShamWow’s in your face around the clock

Just like those ads, self-service forums can run around the clock. And if you have a thriving user community, those customers posting questions to the forums can get anecdotal advice and crowd-sourced help while you’re asleep or watching TV.

2. ShamWow is portable

That’s right the ShamWow can go anywhere. Keep one in the house, the car, the boat, the RV. Take a look at Mary Meeker’s 2012 Year End Update. Here’s just one slide that proves escalating mobile use. There’s plenty more in the full report.

Smartphone adoption

Mobile-friendly self-service portals give customers access to support wherever they might be at the time. Your entire knowledge base could be in their pocket.

3. ShamWow just does the work; why work twice as hard?

Why waste effort on solving issues that have been solved before? You’ve got knowledgeable users, so capitalise on that. You’ve got knowledgeable staff, so capitalise on that. Self-service puts those answers in front of the people who need them, at the time they need them, without you having to hunt those answers down again and again.

4. Once I got a ShamWow, I couldn’t live without it.

Self-explanatory. But if you need convincing, listen to this webcast of Peter McGarahan talking to William G. Purcell, from Paychex, Inc. He’s a big believer in KCS and self-service.

5. You’re gonna spend $20 on paper towels anyway; you’re throwing your money away.

How many of you have a self-service portal as part of your support toolset? How many of you have left it sitting empty and unused or outdated and unused? You’re paying for it, anyway; put it to work.

6. ShamWow is great for everyday use.

Self-service fills a range of support needs—FAQs, a place to collect and prioritise feature requests, customer engagement, standard troubleshooting and how-tos.

7. ShamWow sells itself. It lasts ten years; a sponge lasts a week.

Self-service forums enable you to retain and reuse knowledge gained from your support interactions over and over.

Want more? Here’s the ShamWow guy himself. Watch the video and see if you can come up with more. In the meantime, I’m off to buy a ShamWow.

Thanks to @sitare21 @PeterJLijnse @rfsis1 and @StuartRance for the late night twitter banter that inspired this post.

Taxonomies and Folksonomies

Knowledgebird word cloud

I’ve observed a discussion on the twitters lately dissing hierarchical categorisation in favour of tagging. The conversation was around incident management, but I think it’s worthy of expanding on in a broader knowledge management sense. It’s well-known that I like it both ways, but this rage against the machine* is misguided and potentially ineffectual. (* Where machine represents formal taxonomy.)

First of all, what is taxonomy and folksonomy?

Folksonomy is a way of describing crowd-driven categorisation of information. This flat, loosely-structured form of classification via tags became more widely used around the time of social bookmarking sites like delicious becoming popular.

Taxonomy, conversely, is a formal, hierarchical method of classification. It recognises that cheddar is a sub-class of cheese.

The case for taxonomy

Folksonomies are surely charming. They’re compelling and serendipitous; they capture somewhat of the collective’s personality. As communities of users develop their own naming conventions, folksonomies capture symbolism from the meme du jour, variations and typos, too. Depending on the reason for retaining a knowledge exchange, maybe that’s just fine. Go back to the strategy and consider the goals of retaining and maintaining whatever kind of knowledge you might be dealing with. If all you need is some run-of-the-mill search engine logic, then it’s all good. And, if there’s some rules-based automation available, tags can add some powerful efficiencies.

One argument might be that the artificial intelligence of search engines powerful and over time, with further advancement perhaps, search functionality will be able to connect the dots of folksonomies and draw accurate conclusions about the information you want to find. But in mimicking human thought and our fuzzy logic, search will only ever provide what you probably want to know—based on like terms and popular votes. Like I said before, maybe that’s good enough, but it just isn’t scalable.

Remember when we used to have to defrag our computers? You know… before we all got Macs? Computers like order. It helps them find the files quicker. When the Singularity comes we might still be charming, folksy humanoids but the machines will have us all completely catalogued and ordered, and functioning in exactly the way they expect us to and in the most efficient way possible.

Taxonomies might feel stuffy and dictatorial, but it makes for efficient searching, sorting and reporting. The common language borne from taxonomy is a basis for understanding and collaboration, and they CAN be fluid if reviewed and communicated regularly.

And like I’ve said before, they can live in harmony together. WordPress is just one system that allows for both hierarchical taxonomy, in the form of post categories, and less-structured folksonomy, in the form of tags.

Vive la différence!



The impact of social media on knowledge management

Last night’s NSW KM Forum was the last for the year, so they finished things off with a knowledge café on the topic of social media. Is this the end of KM as we know it or its second coming? The knowledge café involved discussion around three questions on the topic, with one question at each table, and a small group discussing each question. After 15 minutes we moved on to the next table. One person would stay at each table to act as scribe while keeping the rest of us on track, and would recount the summary so far to each new group.

The three questions were:

  1. How can social media help achieve KM objectives?
  2. What is “KM as we know it”?
  3. Does KM have to change to survive? If so, why and how?

I can’t cover everything that was discussed, mainly because I didn’t take any notes, but I can tell you what I think. Traditionally, KM has been closely linked with librarianship—the keepers of structured document repositories. Document management will always exist in some form but knowledge managers are evolving to become curators and connectors. Social media is forcing creators to provide knowledge in consumable amounts, which makes it easier for those people to share their knowledge in the first place. As a result, we end up seeing the huge amount of information and anecdata stream by that we’re so familiar with on Twitter and Facebook. Knowledge managers with an active enterprise social environment in their toolset are having to let go and trust that the good stuff bubbles to the surface.

Rather than killing off KM, I think social media has brought it to life. It’s less about dusty tomes on bookshelves not being updated and more about connecting the dots in real time. It’s nimble and adaptable.

KM will always be about enabling better decisions, not just in the day-to-day but for idea generation, too. Approaching enterprise social tools with bravado and posting that idea, no matter how big or small, is empowering at all levels of an organisation. We no longer have to produce a document to get the ear of the CxO. Last night’s knowledge café was facilitated by Marie O’Brien and she highlighted the third era of knowledge management, as explained by Nancy Dixon. The third era is all about  Idea Management. It’s about enabling vertical knowledge exchange for organisational learning. On a purely practical level, enabling the whole organisation to be potential innovators is certainly easier with some kind of enterprise social tool.

What do you think? Is this the end of KM as we know it or its second coming?

It’s not really about knowledge management

Pic from http://beyondthescarfknitting.blogspot.com.au

I’ve become more and more convinced over recent weeks that knowledge management isn’t about managing knowledge at all. The Oxford dictionary defines management as “the process of dealing with or controlling things or people”. Knowledge isn’t something we deal with; it’s something we aim to use and learn from. Nor can we control it. After all, tacit knowledge often only becomes known through serendipitous encounters and casual conversations. We can do our best to control explicit knowledge through governance over how we store, write and reference formalised documentation such as knowledge base and policy and technical documentation. But control implies restriction and we want to avoid that at all costs. If we talk about the implied meanings of words and phrases, knowledge management suggests that our goal is to follow a precise order of steps to capture and store knowledge in a series of neat boxes.

I admit, I do aspire to an almost OCD level of organisation, but that ain’t ever gonna happen, Friend, because I have an 8 month old pile of unfiled paperwork next to me on the desk, right now. I do like categorisation, yes I do, but I like the frayed edges of serendipity as well. I like to pull at a thread over here to see what unravels, and then a thread over there… Often they’re truly divergent, but sometimes they come back together into a different, more exciting form.

Calling those learning experiences knowledge management just sucks all the romance and the life out of it. No wonder there aren’t more people on my bandwagon.

Knowledge enablement isn’t easy to say, and it’s not sexy marketing, but it’s exactly what the goal is—enabling quicker decision making and problem solving; enabling those serendipitous encounters by connecting people with each other; and enabling growth and innovation through lessons learned.


Why You Should Open Up Support to Your User Community

A group of Kinder egg working gnomes

Photo from Horia Varlan on Flickr

Do you know you have a ready-made community of practice that could be sharing knowledge amongst each other about your product or service? They might be talking in person, but it’s likely they occasionally talk to each other on Facebook or Twitter, as well. When groups of people get together to talk about your product or service they are commonly using, they uncover neat ideas on how your product can be used in innovative ways. They discover more efficient ways of using your product, based on the experience of others. We like to compare what we’re doing to someone else, just to know we’ve got it right.

Now imagine if you facilitated that by opening up an online user community, where your customers could come together and have those conversations in a space they know you’re available and listening. And I’m not just talking about your customers having somewhere to bring up feature requests or “here’s how we’re using it, what are you guys doing?” I’m also talking about your customers helping each other out when issues arise. Sometimes your customers, in their tinkering with an issue, come up with their own workarounds or solutions.

In December, I wrote a post detailing my predictions for 2012. One of those was an expectation that community management would merge with IT service support. Last night, I listened to a webinar called “Is the Service Desk Still Relevant?” During the panel’s discussion, ITIL author Stuart Rance (@Stuart Rance) and @ServiceSphere‘s Chris Dancy, called for service desks to create a community management role to engage with the user community and build upon the knowledge community members share amongst each other and with the service provider. By engaging with your user community in a searchable, online medium, you already have the basis of a living knowledge base. Some support software solutions provide a forum structure that is ideal for this kind of community, and others provide a social stream, not unlike Twitter, which lacks structure but can be easily tagged and searched.

If you’ve got the means but you’re unsure of the method, and you can get to Melbourne in September, please check out Swarmconf. You’ll get a ton of help and knowledge from experienced people in the online community management field, who can help you map out how to get started.

Tacit, Explicit, Implicit, Whatever. Let’s call the whole thing off.

the Wise Leader from HBR May 2011

Image* inspired by The Wise Leader from HBR May 2011


One of the highlights of the KM Australia congress was the debate on day 2. The topic was Making tacit knowledge explicit with collaborative technologies. Arguing for “we should and we can” was Aaron Everingham and James Dellow, and for “we shouldn’t and we can’t” was Shawn Callahan and Dr Vincent Ribiere. I thought it was an odd question in the first place, though there’s a good discussion in the KM Australia LinkedIn group. Brad Hinton also offered a response to the question on his blog. I found the meaning of should or shouldn’t in this discussion to be unclear, and indeed through the course of the debate, both sides agreed with each other at different times.
I’ve always found the conversations that nitpick over the definitions of tacit and explicit to be irritating, but just for the record, here’s what they mean:

Tacit – this is the knowledge in our heads that is made up from experience and personal contexts. It’s not written down and is hard to articulate. A great example, (and I don’t remember where I read this. If you know, please comment and I’ll link to it.), is the worker at an oil rig who knew there was a drilling failure by the feeling of the vibrations at a certain spot on the platform. The only way he could transfer that knowledge was by taking the visitor, who was documenting knowledge and procedures, out to that spot and showing them the feel of that vibration as it was happening and explaining what that meant. Apprenticeships, mentoring, and sometimes video documenting are good ways to tap into another’s tacit knowledge.

Explicit – this is the knowledge that is written down and is accessible in one way or another.

Implicit – this is knowledge that isn’t written down yet but is largely procedural and not dependent on an individual’s context.

Implicit doesn’t often come up in conversations knowledge wonks have about the types of knowledge. Usually, we just talk about tacit and explicit, and this may explain why people confuse tacit with implicit. The reason I find these conversations irritating is because the person who needs the knowledge at the time they’re doing the work, probably doesn’t know and certainly doesn’t care. No complete knowledge management program has one single approach to knowledge transfer, aiding one type of knowledge at the expense of the other, anyway. We should always take a multi-pronged approach, even though we may make one change at a time. So let’s just get the knowledge to the people, no matter what its original form.

And so, what do collaborative technologies have to do with this discussion? These social tools allow us to connect virtually, before we meet in real life. They allow a relationship to germinate so that the initial awkwardness and defensiveness that some of us might feel on first meeting, isn’t there. When those barriers aren’t there the stories and personal contexts, and the tacit knowledge, flow much more easily. So, while collaborative technology doesn’t make tacit knowledge explicit, it certainly enables that knowledge transfer.

* The image is from this fassforward Consulting Group sketchnote, inspired by this article.

Page 2 of 4123...Last