Hi ByteWorks Volunteers,
Your friend, Steve DeLorey, has recommended this article entitled 'The 
importance of pigheadedness' to you.

Here is his/her remarks:
Everybody,
I was reading up on a new book called "Here Comes Everybody" and ran across 
this bit of wisdom. I'm interested in the book because it is supposed to 
address some of our current problems. Such as, how to get things done without 
imposing too much structure.

Steve

The importance of pigheadedness
Posted By Suw Charman-Anderson On April 29, 2008 (11:09 am) In Business,  
Innovation,  Media 2.0

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.

Article taken from Strange Attractor - http://strange.corante.com
URL to article: 
http://strange.corante.com/2008/04/29/the-importance-of-pigheadedness



[Non-text portions of this message have been removed]

Reply via email to