“Collaborate!” (getting people to use technology to work together)

Working with other people is, for me, the best way of learning and getting things done. Unfortunately, I only learnt this after I left university, but better late than never…

Over the last two years at BT, I’ve introduced users to a variety of technologies designed to help them work together more effectively, originally in the belief that if you make the right choice about which tools to deploy, that’s most of the job done. It pretty quickly became clear that that ol’ hilarity about horses and water is as true with collaborative working as it with so many other aspects of technology. Indulge me while I point this out, but to expect people to use collaborative technologies in a constructive way from the off is madness. On the contrary, the average group of people you introduce to a new tool, whether it is based on Microsoft Sharepoint, JotSpot, Atlassian Confluence – whatever, really – find that their productivity goes down and their confusion goes up.

The obvious answer here is that putting the effort in at the beginning, to explore the uses of the technology with the group and pointing out common pitfalls, is a good idea and should be a part of any technologist’s work when we roll out new technologies. However, this can all be a bit undirected and I’ve found that a few approaches work better than others, and that bearing these in mind can and should influence both your choice of technology as well as the pace of the interactions you have with the teams who will be using it. (A lot of the following has to do with moving working practices out of the inbox and off the desktop, and onto the web in some way.)

1. Minimise change The most powerful thing that you can do as a technologist is stick as closely to people’s ways of working as possible, and let migrations to new technologies happen at a pace they are comfortable with. An example of this done very well is showing a group how the calendar you’ve just set up for them on their shiny new Sharepoint server is also accessible right inside their Outlook. This is cool because they probably spend a lot of their time there already, so it doesn’t seem like such a conceptual leap.

2. Make things familiar This is related to the point above, but it is worth saying that how recognisable a new tool is makes a big difference to how happy people are using it. I’m not just talking about colours and having the corporate logo in the same place, but recognisable behaviours are important – what happens when you right-click the mouse? What happens when you click and drag? Outlook Web Access comes up trumps in this area – a lot of work has gone into recreating the feel of Outlook within the web browser, albeit in a very Internet Explorer-specific way. (Just as a side rant, I feel that Microsoft’s stubborn refusal to emulate the IE experience on Firefox is so annoying mainly because it feels completely unlike Outlook, not because there is fundamentally different functionality (although the omission of search is unforgiveable.))

3. Use a carrot not a stick I often get into the habit of thinking that the benefit to changing the way you do something is obvious if I already know what that benefit is. The best example of this is with wikis – because I use them a lot, it seems to me that storing text content in a wiki is a pretty effective way of getting people to collaborate on it. The problem is that this is only true if everyone I expect to work with is also of this opinion; if I introduce the idea to a group of people who are not regular users, there is generally a modest amount of enthusiasm for the idea, followed by an almost total lack of participation. Whilst this is still a tricky problem (mainly because wikis work because of the network effect), I’ve found that if you put meeting agendas on to wikis and not in an email, all of a sudden wikis make a lot more sense and people use them for other things too. This is the “carrot”, as opposed to the “stick”, which would be you (or more likely, their manager) telling them to use the tool. This carrot method applies to so many situations it is another corporate cliché, also related to horses, which might say something about the way managers see their staff.

[edit:] This McKinsey paper was flagged up to me – if you can be bothered to register (grr), it’s a well-researched and interesting look at how to get the most out of user-generated content (a big part of online collaboration!).


  1. Chris
    Posted September 25, 2007 at 8:55 am | Permalink

    The final point is the most important. If I know that something benefits me I’m bound to be interested. Trying to convert my colleagues to wikis has been arduous but successful. The root of that success was to show benefits by demonstration. I would deliberately put myself in situations (such as presentations) where colleagues would ask questions requiring up-to-date information to answer. I’d then visually demonstrate the power of the wiki. That old classic ‘seeing is believing’ has never failed me.

  2. Posted September 25, 2007 at 9:59 am | Permalink

    I like that example a lot Chris… very clever!

  3. dr1ft3r
    Posted September 25, 2007 at 1:45 pm | Permalink

    Jon – I agree wholeheartedly with Chris on your third point being the most critical. The only real way of getting people to collaborate is making their contributions not only important to everyone else, but ultimately to those who are the actual contributors. Without this carrot, I have yet to be successful at any of the stick approaches that have been attempted for any length of time. Let’s collectively think of better carrots to provide to users…

  4. Posted September 25, 2007 at 3:34 pm | Permalink

    That’s a great idea James, I look forward to seeing you open a wiki on the subject! 😉