Imagine the following dialog taking place in the office of a major company’s CIO. Sitting at his desk he talks to an IT Director responsible for the company’s HR infrastructure.

CIO: So, how is the new performance review tool doing?
Director: Works like a clock. It’s been three months since we’ve deployed it and so far so good.
CIO: No issues, then?
Director: Well, there is that thing we’ve been sort of struggling with.
CIO: What is it?
Director: Adoption is kind of low. Honestly, they don’t use it that much.
CIO: Hmm… Nice. So they keep doing it in email?
Director: Yep. Plus some homegrown stuff and an open source thing someone installed under his desk.
CIO: What have you tried?
Director: The usual. You know, email announcements, posters, some training. Signed up a couple of VPs to talk about it at their meetings. Still, the uptake has been minimal. A couple of divisions said they don’t get it; one said they won’t look at it till the next fiscal year.
CIO: Nah, that’s not enough these days. You’ve got to provide incentives. Sponsor a contest or two, have cool prizes for the top reviewers. Do that viral thing. Also, I hear reaching out to the vocal folks helps – make sure you sell it well to them and get them talk about their success stories. Plus, go to that site… what’s its name… slowforward, fastbckwards… something like that… they post good tips. I’ll look it up for you.
Director: Will do. Remember, how simple it was in the old days?
CIO: Sure do. But times have changed. Don’t forget to set up that contest…

Doesn’t make much sense, does it? But try replacing “new performance review tool” with “new wikis” or a social software package of your choice, and all of a sudden the dialog doesn’t seem so absurd anymore.

Adoption: a New Word and a New Concept

For years IT lifecycles have been about planning, deploying and operating. Whether you were rolling out a review tool or a new accounting package, worrying about its adoption was simply not on your to-do list. You plan it well, you deploy – and then you’re in maintenance mode. But when it comes to social business software, deployment is just an initial step on what may become a long and rocky road. And if you’re not thoughtful about walking that road, it may lead to a rather daunting place where beautiful broadly available tools sit for months waiting for a single user to touch them. Having a social tool to solve a real business problem is necessary for long-term success, but in most cases isn’t sufficient. The second ingredient of the e2.0 secret sauce is adoption.

The main premise of social software is that it connects people – better, faster, cheaper. This is where its power comes from. But it is also its Achilles’ heel. The same network effects that make social software so powerful once it’s broadly adopted can make it nearly useless when its user base is too small. How valuable Facebook would be if you were the only one using it – or if it was used only by people with whom you have nothing in common? Today, more than ever, network effects bring a huge advantage when taken into account, and a lead to spectacular failures when ignored.

As usual, in the enterprise context, things are similar, but not quite the same as they are in consumer space. Network effects are obviously not new in the enterprise land – after all when you send email to a colleague you do expect that person to have an email account and to check it often enough. Same goes for actions like sharing a document with someone – your recipient should have software capable of understanding the format you’re using. What’s different about today’s social software is the landscape in which it has to be introduced and operated.
Until now internal adoption of enterprise software followed one of the two simple models:

1. Users have no choice (desktop OS, e-mail, payroll, etc)
2. Users benefit from software regardless of its adoption by others (file sharing, internal portals, etc)

In the first case you get a speedy (though not always cheerful) 100% adoption, in the second case as long as the tool provides value, a simple awareness campaign leads to steady adoption growth. In contrast, adoption of social software happens in a dramatically different environment: typically users do have a choice, and the value they get out of the software depends on how many other people use it. While different social tools require different levels of adoption to become useful (Hutch Carpenter has a great post on this), they all need some critical mass of users – and for some tools that mass is rather significant.

Enterprise social systems are typically complementary in their nature. Rarely – if ever – they are deployed as a direct replacement of an existing LOB application. They aim to improve connections, but truth is that in any functioning organization people already have some existing ways to connect and collaborate. So unless your new tool explicitly replaces an old one, it faces what every new start-up out there has to face: competition. All of a sudden, IT departments and business decision makers have to deal with challenges such as cold start problem and sobering reality check of “build and they will come” approach. They face internal communities happily sharing information on email distribution lists, documents on internal file shares filling the gap a wiki was expected to fill, and surprisingly efficient expertise finding methods that involve asking a know-it-all colleague down the hallway. When it comes to social software, habit may be the biggest obstacle.

Walk the Yellow Brick Road

So what’s the recipe for dealing with these challenges? It’s simple: you acknowledge their existence, and invest efforts into winning your users’ attention. At least, this is a recipe that’s been working pretty well for the team I lead at Microsoft. In particular it has really helped as we’ve been developing and driving adoption of CodeBox – Microsoft’s internal shared source system for collaborative software development (more on it here).

We’ve found that the key is to think like a startup, treating employees like customers and fully realizing that they had been taking care of their business before your solution existed, and will move on if you go bankrupt. While the exact list will vary depending on the system you are trying to get adopted and factors like organizational dynamics, here are some core principles that in my opinion seriously help with adoption of majority of social software.

1. Know who your users are, what they need, and which of their pain points you can address with your solution.
2. Plan and execute on your adoption strategy – broad adoption very rarely happens on its own
3. Run pilots and early adopter programs, targeting people who really care about the problem space. They may be harsh in their criticism, but their feedback is invaluable, and once you get them on board they become your most active promoters.
4. Build and nurture an active community around the system you introduce.
5. Define a clear set of metrics and track them meticulously all the time.
6. Expose your new solution in the contexts where your users currently operate. New shiny destinations can be tempting, but users don’t have time to go too often out of the tools they live in.
7. Identify the most successful customers and give them stage to tell their story to others.
8. Show the way for your users. The benefits of a new system are much better understood when someone articulates them for you.
9. Walk the talk, i.e. use your solution every day to do some (better yet, a lot of) real work – you’d be surprised how much you learn when your own deliverables depend on the system you thought was perfect for others.
10. Be flexible and adjust as you go, based on the trends you observe and user feedback you receive.

Note that this list (an extended version of which can be found here) is about adoption; it does not cover many things you need to take into account to design and build the system.

When it comes to social software, broad adoption is paramount. More critical than features, it can make a clumsy simplistic system more successful than its sleek feature-rich competitor. But getting to that shiny Emerald City requires walking the yellow brick road, since people need a reason and time to change their habits. The most interesting part about that journey is that while your users will undoubtedly learn something along the way, the person who will learn the most is you.