Turning Serendipity into Probability

I’m going to take a swipe at another cherished social software notion: Serendipity. We should ban that word from the social software lexicon. It’s misleading and it makes enterprise social software seem about as relevant to the business as the plastic mistletoe hanging at the office Holiday party: Something amazing could happen, but it probably won’t.

The idea behind serendipity is that social software enables colleagues who have shared or complementary interests and expertise to discover each other and collaborate. It’s serendipitous because, hey, who knew that Theresa in Tucscon was a certified blackbelt in Six Sigma, the very methodology that Victor is trying to implement in Virginia?

It’s true that social software teases out those kinds of hidden connections. But when social software is implemented properly, there’s nothing serendipitous about it.

Imagine Victor in Virginia works for a 10,000-employee defense contractor that has successfully implemented an enterprise socials software tool as its social intranet. If he goes to that intranet and asks who can help him with a Six Sigma implementation, he is almost guaranteed to get five, ten, maybe twenty responses. While Victor may not know who will respond, he can be reasonably confident that someone will. So from Victor’s standpoint, there’s a high probability that asking the question will get the kind of responses he’s looking for.

It’s simple mathematics. Consider the following statistical fact. For any two people, there is a very low probability (roughly 1/365) that they share the same birthday. And when two people discover they have the same birthday, it’s serendipity. But if you fill a room with just 57 people selected at random, there’s a 99% chance that some two people in that room will share the same birthday. That’s probability.

Victor and Theresa may be surprised to discover that they share an interest in six sigma. That’s serendipitous. But we should not be at all surprised that Victor got the response he needed. The odds were quite high. From the moment Victor posted his question, he was almost guaranteed to get a response. That’s probability.

The point is that social software doesn’t enable serendipity; it transforms serendipity into probability. Serendipity is when Victor happens to sit next to Theresa on the red-eye to London and discovers that they’re both interested in Six Sigma. It’s a random event, neither reliable, nor repeatable, nor scalable.

But when Theresa is first to respond to Victor’s company-wide post looking for Six Sigma expertise, that’s probability. It worked, we knew it would work, and the fact that it worked this time makes it even more likely that it will work next time.

What’s that you say? My distinction between serendipity and probability is mere semantics? Maybe, but words matter. Companies and their leaders only take social software seriously when they see it as part of mainstream business process. Mainstream business process is all about repeatability and scalability.

Imagine the response you’ll get if you tell your CEO, “We’re implementing a system to make serendipitous connections among staff members.” I can hear your CEO yawning from here.

Now imagine telling your CEO, “We’re implementing a system to ensure that all staff get the help they need, when they need it, from knowledgable colleagues across the company.” That CEO conversation just got a whole lot more interesting.

So let’s get serious about making business process social, and leave serendipity to the mistletoe.

Comments (7)