I just read an essay by Clay Shirky, Gin, Television and Social Surplus, about how the industrial revolution has resulted, after a brief period of societal gin-soaking, in a surplus of time and productive capacity which has been mopped up by TV sitcoms. Now, however, this social surplus is being put to use in things like Wikipedia, World of Warcraft and blogging. People are taking their spare time and energy and they’re doing something with it.

It’s a great essay, and I strongly recommend that you pop over and read it, right now, all the way through, because it articulates something that many of us know is happening, but which a particularly large chunk of the media hasn’t cottoned on to yet. It’s not the content of Clay’s essay that I want to further discuss, but one little line that has much broader ramifications:

The normal case of social software is still failure; most of these experiments don’t pan out.

Every now and again I’ll be talking to a client or a journalist or some random person at a conference, and they’ll ask me if I think that social software is a fad. Invariably they’ll have anecdotal evidence of some company, somewhere, who tried to start up blogs or a wiki inside their business, and it failed. That, they say, is proof that social software has nothing to offer business, and that if we give it a few more years it will just go away. Quod erat demonstrandum.

The problem with this interpretation is that these failures – which are common, but largely unexamined and unpublished because no one likes to admit they failed – are part and parcel of the process of negotiating how we can use these new tools in business. They are inevitable and, were they discussed in public, I’d even call them necessary as they would allow us to learn what does and doesn’t work. Sadly, we don’t often get a glimpse inside failed projects so we end up making the same mistakes over and over until someone, somewhere sees enough bits of the jigsaw to start putting them together.

There is a lot of failure in the use of social software in business, on the web, in civic society, but we need to see this as a part of the cycle, a step along on the learning curve. We can’t afford to stop experimenting, just because something failed once, or because it didn’t work out for someone else. And we can’t afford to take part in the Great Race To Be Second, either, because if you’re waiting to see how other businesses succeed (or fail) before you leave the starting line, you’re not going to be second, you’re going to be last.

From a business point of view, the nice thing about social software is that a lot of is is free or ridiculously cheap, so the monetary cost of failure is low and made up mainly of the cost of people’s time. There is no need to judge a social software project based on the same criteria as, say, a massive software deployment from a megacorp vendor that cost millions and took three years, yet these are the terms by which many businesses are judging their blog, wiki, or social networking experiments. And because the tech is so cheap, businesses can afford to run many small experiments to find out what works before they deploy tools more widely; indeed, they cannot afford not to.

But we also need to recognise that the biggest speed bump in social software projects is invariably going to be the social, not the software. The technology is improving every month, mainly because it’s being developed by small, nimble vendors who use the software they create and want it to be the very best it can be. But the tech is only a fraction of the battle. The rest, like Soylent Green, is made of people.

And this is where the problem with failure comes in. Generally speaking, people don’t much like change. They don’t even like choice all that much, although they’ll tell you that they do. They certainly don’t like failure, or anything that looks even remotely like it. (Especially in the UK, although I think that the US is a bit more tolerant.) And they don’t like trying again when things do go a bit wobbly.

Failure, real or perceived, is inextricably entwined with status and, frequently, if a project looks like it’s about to go bottom up, instead of figuring out how to save it, people figure out how to distance themselves enough to save face. In a business culture where rewards and punishments are focused on the individual, the teamwork and collaboration required to make a social software project a success can become too much of a risk. But if you’ve got the right skills and personality, you can turn that around.

To be successful at social software implementations in business you need firstly to have a solid understanding of how people work and relate to computers, tools, and each other. You need to understand how to introduce tools in a way that is non-threatening and which emphasises utility and benefits. You need to understand the political climate within your business, and know how to route around anyone who’s threatening to be obstructive.

Secondly, you need to be really pigheaded. If one team doesn’t take to a wiki, try working with another. If one blog fails, try to figure out why and then start another. Iterate. Change things. Experiment. Try again. After all, it’s only failure if you give up.