Three lies about social software

Lie 1: Social software causes groupthink and herd behaviour

I’ve never quite worked out why people think this is the case; for a long time I just assumed this was a misconception held by those who’d never really experienced or used social software in earnest.

Then I read Kathy Sierra’s post on One of Us is Smarter than All of Us, and suddenly everything fell into place. [By the way, I really like her Past Favourites section, it makes it really easy and convenient to find a prior post.

People who believe that social software foments groupthink are similar to people who believe that Wisdom-Of-Crowds is about herd instinct. Here’s a quote from Kathy’s post:

  • Where I had it wrong is that his book’s premise (wisdom of crowds) comes with qualifiers.
    The wisdom of crowds comes not from the consensus decision of the group, but from the aggregation of the ideas/thoughts/decisions of each individual in the group.
  • At its simplest form, it means that if you take a bunch of people and ask them (as individuals) to answer a question, the average of each of those individual answers will likely be better than if the group works together to come up with a single answer.

It’s really like scaling up Belbin-like team dynamics on a gigantic scale. The “team” represented by a given blog community is actually a collection of incredibly diverse people, with common interests rather than common views. Much of what I learn from comments on my blog is from the extensions, the qualifiers, the provisos, even the complete disagreements. This is not groupthink, it’s anything but.

Humanity is a collection of individuals. A very long tail. 19th century marketing really loved pigeonholing people, and pigeonholed people may well have acted like Gadarene swine. [Talking about Gadarene swine. Many years ago, when I commuted in to London on the A4, getting ready for another day on the treadmill, I couldn’t help but smile when I saw the Good Morning Lemmings sgraffito on the motorway stanchions. Made me remember to get off the treadmill before I got to work. Incidentally, if you want to see what I saw, here’s a link to a Hilary Paynter sketch on the topic]

Lie 2: Social software is full of inaccuracies and downright lies

You only have to read things like the Pew Internet report to figure out what percentage of blogs and wikis and IM are to do with reportage. Most of this space is taken up by observation, comment and opinion, not “reported facts”. I guess you have to be pretty arrogant before you can dismiss someone’s opinion is wrong; you can disagree with the opinion or the comment, but that’s about all.

Even for the small part of this space that is about reportage, it’s hard to sustain the “inaccuracies and lies” position. There’s always a variant of Linus’s Law in operation: Given enough eyeballs, all information bugs are trivial. If anything, social software is more honest than MSM when it comes to factual errors. They get corrected. And the original error-prone version disappears.

With MSM on the other hand, the lie is printed and continues to be an archived lie. And while you may get a retraction or correction, it tends to appear on page 32 sandwiched between dog shampoo ads and undertaker recruitment campaigns.

Lie 3: Social software destroys privacy

There are many reasons why I believe that privacy, as the West knows it, is dead. Some of it is to do with the web. Some of it is to do with social software, I guess. Some of it is probably even due to cyber-crime. But I think we’re missing the point. People share information willingly. Now some of them may not realise quite how much information they are sharing, and how this information may be used against them, but that cannot be laid at the door of social software.

People who don’t want to share openly still use social software. There are passworded wikis, closed-loop IM systems, even things like Orkut Crush. Openness is primarily a choice and not a condition.

Designing and testing for customer experience

A few weeks ago, I wrote about how using opensource makes you responsible; one of the tragedies I’ve seen regularly in large institutions is the willingness of service departments to hand off blame to the “vendor”, and I’ve often wondered why people abdicate responsibility that willingly.

The customer does not care about your sourcing strategy. The customer cares about what he/she experiences. That’s what we have to design for, that’s what we have to test for, and that’s what our sourcing and partnering strategies need to underpin.

As we move towards realms where more and more things get commoditised, and more quickly at that, it is reasonable to assume that the only aspect of a service offer that differentiates one firm from another is the quality of the customer experience.  And one of the things that intrigues me about all this is how to get better at designing for customer experience, and its cater-cousin, testing for customer experience.

While researching this, I came across a transcript of Danah Boyd’s talk at the O’Reilly Emerging Technology Conference in San Diego earlier this year, via Kathy Sierra’s post on ultra-fast release cycles.

The entire talk is a must-read. Examples:
[Talking about MySpace, Flickr and Craigslist]

These three sites have many attributes in common. They all grew organically. They each have public personalities that early adopters feel connected to. The early adopters really felt as though they were participating in and creating an intimate community, even as the community grew to millions. Users are passionate. Designers are passionate. They feel a responsibility to it and are deeply invested in making users happy. Character was not boiled out of the site; the text on the system is natural and goofy, reflecting the personality quirks of the developers rather than the formal speech of a corporation. Each site has a unique culture that was born early on and evolved through years of use and growth. The culture evolves with the designers and users working in tandem.

Customer service is not a segregated group who simply answers questions of a finalized product. They are completely integrated into the design system and the senior people are the most deeply embedded in user culture. There is a strong commitment to the needs and desires of the users.

While the creators have visions of what they think would be cool, they do not construct unmovable roadmaps well into the future. They are constantly reacting to what’s going on, adding new features as needed. The code on these sites changes constantly, not just once a quarter. The designers try out features and watch how they get used. If no one is interested, that’s fine – they’ll just make something new. They are all deeply in touch with what people are actually doing, why and how it manifests itself on the site.

[Talking about how the creators of these sites use embedded observation]

The designers of these systems are engaged in embedded observation. They are living in the culture that they are helping to frame. They are aware of the others living in that culture and constantly engaging with them to really understand the emergent behaviors. They recognize their power as designers and try to use it to benefit the collective rather than their own personal goals. Their design process is stemming from this embedded observation, producing a state of “flow” to use Cziksentmihalyi’s term. The designers love what they are doing and infuse their passion into the systems. This is a very powerful way of doing design.

What they’re doing methodologically is very unique in software development and is not yet part of the standard practices for developing social software, although it should be. Embedded observation allows developers to understand culture. They are doing a form of ethnography, the method used by those seeking to understand culture. They understand culture by living amidst the cultural natives, trying to understand practices from the perspective of the people engaged in them. They are trying to make sense of how the symbols came to be and how the culture is maintained. They are doing so in order to understand culture and to help shape the architecture to support the culture.

Embedded observation takes into account the cultural forces that can not be systematically tested or modeled. As a result, the designers are aware of social problems when they materialize and can work immediately to try to influence change. Their efforts at understanding culture and evolving the design alongside it create a meaningful bond between the users and the designers.

[As part of a set of guidelines at the end of the talk]

Make sure designers and customer support are engaged with one another. Customer support should help designers know what is going on with users; designers should work to understand what customer support is seeing. This probably means they need to be seated near each other, have an opportunity to socialize together, etc. Oh, and for good measure, have your designers drop into the support queues every once in a while.

None of this is rocket science; as Danah so eloquently explains, many of the more recent successful companies live and breathe this stuff.

I think there’s something that’s really important, something fundamental, that Danah captures well. As IT professionals, we’ve been good at listening to a lot of people. We used to be good at listening to ourselves, to the detriment of evweryone else. But we learnt from that, and we got better at listening to the “customer”. And quite often that meant the person who paid the piper. The front office. The sales channel. The product marketer. Whatever.

But we never really listened to customer service reps. And if we want to improve the customer experience, it’s a good place to start.
We need to get better at involving our customer service staff in the design process; we need to get better at getting them to articulate the scenarios they would like to have improvements made to; we need to get better at understanding what it really feels like at the customer service coalface.

More later. I’m interested in comments from people who have done this, what they’ve learnt, what worked for them, what didn’t work.

The Revealed Intention Exchange

Anant’s written a post about Orkut Crush which makes fascinating reading. Maybe it’s been happening across many social networking sites, and I just haven’t seen it; possibly because I haven’t used the “looking for someone” facilities.

Orkut Crush allows person A to register a  “crush” on person B, and vice versa; the registered information is only provided to the matched pair when both sides signal.

So at a level of abstraction it allows a signalling of intention, done in secret, with the intention only revealed to the other party when matching conditions are met.

There are many things that need matching. There are many ways of indicating interest or signalling intention.

I wonder.

Varieties of Work-Changing IT

I had the opportunity to spend some time with Andrew McAfee in London last week, but for some reason I hadn’t yet seen his article in November’s Harvard Business Review. So we didn’t talk about it. Shame, but one that’s easily corrected.
It’s well worth a read; I’m working on my comments and will share them with you in a post later. In the meantime, I believe it’s available free-to-air for the rest of this month, so do try and take a look, you can find the article here.

I just can’t resist one comment though. Take a look at the table below.

R0611J_A.gif

Andrew makes one very very important point. Not that the others aren’t important, but one of them really stands out for me.

In the table above, he defines Enterprise IT as “IT that specifies business processes“.

He does not say “IT that is specified by random and ever-changing and poorly articulated and inconsistent and sometimes even nonexistent business processes.”

IT that specifies business processes.

By this I don’t mean that the IT department has to specify all the business processes, that’s just plain stupid. What I mean is that enterprise systems work well only when there are rigorous standardised processes; they work well when these rigorous standardised processes are industrial strength, with external frames of reference; they work well when the number of processes is kept to an absolute minimum, and where process divergence and diversity is avoided. The “system” consists of people, processes and technology, working to common goals and held together by a common culture. Too often it’s the process piece that goes AWOL, aided and abetted by avaricious consultants, accepted and nourished by inertial inhouse staff.
IT that specifies business processes.

If only that were true. If only I had a dollar for every time “respectable” consultants plundered the heart of an organisation by mangling an enterprise resource planning system until it was as unfit for purpose as humanly possible. If only I had a dollar for every time “responsible” business users lapped up all this attention and “blamed” the internal IT department for rampant project failure, because they believed the lie. The lie that an ERP system was meant to mirror their existing processes. because they wanted to believe the lie. If only I had a dollar for every time the internal IT department quietly acquiesced and said it was all their fault, fired a few innocents, promoted a few bystanders, whatever. If only.

Of birds flying around unwalled gardens: There’s hope in them thar hills

For a while now, I’ve been tracking what’s happening with Songbird, and more recently I’ve started playing with it. It works. At least the parts of it that are meant to work, work.

cross_platform.png

Ross Karchner at Ross Notes puts it succinctly:

  • Songbird looks like it is shaping up to be the cross-platform, open-source iTunes replacement I’m looking for, with some really great integration with the larger music web– It’s like taking iTunes, ripping out the music store, and replacing it with the rest of the internet.
  • Browse to any web page with links to music, and it becomes a playlist. Songs play instantly, and saving them to your library becomes a single-click or drag-and-drop operation.

I love iPods, and will continue using them. Because they’re fantastic. In design and execution and usability and experience.

I’ve never bought anything from iTunes, though my children have. iTunes is nothing more than an elegant way for me to manage my music, music that I’ve paid for.

I love Macs. I still have fewer Macs than iPods, but the gap’s narrowing :-)

So why do I like what I see in Songbird? Because I don’t like lock-in. I want to be able to choose my device, choose my platform, choose my connection, choose my everything. I understand when that is technically impossible. I am less tolerant when it comes to creation of artificial scarcities and blocks. Just look at the garbage that is Region Coding on DVDs and you will see what I mean.

Songbird may not be the answer. We have to wait and see. But it has possibilities. And is “directionally” sound. [Pun intended].