90-9-1 Participation and Enterprise Social Software Adoption

In 2006, Jakob Nielsen postulated that participation in online communities followed these characteristics:

  • 90% of users are lurkers (i.e., read or observe, but don’t contribute).
  • 9% of users contribute from time to time, but other priorities dominate their time.
  • 1% of users participate a lot and account for most contributions: it can seem as if they don’t have lives because they often post just minutes after whatever event they’re commenting on occurs.

This was groundbreaking research, and it is a terrific framework for thinking about communities. Its lessons can help sites design better interactions.

The 90-9-1 is useful for thinking about employee participation as well. The more people who participate, the more Enterprise 2.0 advances companies’ fortunes.

But in really thinking about communities, it occurred to me that 90-9-1 is an incomplete basis for considering participation inside the enterprise. In reality out on the web, participation levels for a typical site are more aptly described by the pyramid below:


Of course, this is a fairly useless graphic for the consumer Web. Obviously, the vast majority of users don’t visit any single site. Tell me something I don’t know.

Inside a company, this graphic becomes critical. Consumers can live with splintered participation on various websites, be they Web 2.0 or Web 1.0. But this approach is terrible inside companies.

For instance, assume there’s a major initiative underway inside a company. Some employees are using the company wiki, but others never visit the wiki. They use email and PowerPoint decks to trade information and ideas. As things progress, some employees think to check the wiki for new items. Others never check the wiki, and exclusively head out to Google to find information, even if the same or better information has already been added by colleagues to the wiki.

Splintered participation. Out on the consumer web, it’s a personal choice. Inside companies, it’s inefficiency.

For companies to get full benefit from the social productivity tools deployed to employees, participation has got to look better than 99-0.90-0.09-0.01.

Improve Tools Visibility

A recent blog post by Oliver Marks on ZDNet examined integration of Enterprise 2.0 inside companies. This quote hypothesized a cause for low adoption of wikis and blogs in some organizations:

This is why there are so many sparsely populated wikis and blogs slowly twisting in the wind in the corporate world – because they were set up as tentative trial balloons with no clear utility or guidelines for expected use.

The gist of his point is that before you let these apps in your door, know why you want to use them. That’s solid advice, and should be clearer for projects from the start.

I’d like to suggest another way to influence participation inside companies. Wait…let me quote Dinesh Tantri’s idea for increasing participation:

We would need some means of allowing users to carry these services in a virtual backpack. This backpack should be available at all points where users interact with information systems. (Desktop, Intranet, Extranet and probably enterprise apps ). Browser and desktop extensions are one easy way of doing this. Perhaps smarter ways of doing this in a browser/platform agnostic way will emerge. The point is, usability and the interaction design of Enterprise 2.0 deployments has to be high on the agenda of enterprises trying to leverage them.

The idea is embedding social software into the regular tools and activities that employees already use. Dennis Howlett advocates this with the ESME microblogging project with which he works. It’s an idea I like a lot.

If you think about how things work out on the web, awareness grows for tools like Facebook, Twitter, Digg, FriendFeed, etc. as people find about them naturally. There’s no policy prescription for using these apps. They come into view in the course of one’s dealing on the web.

What I like about Dinesh’s idea is that it lets the “99%” crowd, those who never visit a particular site, discover content, conversations and people that are relevant to their day-to-day jobs. This raises their awareness. When you run a search and find out that something relevant to you is already on someone’s blog, or the wiki or microshared, you suddenly have more interest in that tool. That awareness is important for any tool, even more so when its use is not mandated by senior management.

Raising awareness of social software tools, content and users. A critical component of a successful rollout of Enterprise 2.0.

I’m @bhc3 on Twitter.

Enterprise 2.0 Vendors – An Implementation Lifecycle Model

On a phone call with a Connectbeam customer, I heard what seemed like a good description of the way in which Enterprise 2.0 – and perhaps other enterprise software – achieves enterprise-wide adoption. This particular customer started with an internal advocate who started with a departmental implementation, and is now rolling it out to thousands in the organization.

Now anyone following the space knows there are many, many factors in the process of gaining adoption. What I’m going to describe is a slice of those factors, but I think it’s a juicy slice.

The graphic below depicts the model:

Four stages in this simple model. Let’s break ’em down a bit.


This is the initial toehold in the organization.  Where will the app makes the most sense? For many vendors, the place where it makes the most sense is the department where the most enthusiastic advocate resides.

Clearly, the vendor needs to consider where its app will have the highest impact, and where an office culture will be receptive to a new way to working.

Implement also includes any integration with other apps. Don’t underestimate this. It takes a bit of time to set things up, and often at the departmental level, employees aren’t as familiar with corporate apps.

But really, the Implement process revolves around the manager who has the most passion for your app.

Try It

Next, employees need to actually use your application. This is important (obviously). If you’re going to show ROI for your app, it starts with people actually using your app.

Measure usage stats. These are the early markers of whether the app will be successful inside the company.

The internal advocate needs to recruit fellow passionates into this process. Try out the service. Put some real live near-term projects and tasks up on the service, be it a wiki, microblogging, blogs, social bookmarking, RSS, etc.

The internal advocate and his/her fellow travellers should celebrate when other employees use the product. Give them a shout-out for their usage, recognize the useful stuff they create.

The Try It stage needs to run for a few weeks or even months. The app really needs to prove its utility in this stage.


After sustained usage by a group for a while, there will be interesting Anecdotes that emerge. Let’s be clear on the value of these…

Anecdotes drive company-wide adoption

Dry stats such as entries per day, clicks per user, etc. are the stuff you need to measure whether people are Trying It. Anecdotes are what sell the app to other departments and locations inside the organization.

Anecdotes are tangible examples of value. Other employees can hear these examples, and imagine the app being used in their daily work.

Anecdotes that put real dollars behind the use of the app are incredibly value. “So-and-so did this with app, and ended up saving $XX,XXX” types of stories. Those get the attention of senior management, make heros of the internal passionates, and put the social software app on an equal footing with other apps inside the company.

The internal advocate is best-positioned to hear and solicit these Anecdotes. They are the key to company-wide rollout.


Welcome to the world of big-time software. Once you break through the departmental and geographic barriers, you’re going to get a lot of feedback on your app. More use cases will emerge than you knew. And more feature requests will come in.

But, attention will still need to be paid to the Try It stage. These other departments may not have a dedicated passionate. The key here will be recurring communication about Anecdotes. The group of internal advocates from the original pilot will become ambassadors and trainers on the best ways to use the app. This continues their role as internal heros and stewards of the app, and leverages their energy and experience.

Wrapping Up

This is a simple model, with a few observations provided. If you’ve got others to share, feel free to weigh in with a comment below.

I’m @bhc3 on Twitter.