<< January 2006 | Home | March 2006 >>

Influence and Persuation

Did anyone see Derren Brown's 'The Heist' on C4 just after Christmas?

For those that didn't, he set up some middle managers by pretending to be coaching them with seminars, experiments, etc. What he was actually doing was kind of brain washing them to think it was acceptable to rob a security van. The last thing he did was to set them up to be walking down a street all alone, going past a security van. 3 out of 4 of them pulled out their toy gun and robbed the van!

It was very impressive - and got me and some mates talking about how it was done. We ended up looking on Google and Amazon, and I'm now the proud owner of two books on influence and the power of persuasion. So if find that after having a drink with me, you are robbing banks and strangely putting the money into a Swiss bank account, that might be why :-)

OK - most of the things in the books are about how to sell stuff to people, or avoid being sold crap. I'm trying to work out how to use the techniques in software managment...

The good thing about the books are that they are backed by scientific research. For example, if you wanted to jump to the front of a line of people photocopying, by saying "excuse me, can i jump to the front" you would only have a 60% success rate. If you change that to "excuse me, can i jump to the front because i'm in a rush", you would have a 95% success rate. Strangely though, the reason you give is not important. You still get a 94% success rate if you say "excuse me, can i jump to the front because I need to make some copies"! The human mind is set up to use its subconscience where ever it can, and this is a case where the subconscience saves you time by thinking for you. But it isn't good at logic, so doesn't disect the request.

Another good one is well known. If you are making a request for something, start with a high request, and when you fail go in with what you really wanted in the first place. eg. Can I have 90 days for this software component please. No. OK well if we blah blah blah, we can do it in 60. OK! The reason it works is because all societies bring up their children to realise that when someone offers you something, you should reciprocate the offer. So when I offer to do it in less time, you are subconsciously forced to reciprocate by saying yes. Furthermore, because the second request of 60 days is much less than the original 90 days, we look at it relatively, not absolutely. So the fact that is less than the original makes it much more appealing. Never mind the fact that I only need 45 days (or is that 90 days, because I spend half my time on the phone, or blogging - see earlier blog!)

OK - last one for today. If you were to buy someone a drink without them asking, the reciprocation rule taught to us during childhood means that we feel obliged to return the favour. But if I were to ask you for a return favour before you offered me another beer, by say asking you to buy 5 raffle tickets at a quid each, the majority of people will comply. So by spending 2 quid on a pint, Ive made money! What's more, research has shown that its irrelevant if you like the person, the fact that you owe them makes such a big impact that you will buy the raffle tickets even if they are an idiot. Now, add this example with the one on negotiating above, and you could ask the person to buy 10 quids worth of tickets. they would probably say no, so you counter offer with getting them to buy 5 quid of tickets. how could they decline such an offer (especially when they owe you for the beer!)

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

Time Usage

An IBM colleague has been keeping track of time usage by his developers (off shore) over the last week. He found it surprising that only 50% of the time was actually used for development. The rest of the time was take up by communications, knowledge transfer (basically ramp up of new developers), maintainance issues (dealing with customers on the phone doing second level support), etc.

Having read Peopleware: Productive Projects and Teams, by Tom DeMarco & Timothy Lister, (December 1999, ISBN 0932633439) I wasn't that surprised. It explains why I've always found that doubling an estimate magically makes it accurate.

My IBM colleague is going to continue to monitor for a few weeks, so if the results change, I will let you know!

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!