free html hit counter
Posted on: Saturday, June 26, 2010 by Rajiv Popat

Leadership Tip: The Art Of Easing Out And Building Self Sustaining Teams.

Hell has broken lose at Multiplitaxion Inc. The sky is falling. The shopping-cart of a production system seems to have developed a glitch in a live website and apparently, it seems like people cannot buy things from the website.

I know what to expect next.

Throng of emails start flowing in on the support system.

Then comes a few emails from the client, with a little bit of tough love, directed at all of us.

It looks like there is a minor configuration glitch in Jack's code which is causing this awkward moment for all of us.

I hear the soft whisper in my head. My first instinct, the hidden, sedated asshole within me, whispering in a gentle, seductive and powerful voice.

"Call up Jack! Ask the incompetent idiot to fix it ASAP. Tell him it's CRITICAL. Absolutely fu@#king critical."

And then the veteran who has been there, done that and knows that it not work in the long run takes over.

I smile inwardly and decide to wait, answering the emails to the best of my abilities and sitting down to fix my own share of bugs, reminding myself that I am just as incompetent and just as big an idiot as anyone else.

Jack has already received the email. Jack is a mature human being with brains to understand that when shopping carts go down, companies lose money. He is probably looking at the problem right now and trying his best to fix it as quickly as possible. If he does not respond in the next hour or so, I will causally check with him. I respond to the seductive voice in an equally commanding tone and shrug it aside.

A few minutes later, another email lands on my inbox. It's Jack. The issue is resolved. The cart is up and running again. Life is back to normal.

The next morning, Jack is at my cubical. He wants to apologize about the issue and all those emails everyone had to reply.

"Nah. Don't worry about it. Shit Happens." --- I respond with a smile.

That is it. End of discussion. We go grab a cup of hot chocolate, talk about latest phone that I have been drooling over and discuss my intent of buying it.

I am happy. My life as a 'manager', 'development lead' or whatever it is that you want to call me, is a happy one.

It was a zero-touch operation or me. I now have a self sustaining team that functions perfectly well without me and I would have never found that out if I would have intervened on that and many countless nights before that.

Yes, there have been a few accidents. A few bumps while the teams I worked with in the past were in the drivers seat and I was in the back-seat, looking out and admiring the view, but nothing bad enough to get us killed.

Here is the interesting part however.

Every time the sky starts falling you will have a temptation of taking the drivers seat. Ease out of it. Let your team drive.

Because if you let them drive, they might get into a couple of small accidents and maybe even a couple of big once, but then they will learn how to drive, really fast and really well.

And once that happens, you can just take the back seat and admire the view or just find bigger challenge for yourself.

You know, the "professional growth" crap they talk about in seminars. This is how it happens.

Try it.

It actually works.

I wish you good luck.

posted on Saturday, June 26, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, June 25, 2010 by Rajiv Popat

Programmer Tip: Reducing Your Parallel Threads And Prioritizing Your Free Time.

I just promised someone I'll do a talk in their conference. He wants a copy of the presentation I am going to deliver at the conference. I have two unfinished drafts of blog posts sitting in my drafts folder. There is a side project that I need to be working on.

I am out with my family, eating in an amazing Italian restaurant. There is some shopping that I need to do. The book that I started working on is on a stand still, unfinished, grabbing me by collar and asking me to give it the finishing touches it deserves.

Put simply, I am on a thread dead-lock as I desperately try to figure out which thread to take up and process next.

It is something fairly similar to your machine's processor choking with too many applications running and each ALT+TAB takes you seconds to switch.

The conference cannot wait, neither can the blog posts but it is time to choose between the book or the side project. A decision has to be made,  a thread needs to be ended and a door needs to be closed. At-least temporarily.

Dan Ariely in his absolutely amazing book, Predictably Irrational talks about the inherent fear that we as human beings have towards closing doors. He used experiments which included observing students while they played a computer game designed specially for the experiment to observe how human beings react to the idea of closing doors. He explains:

To find out, we changed the game. This time, any door left unvisited for 12 clicks would disappear forever. SAM, A RESIDENT of the hackers' hall, was our first participant in the "disappearing" condition. He chose the blue door to begin with; and after entering it, he clicked three times.

His earnings began building at the bottom of the screen, but this wasn't the only activity that caught his eye. With each additional click, the other doors diminished by one-twelfth, signifying that if not attended to, they would vanish. Eight more clicks and they would disappear forever. Sam wasn't about to let that happen. Swinging his cursor around, he clicked on the red door, brought it up to its full size, and clicked three times inside the red room. But now he noticed the green door—it was four clicks from disappearing.

Once again, he moved his cursor, this time restoring the green door to its full size. The green door appeared to be delivering the highest payout. So should he stay there? (Remember that each room had a range of payouts. So Sam could not be completely convinced that the green door was actually the best. The blue might have been better, or perhaps the red, or maybe neither.) With a frenzied look in his eye, Sam swung his cursor across the screen. He clicked the red door and watched the blue door continue to shrink.

After a few clicks in the red, he jumped over to the blue. But by now the green was beginning to get dangerously small—and so he was back there next. Before long, Sam was racing from one option to another, his body leaning tensely into the game. In my mind I pictured a typically harried parent, rushing kids from one activity to the next.

Is this an efficient way to live our lives—especially when another door or two is added every week?

I can't tell you the answer for certain in terms of your personal life, but in our experiments we saw clearly that running from pillar to post was not only stressful but uneconomical. In fact, in their frenzy to keep doors from shutting, our participants ended up making substantially less money (about 15 percent less) than the participants who didn't have to deal with closing doors.

The truth is that they could have made more money by picking a room—any room—and merely staying there for the whole experiment!  (Think about that in terms of your life or career.)

When Jiwoong and I tilted the experiments against keeping options open, the results were still the same. For instance, we made each click opening a door cost three cents, so that the cost was not just the loss of a click (an opportunity cost) but also a direct financial loss. There was no difference in response from our participants. They still had the same irrational excitement about keeping their options open.

As human beings in general and as programmers in particular we are hugely attached to the idea of keeping our options open, keeping multiple choices in our lives and getting involved with multiple projects. On one hand, we have programmers who cannot program and 501 developers. On the other we have folks who are working on so many different things and trying so hard to keep all of these efforts alive that none of them ultimately see the day of light.

For me, it was this secret project of mine, that would have to wait. I am closing a door for the time being, so that I can focus on another one and so that the book can reach a meaningful logical milestone.

If you are getting bogged down with too many side-projects to work on, too many speaking engagements, too many things to do and you find yourself handling multiple threads even on weekends, maybe its time to take a pause, evaluate and close a few doors. The least you can do is close them temporarily and then come back to them at a later time.


Focus on what is really important to you, even if it means closing a few doors of your life so that you can focus on the ones that mean a lot more to you..

Go ahead, pick a few assignments or projects that can wait and either end them or put them on hold temporarily.

I wish you good luck.

posted on Friday, June 25, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Sunday, June 20, 2010 by Rajiv Popat

Programmer Tip: The Virtues Of A Little Bit Of 'Boredom Time' In Your Life.

This idea of this post started off with a mail thread from someone who has a knack for sending amazing links which nudge you to do some serious soul searching every time you click one of his links. This one was a post about the iPad.

To be honest however, it was more than just an iPad post. Peter Bregman in his post on why he returned his iPad in less than a week, talks about the importance of boredom in your life. He explains:

The brilliance of the iPad is that it's the anytime-anywhere computer. On the subway. In the hall waiting for the elevator. In a car on the way to the airport. Any free moment becomes a potential iPad moment.

The iPhone can do roughly the same thing, but not exactly. Who wants to watch a movie in bed on an iPhone?

So why is this a problem? It sounds like I was super-productive. Every extra minute, I was either producing or consuming.

But something — more than just sleep, though that's critical too — is lost in the busyness. Something too valuable to lose.


Being bored is a precious thing, a state of mind we should pursue. Once boredom sets in, our minds begin to wander, looking for something exciting, something interesting to land on. And that's where creativity arises.

My best ideas come to me when I am unproductive. When I am running but not listening to my iPod. When I am sitting, doing nothing, waiting for someone. When I am lying in bed as my mind wanders before falling to sleep. These "wasted" moments, moments not filled with anything in particular, are vital.

They are the moments in which we, often unconsciously, organize our minds, make sense of our lives, and connect the dots. They're the moments in which we talk to ourselves. And listen.

To lose those moments, to replace them with tasks and efficiency, is a mistake. What's worse is that we don't just lose them. We actively throw them away.

"That's not a problem with the iPad," my brother Anthony — who I feel compelled to mention is currently producing a movie called My Idiot Brother — pointed out. "It's a problem with you. Just don't use it as much."

Guilty as charged. It is a problem with me. I can't not use it if it's there. And, unfortunately, it's always there. So I returned it. Problem solved.

Go ahead, click the link and browse through the entire post if you haven't done so already. The valid point Peter seems to be making here, is about slowing down. Giving your brain some boredom so that it can figure out creative, genuinely fun and innovative things to do to avoid that boredom.

It's more than just the iPad.

I have talked about this before. Firefighting for instance gets you in a mode where you are least creative.

With a zillion gadgets, MP3 players and twitter on our phones, we are insanely connected to random people all around the globe but it does the exact same thing to your brain that firefighting does. It gives you an easy convenient way to make yourself busy and indulge in activities which are 'seemingly productive' but result to nothing other than a truck load of time getting wasted in the long run.

If you work in a field which involves creative work or are connected with the process of building software that is supposed to make big or small dents in the universe, the first thing you need to do is slow down and give your brain some boredom.

Boredom is important,  because when your brain experiences boredom and feels restless, it starts thinking of productive ways to keep itself busy. That's when some of the best ideas and solutions emerge. The last time I checked, ideas and amazingly interesting solutions to complicated problems, typically don't emerge when you are watching an action movie or a soccer match for instance.

Go ahead, slow down.

Experience a little bit of boredom today.

Use this boredom to let you mind wander and come up with a genuinely innovative idea or two.

I wish you good luck.

posted on Sunday, June 20, 2010 10:34:06 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Saturday, June 19, 2010 by Rajiv Popat

Programmer Tip: The Perils Of Having A Truck Load Of Negative Drama Around You.

Folks at Multiplitaxion Inc are gathering in small groups and talking every time I walk through the cafeteria. There are whispers all around. It's in the air. You can quite literally feel it. There is drama in the air and it looks like the drama has a drama queen.

Or should I say, a drama king.

It seems like Fred just had a hugely vocal argument about why he cannot be working from home on a certain day. Fred it seems is not willing to accept the fact that HR isn't comfortable with the whole idea of working from home. Fred is also not willing to have a logical objective conversation with the HR folks and convince them of the benefits of letting folks work from home at times.

He chooses the vocal loud revolt instead, creating a loud conversation which turns into a heated argument.

Very soon, every single engineer, in every nook and corner of the office knows the incident and is talking about it.

Fred's intent is pure. His approach however is destructive because it involves a simple ingredient which single handedly is capable of destroying teams and organizations.


A few days later, one of our scrums, begins with a joke involving a senior manager. Everyone in the scrum takes a stab of cracking a joke at this manager. Soon, a decently normal scrum now involves a lot of talking. It has almost turned into one of those meetings where nothing gets done. This dear manager of ours, has fired three innocent hard working programmers and has given us something to discuss.

More drama.

Some idiot somewhere has sent condescending emails with a threat to one of his managers at the time of his resignation. The email seems to have gone to everyone in the group and a truck load of people seem to be involved in discussions on the topic.

Insanely massive drama.

During my early days at Multiplitaxion Inc, I loved going to office every day, but then there was a part deep down within me which wished that there was no drama the next day. It was stressful. Seriously stressful and non-productive.

But then, to be honest, there was also a deep dark secret part of my brain, which uncontrollably liked observing drama as it unfolded. Like everyone else in the organization, I often got involved in discussing the drama as it was unfolding.

That, to an extent, is what we all do. At different levels. When there is drama unfolding all around, you are likely to get sucked in. The spice of the drama, happens to be much like the oil in the McDonalds French fries. It surely won't kill you in a shot or two, but then when it sneaks up on you, you hardly know what hit you. That is exactly what drama does to your productivity, your work ethics and your professionalism.

It turns you from a productive programmer to a drama queen before you even know it.

I have talked about this before. Relationships and circles based on criticisms don't last long. Work relationships based on dramatic situations are even worse. So I totally understand that you had nothing to do with Fred sending out that flame email to his manager and copying the entire group while he was at it, but even then, might I suggest that you disconnect from the drama and focus on being productive.

Might I suggest that when a colleague takes you to a cup of coffee and then starts bitching about a mutual boss, you gently change the topic and focus on what you can do to fix the situation rather than whining together like babies.

It's hard.

But I didn't become a programmer because I wanted to bitch, whine, moan, cry or experience a lot of negative drama. If I wanted that, I would have given my shot at the films or television. I joined programming because I wanted to work with the sharpest, smartest, wildest, wittiest and some of the most creative people I could find and then join forces with them to build stuff or tell stories about what they do or how they do it.

The lesser drama you see on a day-to-day basis, the more you will get done, the more productive you will be, the happier you will be, the more flow you will experience and above all, you will be able to build more stuff and get more done.

Go on, the next time you start experiencing random negative drama, say no to it.


Start saying no to it.

Chances are high that you will get much more innovative, creative and above all productive, instantly.

I wish you good luck.

posted on Saturday, June 19, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, June 18, 2010 by Rajiv Popat

Leadership Tip: Understanding Human Polymorphism In Teams And Organizations.

You have spent days observing Jack. He is awesome when it comes to dealing with pressure situations. Never looses his cool. Has shown perfect leadership qualities when talking to you, even in the most pressure prone situation, giving you a strong vibe that everything is under control.

You are impressed.

Months later, you find yourself sitting across the table with a bunch of developers telling you how Jack is throwing his shit their way, bossing them around and making them do hardcore deadline driven development.

You cringe.

A few days ago I posted a small tweet.

You thought you knew Jack.

Human beings happen to be hugely polymorphic. They are insanely different creatures in different situations and in different groups.

Jack, as it turns out, happens to be a seriously kick ass programmer and a very good person to have on your team. Give Jack a couple of additional programmers to mentor or work with and Jack measures them with the much higher level of critical outlook that he measures himself with. This is not about qualities or talents that Jack lacks when working with or mentoring a small team.

When he happens to be seating in a status meeting or dealing with crisis situation Jack happens to be a very different human being than what he is when his team is facing a crisis. Observe carefully and you will be able to literally see Jack morph from a quite, calm, cool headed individual sitting in front of you, to a angry, loud micro-manager when working with his team.

This is not the only situation where people in your teams and organization will morph though. Another classic case of morphing that human beings often go through is when they have given you their resignations.

This is when folks will give you a truck load of suggestions about how your organization needs to improve, how it has been missing out on certain areas and above all, all those dozen tiny little areas which he just did not seem to care about before he resigned.

The same individual who tells you how much he loves working in your organization or your team morphs into a totally different human being when he interviews for a different company next week and answers the famous "three things that you don't like about your current organization" question in that interview.

When you are working with a team of three individuals, you are probably dealing with a team of more than thirty personalities, constantly morphing from one to another.

This is important. So important that I am going to say it again.

When you are dealing with a team of three individuals, you are actually dealing with thirty different personalities, not three.

If there is one thing years of working with human beings has taught me, it is that you cannot be banging your head over being nice to all thirty of these constantly morphing personalities. Focus on the three that work with you.

Go ahead, talk to Jack about how much his team hates working with him, even if it means rubbing him in the wrong way.

Go ahead and stop worrying about the personality that is constantly looking for a change because irrespective of how much you or your organization tries there are always going to be some folks who will occasionally morph into individuals who are so dissatisfied with small things that you cannot just retain them in your organization or your team.

Stop worrying about rubbing two-hundred-and-ninety seven morphing personalities the wrong way and focus on the three that work with you.

Be nice to them and do all you can to make their work experience a pleasurable one.

I wish you good luck.

posted on Friday, June 18, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Sunday, June 13, 2010 by Rajiv Popat

Leadership Tip: Avoiding The Perils Of Organizational Procrastination.

Multiplitaxion Inc, was a technical training provider where I happened to work for a few months. Multiplitaxion Inc, as it turns out was very open to change and as far as getting approval for change was concerned, if you knew the right people to talk to, getting your ideas approved for implementation was easier than you could think. But then, getting your ideas approved was just a small part of the brining-about-change game.

If medical science ever discovers such a thing as organizational procrastination, let it be known to mankind today that you read about this condition here first. Multiplitaxion Inc, was a master at it.

This was, in more ways than one, very similar to silent disagreement. In fact, it was worse because it worked at an organizational level. Projects that had been approved took days to get started, policies took weeks to get applied, rules took months to actually get changed and even project parties for successful projects took countless number of days to get planned.

Approvals were quick.

Actual implementation however, took months, even for the smallest of decisions.

Amidst all this procrastination, one thing that we as young and budding engineers learnt was that procrastination at an organizational level often also leads to organizational amnesia. Before long, we realized that some of the best ideas that would have otherwise turned into innovative products, were not even seeing the light of the day, because people were approving them and then procrastinating over them till they dropped out of everyone's memory.

If you happen to run an organization or have the power to get things done within your organization my advice to you would be, don't create organizations or teams with procrastination and amnesia. Think hard over an idea till the time you back it and approve it. Once you know you need to get something done, stop your procrastinations and get things done as a fast moving team or organization.

I wish you good luck.

posted on Sunday, June 13, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, June 12, 2010 by Rajiv Popat

Design Tip: If Your Product Is Great, It Does Not Need To Be Good.

If you have ever worked on anything that was used by more than one user, for more than a few days of their lives, you probably get a truck load of hugely random and weird feature requests at work. If you have worked with a bunch of marketing and sales folks responsible for demoing your product to 'potential customers' you probably know this even better. 

I have talked about avoiding the Perils of Demo Driven Development through heavy use of YAGNI before. But then having said that, every once in a while, a random critic will convince your marketing and sales team that if you could just build that chat application that allowed the point-of-sales team to interact with each other and integrate it with your billing system your billing system will sell like hotcakes.

If you have ever thought of giving in to temptation and building stuff that the competition is building just so that your product could compete with your competition, Paul Buchheit of Gmail has sensible word of advice for you. He explains:

I believe this "more features = better" mindset is at the root of the misjudgment, and is also the reason why so many otherwise smart people are bad at product design (e.g. most open source projects). If a MacBook with OSX and no keyboard were really the right product, then Microsoft would have already succeeded with their tablet computer years ago. Copying the mistakes of a failed product isn't a great formula for success.

What's the right approach to new products? Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise. For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac (most hardware companies can't make software, so I bet the others got this wrong). That's it -- no wireless, no ability to edit playlists on the device, no support for Ogg -- nothing but the essentials, well executed.

We took a similar approach when launching Gmail. It was fast, stored all of your email (back when 4MB quotas were the norm), and had an innovative interface based on conversations and search. The secondary and tertiary features were minimal or absent. There was no "rich text" composer. The original address book was implemented in two days and did almost nothing (the engineer doing the work originally wanted to spend five days on it, but I talked him down to two since I never use that feature anyway). Of course those other features can be added or improved later on (and Gmail has certainly improved a lot since launch), but if the basic product isn't compelling, adding more features won't save it.

On his assessment on whether iPad is a great product or not, or if all the critics shouting at the top of their voice about the lack of features in the iPad are justified in doing so or not, Paul gives useful advice to young and budding product designers. He explains:

By focusing on only a few core features in the first version, you are forced to find the true essence and value of the product. If your product needs "everything" in order to be good, then it's probably not very innovative (though it might be a nice upgrade to an existing product). Put another way, if your product is great, it doesn't need to be good.

Making the iPad successful is Apple's problem though, not yours. If you're creating a new product, what are the three (or fewer) key features that will make it so great that you can cut or half-ass everything else? Are you focusing at least 80% of your effort on getting those three things right?

If you are working on a product, go ahead. Pick those three small and simple things which your product is supposed to achieve. Write them down in easy to understand sentences on a whiteboard.  Now, do some serious soul searching on if your product does these three things flawlessly. Is your product the best in the world at doing these three things? With consistent effort and hard work, can it become the best in the world at doing these three things?

If you answered no, adding features to your product will not help. If you answered yes, put in that consistent effort and hard work to make your product a great product, because if it is a great product, you won't have to slog your ass to make it a good product.

I wish you good luck.

posted on Saturday, June 12, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, June 11, 2010 by Rajiv Popat

Leadership Tip: When In Doubt Rely On Basic Goodness Rather Than Market Norms.

During my work at a client, who for the purposes of this post, I shall refer to as Multiplitaxion Inc, I saw an amazing example of management and HR policies, backfiring in ways that no-one had expected them to backfire.

Multiplitaxion Inc, was an amazing place to work at. Even for me as an outsider or a consultant who was just visiting, the folks at Multiplitaxion Inc were not just nice, they were super nice. They got me my very own personal cabin, gave me printer access and even had a name plate with my name printed even though I was just going to work with them for a few months.

Multiplitaxion Inc, happened to be one of those places where a group of like minded people gather, not just to work but to live a like minded life. These were bunch of rather amazing oil engineers and software engineers who worked for twelve to thirteen hours a day. Walk into Multiplitaxion Inc at seven in the evening and chances were that you would see a bunch of engineers flocked together trying to solve a problem.

During my stay at Multiplitaxion Inc one thing I noticed was that people hardly ever took leaves. During my first three months of stay, no-one from my team ever took a leave. 

This story however, begins on a bright sunny day when someone high up in the pecking order who had access to the time card logs and no real work to do decided to glean though the logs and discovered that people were coming really late to office. Soon strings were pulled and decisions were taken for the best interest of the organization.

Emails went out informing the employees that folks entering office after ten would be marked absent for the day and that people were 'requested' to be at office on time. A policy that was supposed to put some sense into office timings and increase employee productivity. A policy that started backfiring on the very first week on which it was imposed.

Turns out, Jack, who happened to be one of the youngest and the brightest programmers in our team, stumbled on a scenario which caused the policy to backfire on the very week in which when it was imposed. One first morning, as Jack prepared to leave from office, his eyes fell on the watch and seeing that it was nine-thirty already, Jack realized that there was no way he was going to cover a one hour drive and make it to office by around ten. 

Jack, gave the situation due thought and given the fact that he had a ton of leaves cumulated with him because he never took any, decided to go for the idea of taking the day off. From that point on, the idea spread like wildfire. Folks who had never taken leaves in years, suddenly started going missing. Passion that had once driven folks to come to office, turned into confirmation towards rules. Leaves that were never utilized were now used up rather quickly.

A policy that was designed to make people spend more hours at the workplace turned into a policy that made them spend the least number of hours that they had spent in office during their entire careers.

What had happened here is very articulately describes by Dan Ariely in his book Predictably Irrational. Dan explains:

My good friends Uri Gneezy (a professor at the University of California at San Diego) and Aldo Rustichini (a professor at the University of Minnesota) provided a very clever test of the long-term effects of a switch from social to market norms. A few years ago, they studied a day care center in Israel to determine whether imposing a fine on parents who arrived late to pick up their children was a useful deterrent.

Uri and  Aldo concluded that the fine didn't work well, and in fact it had long-term negative effects. Why? Before the fine was introduced, the teachers and parents had a social contract, with social norms about being late.

Thus, if parents were late—as they occasionally were—they felt guilty about it—and their guilt compelled them to be more prompt in picking up their kids in the future. (In Israel, guilt seems to be an effective way to get compliance.) But once the fine was imposed, the day care center had inadvertently replaced the social norms with market norms.

Now that the parents were paying for their tardiness, they interpreted the situation in terms of market norms. In other words, since they were being fined, they could decide for themselves whether to be late or not, and they frequently chose to be late. Needless to say, this was not what the day care center intended.

In the same book Dan goes deeper into the concept of why this fine did not work using the idea of two worlds that each one of us live in. He explains:

As Margaret Clark, Judson Mills, and Alan Fiske suggested a long time ago, the answer is that we live simultaneously in two different worlds one where social norms prevail, and the other where market norms make the rules. The social norms include the friendly requests that people make of one another. Could you help me move this couch? Could you help me change this tire? Social norms are wrapped up in our social nature and our need for community.

They are usually warm and fuzzy. Instant paybacks are not required: you may help move your neighbor's couch, but this doesn't mean he has to come right over and move yours. It's like opening a door for someone: it provides pleasure for both of you, and reciprocity is not immediately required.

The second world, the one governed by market norms, is very different. There's nothing warm and fuzzy about it. The exchanges are sharp-edged: wages, prices, rents, interest, and costs-and-benefits.

Such market relationships are not necessarily evil or mean—in fact, they also include self-reliance, inventiveness, and individualism—but they do imply comparable benefits and prompt payments. When you are in the domain of market norms, you get what you pay for—that's just the way it is.

Dan holds the opinion that when you take a social norm and try to replace it with a market norm you typically, for lack of a better word, f@#ck things up. He explains this much more articulately that I would be able to describe it, using what happened with the fining incident in Israel:

But the Real story only started here. The most interesting part occurred a few weeks later, when the day care center removed the fine. Now the center was back to the social norm. Would the parents also return to the social norm? Would their guilt return as well?

Not at all. Once the fine was removed, the behavior of the parents didn't change. They continued to pick up their kids late. In fact, when the fine was removed, there was a slight increase in the number of tardy pickups (after all, both the social norms and the fine had been removed).

This experiment illustrates an unfortunate fact: when a social norm collides with a market norm, the social norm goes away for a long time. In other words, social relationships are not easy to reestablish. Once the bloom is off the rose—once a social norm is trumped by a market norm—it will rarely return.

For the passionate software and rig engineers who worked at Multiplitaxion Inc, coming to office in the morning and working passionately for problems that were thrown their way was a social norm. What the time-policy at Multiplitaxion Inc did, was to take the social norm and mix market elements to it.

What Multiplitaxion Inc did with this policy, in the words of the book was much like, paying your mother-in-law for a fantastic thanksgiving party or for that matter paying your wife for her love.

Mixing social and market norms usually creates odd situations for everyone involved. If you lead a team or run an organization, it is hugely important that you realize the social norms that exist within your organization. There are things that people might be doing as a part of their existence in the 'social world' and the moment you try to reward or punish them using market norms, you are likely to create awkward situations and policies that backfire in ways you never thought.

Go ahead, use social norms heavily in your organization and when they are in place, don't ever try to replace them with market norms, because if you do, you just might f@#ck things up.

posted on Friday, June 11, 2010 8:30:00 PM UTC by Rajiv Popat  #    Comments [0]