Tag: suwcharman

Here are the notes I took of Suw Charman‘s talk. They’re not necessarily well-constructed, and may even contain inaccuracies. I did my best, though!

It’s trickier than it seems when using blogs in business.

Will talk about using blogs and wikis internally. What can you do when things go a bit wrong?

Software is easy to install, so companies install it, some people start using it, but they’re not getting everything they can out of it.

Wikis are for collaboration, blogs are for publishing. Clear how the technology works, but not clear why some people don’t adopt social software internally for their work.

Reasons?

Low-level fear of social humiliation. How are they going to come across to their peers and bosses? Fear of making mistake. People don’t realise they’re afraid, they just feel a bit uncomfortable talking /publicly/ to their collegues. E-mail is different because it feels private, it’s 1-1 communication. You’re not exposing yourself as much. People become “shy” when you give them a very public place to work.

Also, some people aren’t comfortable in writing. Some are better talkers than writers, and are not comfortable writing in a semi-formal environment. E-mail is more informal. Blogs and wikis are perceived as requiring a higher level of writing skill. Again, people don’t admit to this.

This doesn’t happen in very open organisations, but often if permission isn’t explicitly given to use such tools, that will really get in the way. “Blogs as diaries”, etc — psychological mismatch. What the boss /thinks/ blogs are, and what they are used for in business.

Trust in the tool. “So you mean anybody can change my stuff?” for wikis. “Can I stop them?” Not comfortable trusting the content placed in such tools, and the tools themselves. “What if the tool loses everything?”

Will the tool still be around in one or two years? If we pour our data into this wiki, am I going to just lose everything if management pulls it down?

Many people just don’t see the point. See social software as something they need to do /in addition/ to what they’re already doing. Parallel with KM disasters.

Biggest problem: how to get people involved. Two basic routes: top-down, and bottom-up.

Top-down can work all right if you have a hierarchical company and control what people are doing. Will work while managers go “you have to use this, or…” but people will abandon it when pressure disappears.

Bottom-up. Trojan mouse. People start using stuff because they think it’s useful, and it spreads through the organisation. Grassroots can be very powerful in getting people to use this kind of software. Risk: incompatible software, duplication of efforts, managers closing things down.

Go for the middle way: support from above (yes, you can use that, we encourage you to use this) but rely on the “bottom”, people using the software to have it spread.

Adoption strategy:

1. Figure out who your users are, not globally, but as small groups with shared needs. You need to understand what these people do every day. Good place to start: look at how they’re using e-mail. E-mail is a very abused tool. CCing just to let you know stuff — we get a huge amount of e-mail for things we don’t really need. Or things like conversation often happen badly in e-mail: somebody missing from the CC list, or somebody replying to one instead of all. And you can’t just access somebody’s inbox. People send out attachments to half a dozen people, and they all send back with comments, need to merge. There are places where these things can be done better/quicker. Identify who is influential within your area — supernodes — who can help you spread adoption, push a tool from something that is used locally to something that is used business-wide.

2. How is this going to make their lives easier? Some use cases can be very small, not very impressive, but very practical. E.g. coming up with a presentation in a short time by using a wiki. Doing that by e-mail wouldn’t work, not in four hours. Another thing is meeting agendas. Put it on the wiki instead of sending out agendas in Powerpoint, Excel, Word… The minutes can go on the wiki too. Looking for places where conversations are fragmented => wiki. Blogs: look for people publishing stuff on a regular basis. Start with those simple use cases, then these practices will spread to other uses. People are bad at generalising from a high level (ie, wikis are for collaboration — d’uh?)

3. Help material on the wiki won’t help people who aren’t comfortable with it. Print it out! Or people are so used to hierarchy, that they recreate it in the wiki, even though it might not seem necessary. If this is the behaviour they feel comfortable with, then we’ll enable this. Come up with naming schemes to make this possible. Be very open to letting the people use these tools the way they want to: coffee rotation, sports page, etc.

4. At one point, requests for help etc. dropped. Critical mass had been reached. People were self-organising.

Top-down stuff: Suw’s more in favour of bottom-up, but often needs to be married to top-down.

Important thing: having managers who accept the tools. Some people can really get in the way of this kind of adoption project. Work around them in a way.

Managers who are the most successful in getting their people to use these tools are those who are the most active, who blog, use the wiki, encourage their people to use it. E.g. manager who would put everything on the wiki and send one-liner replies to e-mails containing questions about this with pointer to the wiki.

Use the tools regularly if possible. Easy to slip back into the old ways, but go back to using the tools.

Beware: adoption and usage is not the goal. Getting your job done is.

Q: what about privacy and secrecy?
A: easy to create little walled gardens in a wiki. also, everything that happens on a wiki is logged.

Need for wiki-gardners. Most of the problems are not technological, but cultural. How people react to the environment. Social vs. hierarchical organisation.

Tool recommendation: depends a lot on who is going to use it. E.g. MediaWiki sets business users running screaming, because it doesn’t look like Word. Happier with SocialText, maybe. What is the users’ comfort zone regarding tools? What about the existing IT infrastructure? Businessy users tend to like shiny stuff, branded, Word-like. More technical users tend to be happy with bland-looking things that might even be broken.

Q: external use cases for blogging?
A: “blogs are diaries” => scary for businesses. Some very mundane use cases: Disney used blogs to announce events (threw away their customer crappy tool). Personal knowledge management — “what have I been doing, what stuff do I need to find again?” Person who has to report on what he’s doing: blog about it, and let boss read. Competitive intelligence. What’s happening out there/in here. Also, “oh this is interesting!” — people blogging about social things, not business-related things. Actually good, allows people to get to know each other. steph-note: I think Google understands that. We tend to underestimate the importance of social relationships in business.

Update, July 3rd: the video