Drop The Pilot

I was talking about Enterprise 2.0 with the management team of a large publishing company a little while back, hitting all the familiar topics: ROI, risks and threats, whether Millennials really are different than older workers, and so on. As I listened to their questions and comments, though, I heard another topic emerge, one that I realized I’d been hearing about for a while in one form or another without directly addressing or acknowledging it. This was the underwhelming result of most pilot projects, and the difficulties this posed to E2.0’s champions.

I’ve been hearing a lot of comments that go something like:

My company is interested in Enterprise 2.0 and I believe in it, so I got put on the team to prove the concept. We set up a pilot project where one team / division / business unit got software for collaborative editing / social networking / blogging / etc.. And the results so far have been…  unimpressive. There’s not a massive amount of activity, it doesn’t feel like it’s gaining momentum, and there aren’t clear success stories that I can point to in order to convince the sponsor / the skeptics that E2.0 works for us. What are we doing wrong? What should we do from here?

Let’s take that first question first. I believe these kinds of pilots are unintentionally set up to fail, or at least underwhelm. This is essentially because they contain too few people, most of whom know each other too well.

The more I learn about and think about the value of emergent social software platforms, the more I suspect that the deep meta-benefit they provide is technology-enabled serendipity, defined as ‘good luck in making unexpected and fortunate discoveries.’ Serendipity is possible when we’re collaborating with our close colleagues on a well-defined project, but that’s probably when it occurs least often. It’s much more likely during wide forays and broad searches, the kind that are so easy to do with current technologies.

I think serendipity is part of what underlies Metcalfe’s Law and a big part of the explanation for Eric Raymond’s insight that ‘given enough eyeballs, all bugs are shallow.’ Knowledge workers and their organizations should be doing everything possible to increase opportunities for serendipity. This means searching broadly for information, narrating work so that others can become aware of it, asking questions to the biggest possible audience without presupposing who might have the answers, and generally contributing to and drawing from the biggest possible digital commons. This is what Enterprise 2.0 should be all about.

How many of us have found great information in some weird corner of the Web, someplace far from the presumed authorities? How many have had a question answered on Twitter by a stranger? Received unexpected praise or good wishes on Facebook or LinkedIn from someone we hadn’t thought of in a while? The smaller the scale of an ESSP deployment, the less likely all these good things become.

These realizations lead to an answer to the second question posed above. Enterprise 2.0 enthusiasts should abandon pilots and go as broad as possible right away. The risks of doing this are small and manageable, and the serendipitous benefits are many.

Here’s a simple high-level E2.0 rollout plan that abandons the idea of small pilot projects and instead opens wide the doors to good luck, long-distance helpfulness, and fortunate discoveries. And it’s only six steps long! 😉

  1. Deploy tools that deliver a novel capability, like microblogging, social network formation, or prediction markets. Tools that deliver something novel — that aren’t trying to displace an incumbent — avoid the 9X effect.
  2. Make sure the tools are frictionless, freeform, and emergent. This lowers barriers to participation and altruism.
  3. Give them to everybody with just enough policy-setting to satisfy the people who concern themselves with compliance, risk, and security.
  4. Get a group of both formal and informal leaders to be heavy initial contributors. They’ll draw in others quickly.
  5. Monitor usage over time and make adjustments if and when necessary (for example, if conversations descend into flame wars or anyone’s tone becomes inappropriate or unprofessional).
  6. Collect examples of the good stuff that happens. Use these to justify the project, satisfy the sponsor / boss, and evangelize.

What do you think? Will this work –  will it attract usage, deliver results, and not lead to disaster? Am I missing anything important? If this isn’t a viable blueprint for getting started with E2.0, why not? Leave a comment, please, and let us know.