free html hit counter
Posted on: Friday, July 17, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 6.

Let Your Corridors Carry Your Stories.

During the early days of my career as a programmer; I was hired at Multiplitaxion Inc; where; besides doing my job as a programmer; I was given random chores that other 'respectable-programmers' of the organization found too insulting to take up. The chores ranged from formatting documents; cleaning up HTML; uploading build files on production servers; to ordering food for programmers who were going to work late and fixing lose network cables for people.

Chores that laid the foundation for; and helped me understand the importance of becoming a one man army.

Time moved forward; one day at a time and I found myself working on these chores besides honing my programming skills.

Then one fine morning; years later; I found myself leading a team.

This was soon followed by leading multiple teams.

It was on another fine morning; that I was told that I someone who was very 'senior' and then a quite few people at work started listening to me.

Years later; every time I discussed those early painful times; what I learnt from those times and how those times changed Multiplitaxion Inc; forever; with young and bugging engineers; I started getting funny glances from senior-programmers and managers alike.

Some mildly hinted that the young-and-budding-developers working in teams that report to me might start respecting me lesser if they came to know of my humble starting; stupid failures and the deep scars I had received early on in my career.

Others felt it might have an impact on the overall organizational image.

'Why share stories of your or your organization's humble past with someone who is reporting to you?' --- some wondered.

Rosa Say describes the idea of sharing your own and your organization's past through stories much more articulately than I will be able to describe it. She explains:

Every company has a storied past. Are you aware what yours is?

More importantly, do you know why your stories are so important?

When old timers tell the newbies stories about “the good old days,” or “how it used to be here,” or “the first time we ever did this” what are they so fondly recollecting? Why in the world do they keep talking about past events, often making the retelling far more wonderful sounding than you remember actually living the experience of them?

Is there any value in this memorable nostalgia?

When stories are told in the spirit of retelling your company history, your storytellers are often capturing the memorable parts; what they remember is largely what they want to keep alive because it felt very good to them at one time.

Stories of what had been give us a look back at those things we once believed in, and want to keep believing in. They reveal the values which had bound us together and still do, and why in the aftermath of the story’s events we kept pushing upward and onward.

They often chronicle successes and achievements, and tell of what people feel was a victory, because by nature we want our stories to be good ones; no one likes to recount their failures.

However whether victory, mistake, or outright failure, our stories undoubtedly recount lessons-learned too important to be forgotten. We feel we can keep learning from them, and we tell the story to re-teach the lesson.

Stories from your organizations past and sometimes your professional past can be humbling and painful. When you lead a team and find a few people listening to you; it's easy to put yourself in an ivory tower; shit-can; hide and never talk about all those humbling experiences from the past that taught you so much or made your organization or your team what it is today.

Not sharing these stories; is safe.

Not sharing these stories ensures that everyone in your team continues to respect you and your organization.

Not sharing these stories allows you to continue depicting yourself as this super-successful-guy-who-never-gets-anything-wrong and your organization as the-place-that-was-always-perfect.

This approach; dear reader; has just one problem however --- it is your first step to becoming a genuine prick who is always busy protecting his and his organization's so-called-always-successful-image.

Accept it or not; every organization has stories --- stories of success; stories of pathetic failures; stories of things done right; stories of things done wrong; stories of victories; stories of failures; stories of shipping crap; stories of not shipping crap and sometimes even stories of colossal fu@#kups or total disasters.

How many of these stories make it to the corridors of your organization and flow through them; letting your builders; learn from your organization's past?

Accept it or not; every manager has stories from his professional life --- stories of doing a few things right; stories of doing a few things wrong; stories of heroism; stories of pathetic failures and even stories of colossal fu@#kups orchestrated by his very own self.  

Look around you.

How many of these stories about your organization, your team or your managers are you aware of?

If you answered 'none' you might be working with a bunch of pricks trying to protect their 'so-called-successful-image'  by shit-caning their failures.

Remember; management is all about no secrets and an environment where stories don't flow through the corridors; cannot be a fun filled environment for genuine builders.  

Which stories about your organization and your managers are you aware of?

Do these stories give you a clear picture of your organization's and manager's professional past?

Do these stories tell you about organizations culture chart?

How many stories of your own professional successes and fu@#kups that happened in the past; are you comfortable telling people who work with you?

What's your story; dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Friday, July 17, 2009 10:19:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, July 16, 2009 by Rajiv Popat

Trying To Publish Posts With No Typing Errors Can Make Your Blog Safe-And-Boring.

Honest confession: I am not exactly a rock star when it comes to spelling.

To be honest; I suck at spellings and I make random typos all the time.

The very idea of writing a post without a decent spell-checker makes me cringe.


Because I hate typos; specially when I am the one who is making them.

Spell-checker for me are a profoundly important.

I consider spell-checkers to be an invaluable tool for both amateur and veteran writers.

Having said that; anyone who writes; knows that spell-checkers are far from perfect. Which is probably why; every post I write; goes through more than one round of editing followed by a huge deal of proof reading. Typically; the branding; formatting; editing and proof reading of each post on this blog takes as much time as the process of writing the post itself takes.

While all veteran bloggers will tell you that spell-checking and proof reading everything you post; meticulously; is hugely important; after a point of time in your life when ideas start torturing you till you set them on a concrete post you begin to wonder just how much effort should you be putting into proof reading of each post when the same time could have been used writing about new ideas that will not let you go till you turn them into a fresh posts.

Long story short; publishing a post is pretty similar to shipping software. You have to walk the fine line between quality and shipping. Of-course your posts are shitty; but if they sit on your hard-disk gathering dust waiting to become perfect 'one day' they are worse than shitty.

Penelope Trunk describes this much more articulately than me in her post on typos while writing blog posts. She explains:

Will everyone please shut up about the typos on blogs? Show me someone who is blogging every day and also complains about someone's typos. Just try. See? You can't. Because anyone who is trying to come up with fresh ideas, and convey them in an intelligent, organized way, on a daily basis, has way too many things on their plate to complain about other peoples' typos.

Penelope's argument against spending time on spell-checks and countless rounds of proof reading stands around five simple pillars:

  1. Spellchecker isn't perfect.
  2. Spelling has nothing to do with intelligence.
  3. You don't have unlimited time, so spend it on ideas, not hyphens.
  4. Perfectionism is a disease.
  5. Use the comments section for what matters: Intelligent discourse (not parsing grammar).

If you are someone who posts using a WYSIWYG editor and doesn't even bother finding a decent blog writing tool; the discussion on Penelope's post or this post is clearly not for you.

On the other hand if you are someone who spends a huge deal of time worrying about typos on his blog posts and does multiple rounds of proof reading followed by editing; I would highly recommend Penelope's Post on this topic.

It is worth a read.

Shipping regularly; whether it is in your project, code or blog-posts; is a rewarding and fun filled exercise.

Much more rewarding than constantly worrying about perfection and playing it safe by writing less and writing perfect.

Remember; 'Don't-Worry. Be-Crappy'.

Put a decent bit of effort behind editing, proof reading and spell-checks; but don't be obsessed with these.

After all; your participation and contribution is much more important.

Besides; once you have shipped; you can always Rinse and Repeat.

If you have posts sitting on your hard-disk gathering dust because you are going to 'make-them-better', proof reader them, or spell-check them 'someday'; may I suggest; dear reader; that you ask yourself if they represent an idea worth sharing; and if the answer is yes; consider posting them out.

Not doing so can make your blog safe-and-boring.

Then continue to fix your posts as you move forward.

I do it all the time; and if people complain about their RSS Readers showing an old post as un-read when I fix it later it's easy to blame it all on Pops.

On a side note dear reader; if you find a typo on this post or anywhere on this blog; please do continue leave me a generous comment or email just like some of you have done in the past. I assure you; that the typos will be fixed and you will be thanked sincerely.

After-all; I hate typos; as much as you do.


posted on Thursday, July 16, 2009 10:59:45 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, July 14, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 5.

Software Terror Cells.

Jeff Atwood at Coding Horror had a hard time understanding how open source projects work when he found out that the five thousand dollars he donated to ScrewTurn Wiki was lying idle and unused in the bank; while Dario Solera; the product owner couldn't think of one way to spend money in over four months.

John Galloway elaborates this phenomenon using a unique perspective on open source software development. John explains:

Open Source is to Traditional Software as Terror Cells are to Large Standing Armies. if you gave a terrorist group a fighter jet, they wouldn't know what to do with it. Open source teams, and culture, have been developed such that they're almost money-agnostic. Open source projects run on time, not money. So, the way to convert that currency is through bounties and funded internships. Unfortunately, setting those up takes time, and since that's the element that's in short supply, we're back to square one.

What's interesting; however; is the fact that these 'software-terror-cells' are now rapidly becoming a part of everyday life; and that dear reader; is a good thing.

The idea of guerilla warfare isn't something that is now isolated to open source. It is rapidly becoming; and to a large extent; has already become a part of everyday organizational life.

One 37Signals

It amuses me to just count the number of discussions revolving around 'how-does-37-Signals-make money' that I have with folks from multiple organizations around the world. As much as I enjoy these conversations; there are three things that are really amusing about these conversations.

  1. On one hand you have the whole wide world of software development and the organizations in it wondering how 37Signals is making money.
  2. On the other hand you have 37Signals who with their team of eight developers doesn't really 'have to' to make millions in order to survive.
  3. Every 'enterprise' out there; that needs a couple of million each year just to keep it's payroll moving; wants to be the next 37Signals.

What is amusing is that while the rest of the software development business world is busy trying to figure out the business model of 37Signals and how 37Signals makes millions; the guys at 37Signals are; maybe not through a deliberate strategy; engaging in what Joel Spolsky calls Fire and Motion. Joel talks about the basic idea using his experience as a Israeli Paratrooper. He explains:

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.)  The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

Clearly; 37Signals is pretty much electing to be a software-terror-cell by choosing to grow by not growing. If you gave 37Signals a hundred programmers they probably wouldn't know what to do with them. Put simply; 37Signals is a self sustaining team of seriously kick-ass programmers or genuine builders and story-tellers rolled into one; who can organize themselves and function as a software-terror-cell. A software-terror-cell.

A terror cell that continues to confuse the rest of the world in general and their competition in particular by constantly engaging in fire-and-motion.

Six Thousand Microsofts

Early on in my career we did some work at the Microsoft silicon valley campus. During my short stay at Microsoft I learnt something which was later articulated by another Microsoft employee. The statement was profound and left a deep impact on me --- Microsoft isn't one company. It is just a collection of six thousand Microsofts; and a majority of these Microsofts happen to be successful.

How Many Terror Cells Does Your Organization Have?

Once you've gone out there and hired some seriously kick-ass programmers; your job as a CTO; Vice President; Manager or whatever fancy designation you hold; dear reader; is to get out of their way and let them form self-sustaining-terror-cells which can continue to fire-and-motion day after day.

Try to organize your genuine builder in large standing armies and chances are; you lose.

I don't care how big your organization is; how big your team is; or what 'vertical' of enterprise software development your organization deals with - if you aren't letting your builders organize themselves into small; low maintenance software-terror-cells specializing in genuine innovation with constant fire-and-motion; chances are that there is a huge body shop out there somewhere in India which can take your organization and all it's jobs sitting ducks.

Not to mention of-course that every time you try to organize a large standing army; you screw up your chances of building a remarkable work and fun environment; just a little bit more.

Now go hire some seriously genuine builders and story-tellers. Then once you've hired them go form your own software development terror cells and learn how to fire-and-motion.

I wish you good luck.

How many successful self-sustained software-terror-cells does your organization have?

How many large standing armies is your organization feeding?

Are you indulging in fire-and-motion on your competition or are you being taken down by your competition sitting ducks; dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Tuesday, July 14, 2009 9:08:23 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, July 10, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 4.

Criterias For Hiring Genuine Builders Who Can Create Remarkable Environments If Left Alone.

Recruiting individuals for your team and organization is an art. An art at which I've seen so many different Vice Presidents, Senior Managers, Directors, Team Leaders and Developers suck that you begin to wonder if we are basically an industry of the incompetent recruiting the incompetent.

With this post my intent and attempt; dear reader; is not to teach you how to hire better people for the job. That; is a topic that can cover a book in itself.

What I intend on doing with this post however; is giving you a few qualities you need to look out for in your candidates while you are interviewing them. Keep these qualities in mind and work hard to develop your very own personal litmus tests around these basic qualities. Do this and you should have a good shot at eliminating most programmers-who-cannot-program; whiners and the fake rock-stars before it is too late.

Ready for some qualities you need to look out for in the candidates you interview?


Let's begin.

Thick skinned and down-right shameless.

Qualities of shamelessness and thin-skinned-approach-to-professional-life are things which usually take less than a few minutes to figure out.

As you talk to candidates try to drive the discussion to a point where they need to talk about a couple of failed projects from their career. How does the candidate talk about failures; is he objective about what went wrong; is he pointing fingers; did he learn something from his colossal failures; does he seem interested in sharing what he learnt or is he just interested in shit-canning his failures and hiding them from you.

Most great builders are down right thick-skinned and they fail often. They are often completely shameless about their failure and carry it with a sense of humor. After technical competence; this is the first quality that I tend to look for in people I hire.

Genuine Builders Are Nice When The Sky Is Falling

Ever been late to an interview? I've been there; you know the typical bad day where you are running late by a few minutes and you start the interview with an apology for being late. I stared in awe as the candidate; with multiple years of development experience; reminded me thrice that I was late and continued to give me a rather intimidating look.

If you cannot be nice to me when I start the interview five minutes late; it is safe for me to assume that you cannot be nice when the project is running late by a couple of weeks. 

I'm not saying that you go in five minutes late during every interview; but figure out a litmus test that tells you if a person is just nice; or he is also nice to work with and nice when the sky breaks lose.

Genuine Builder Know Not; And They Know That They Know Not.

Ask difficult questions. See how frequently you hear the words 'I do not know' during the interview. Most candidates find it difficult to even utter these words once during an interview. Others utter these once or twice but start lying and bitching the third time on.

Remember; genuine builders don't know a lot of things and they are rather well aware of their own weaknesses or limitations.

One of their major strength is that they know that they know not. 

Body Language

The art of observing candidates using thin-slicing is a technique described in books like Blink. Of-course you don't have to make split second decisions but anyone who he constantly avoiding eye contact; giving you shitty indignant looks when you correct them at their answers or looking at the cell phone screen as you speak to them in an interview is clearly not someone you want on your team. 

Agree To Disagree 

During every interview I try to make it a point to play the devil's advocate and disagree to the candidate on at-least one technical or design related topic. Disagree; then observe how the candidate handles disagreement.

Does he argue objectively; are there elements of contempt in his expressions as the disagreement continues.

If you were to hire him; there are going to be many heated arguments which are work-related. At the end of the day you want to hire people who have strong opinions weakly held; people who can agree to disagree and people who do not indulge in acts of bozoism.

Critical and Open but Not an Asshole

People who can provide constructive criticism are rather rare. Assholes who randomly criticize things without rhyme-or-reason are a dime a dozen. Unfortunately there is a very thin line that differentiates builders who can provide constructive criticism or whiners who specialize in de-motivating and shattering individuals.

Drive the discussion around the candidate's current project. Try to find out what he feels about the implementation. Anyone who feels that they are doing everything correct is a blatant-compulsive-liar. Anyone who provides random criticism without also mentioning what could have been done to avoid or fix what is wrong; is a down right whiner.

Anyone who is overly critical and wants to change everything in one day is a whiner too.

Track Record

I continue to be amazed at just how many companies ignore this. When one of my bosses told me a deep dark secret of figuring out a candidates possible duration in the organization if you were to hire him; the idea sounded absurd. Like all good ideas; it was absurd but true.

"Anyone who has changed a job each year; for the past three years is not going to stay in your organization for more than a year." --- I was told.

As stupid as it sounds; look at most resumes and you'll see patterns around how frequently people leave jobs. How frequently they hop from one project to another. Unless you are a one in a million example; chances are that you are not going to be able to change this track record. So; if you are looking for a candidate who can be seriously committed; anyone who has changed three jobs in last three years; at the rate of a job a year; is out.

Reason For Leaving

This is one thing that says a lot about the person you are interviewing. I continue to be amazed at just how many candidates lie blatantly when it comes to their reasons for leaving their past job. I also continue to be amazed at how easily they get caught.

I'd have a lot of respect for anyone who leaves a job because of difference of opinion. Much more respect than I can have for someone who leaves for a slightly higher paycheck and does that year-after-year. Build some simple litmus tests around reasons for leaving and you'll discover that finding out true reasons for leaving is not hard.

Passionate About Something

As they say --- passion is something that cannot be faked. You either have it or you don't. Ask the candidate which technology does he absolutely love working on. Then let him speak about it and hear him speak.

Passion is easy to detect. Having said that; the paradox of detecting passion is simple --- it takes a passionate programmer to detect and understand passion in another programmer.

If you are yourself a pay-check-programmer whose resume is floating in job portals around the year; and you believe in 501 programming spotting passion is going to be very difficult.

Genuinely Interested And Connected

Most programmers don't read books. Having said that; when I come across a programmer who hasn't read a single book on programming in his entire life; do I really want him on my team?

A programmer who doesn't read programming books is much like a movie actor who doesn't like watching movies. Disconnected and Disinterested.

Does your candidate have a favorite author? Does he work for an open source project? Does he read technical books? Does he have an active blog that he updates regularly with meaningful content? Does he answer forums?

If the answer to most of these is no; he's probably not genuinely interested or connected to programming.

You'd actually do him a favor by gently nudging him out of your office and if possible; nudge him to a different profession.

How much time has the candidate spent on your corporate website? That tells you something about his interest level in the organization. Even today; I continue to be amazed by the number of people who come down for an interview without even taking a quick glance at the company's website.

Both of these are clear examples of the candidate not being genuinely interested in programming in general and your organization in particular.

Weird But Acceptable

Genuine creativity is un-conventional; sometimes even ugly and down right weird. During my course of interviewing career I've interviewed and hired candidates ranging from folks who could barely speak English to folks who were so disappointed with BDUF approaches to software development they just couldn't stop talking.

If there is something weird or unconventional you can spot in a candidate during the small duration of an interview and it is not a harmful weirdness; embrace it. People who get into office at nine and have utmost respect for all the rules; do not know how to bend them and make small or big dents in the universe.

My work experience ranges from working with people who talk about drinking "one gigabyte of alcohol" in an office party to poets who are passionately inspired by other poets. I've always embraced weirdness and have considered it a part of the whole creative process.

Of-course; I've seen a couple of managers have their share of one or two isolated bad experiences where they landed with a kleptomaniac; without knowing they were hiring one; but then that doesn't make all forms of make diversity or even weirdness --- bad.

Wearing slippers to office is acceptable; stealing client's headphones is not.

Unless the weirdness is bad; harmful or un-acceptable --- embrace it.

Nothing Beats A Genuine Builders Recommendation

With all these criteria I might have already started sounding like someone who has years of wisdom at the whole recruitment process. But clearly all this wisdom doesn't work all the time. Which is why; when a candidate referred by one of the top-most-builders in my team fails my interview criteria; but the genuine-builder who referred him has worked with him in the past and is willing to vouch for him; here is what I do --- I shut up and recruit him.

Remember the good old saying that they used to teach you in junior school - 'birds of a feather flock together' --- Your hugely underpaid school teachers knew nothing about the importance; what they were teaching you; would have in your professional life.

If there is something that I've learnt about recruitment after being involved in recruitment for years; it is that idiots usually tend work with idiots and idiots to have friends outside work who are also idiots and they tend to refer these idiots for interviews.

Having said that the same lesson also applies to genuine builders. Builders; usually tend to hang out with other genuine builders. When wondering what you should do with a candidate one of your best builder worked with in a previous organization and has recommended --- remember --- chances are that the seriously kick ass builder who recommended him probably enjoyed working with the candidate because the candidate in question was a seriously kick-ass builder too.

You are never going to find out enough about a candidate during an interview.

When your top most performers refer someone and are willing to vouch for them; shut up; and hire them.

I do not claim of this list being an extensive list of 'all' the qualities you need to look out for; but look out for candidates who do not have most of these qualities and you've filtered a huge part of shitty-whiners out which just makes your chance of recruiting genuine builders that much better.

What are things; besides technical competence; that you look for in a candidate before you bring them on to your team?

How many of these criteria were you actively monitoring or trying to access during interviews you conducted in the past?

Which other criteria do you look for in your candidates, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Friday, July 10, 2009 10:58:12 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, July 9, 2009 by Rajiv Popat

Behind Every Failed Project Are Reasons That Are Simple And Straight Forward.

Microsoft Solutions Framework Essentials: Building Successful Technology Solutions - a book on Microsoft Solutions Framework (MSF)  by Michael S. V. Turner talks about the Standish Group 10th Annual (2003) CHAOS Report which mentions that only 34% of the projects in a sample size of 30,000 projects are successful. A staggering 51% are badly challenged --- the kind I like to call 'successful failures'.

To add to that 15% of them take a nose-dive to a down right catastrophic failure.

When I was doing a post on the fact that the success or failure of your project depends on the competence of your team and not other complicated factors like 'lack of a systematic process' one question that kept pinching me was why didn't project managers around the world just 'get it'. Why did they keep finding refuge in complicated terminology and jargons.

To find the real answer to the question; dear reader; you have to dive in the human mind and how it works. Besides the fact that complicated reasons give young and budding managers a curtain of crap to hide behind; I am also starting to believe that there is more to this phenomenon that just the prickdom of the young and budding managers or the desire of developers to save the skin of their other fellow developers.

Study how the human mind thinks or works and you'll find that there are two primary reasons why project failure analysis never produces any real concrete reasons for the project's failure.

The first one being; the fact that the human brain is often incapable of comprehending the implications small things can have on our lives and our projects. Malcolm Gladwell describes this phenomenon in his book - The Tipping Point - where he offers his readers a simple hypothetical puzzle:

Consider, for example, the following puzzle. I give you a large piece of paper, and I ask you to fold it over once, and then take that folded paper and fold it over again, and then again, and again, until you have refolded the original paper 50 times.

How tall do you think the final stack is going to be?

In answer to that question, most people will fold the sheet in their mind's eye, and guess that the pile would be as thick as a phone book or, if they're really courageous, they'll say that it would be as tall as a refrigerator.

But the real answer is that the height of the stack would approximate the distance to the sun. And if you folded it over one more time, the stack would be as high as the distance to the sun and back.

This is an example of what in mathematics is called a geometric progression.
As human beings we have a hard time with this kind of progression, because the end result — the effect — seems far out of proportion to the cause.

Bring this to the world of software development; and we often tend to miss out of the ramifications of slightly in-competent programmers in our teams or organizations. Anyone who reads legendary author Steve McConnell knows that a competent programmer is ten times more effective than an incompetent one.

Having one ass-hole or a monkey is enough to screw up your next project.

So; that lowering of the selection criteria during your interview process obviously has a impact which is large enough to cause your projects to go for a catastrophic nose-dive while your brain struggles to comprehend how relaxing the selection criteria in an interview 'slightly' can cause projects to fail.

The other part of the answer; lies in the fact that that human beings by their very nature are pathetic risk assessors. Steven D. Levitt and Stephen J. Dubner describe this problem much more articulately in their book Freakonomics. The explain this phenomenon using two simple examples. In the first example they site the example of deaths caused by having guns in home; vs. deaths caused by having swimming pools:

Consider the parents of an eight-year-old girl named, say, Molly. Her two best friends, Amy and Imani, each live nearby. Molly’s parents know that Amy’s parents keep a gun in their house, so they have forbidden Molly to play there. Instead, Molly spends a lot of time at Imani’s house, which has a swimming pool in the backyard. Molly’s parents feel good about having made such a smart choice to protect their daughter.

But according to the data, their choice isn’t smart at all. In a given year, there is one drowning of a child for every 11,000 residential pools in the United States. (In a country with 6 million pools, this means that roughly 550 children under the age of ten drown each year.) Meanwhile, there is 1 child killed by a gun for every 1 million plus guns. (In a country with an estimated 200 million guns, this means that roughly 175 children under ten die each year from guns.)

The likelihood of death by pool (1 in 11,000) versus death by gun (1 in 1 million-plus) isn't even close: Molly is roughly 100 times more likely to die in a swimming accident at Imani's house than in gunplay at Amy's. But most of us are, like Molly's parents, terrible risk assessors. Peter Sandman, a self-described "risk communications consultant” in  Princeton, New Jersey, made this point in early 2004 after a single case of mad-cow disease in the United States prompted an anti-beef frenzy.

"The basic reality," Sandman told the New York Times, "is that the risks that scare people and the risks that kill people are very different."

Bring the idea over to your project and evaluate what is more likely to kill your project; having incompetent assholes; no customer feedback and a thousand other really small things or lack of a 'formal communication plan and scope control document'.

Most so called traditional project managers around the world will give you hours worth of free lecture on why a Process (with a capital 'P') is vital to your project.

Why they do this can be best explained with the whole idea of perception of control called the 'control factor'; described rather articulately by Steven D. Levitt and Stephen J. Dubner  in Freaknomics. The book explains:

But fear best thrives in the present tense. That is why experts rely on it; in a world that is increasingly impatient with long-term processes, fear is a potent short-term play. Imagine that you are a government  official charged with procuring the funds to fight one of two proven killers: terrorist attacks and heart disease. Which cause do you think the members of Congress will open up the coffers for?

The likelihood of any given person being killed in a terrorist attack are infinitesimally smaller than the likelihood that the same person will clog up his arteries with fatty food and die of heart disease.

But a terrorist attack happens now; death by heart disease is some distant, quiet catastrophe. Terrorist acts lie beyond our control; french-fries do not. Just as important as the control factor is what Peter Sandman calls the dread factor. Death by terrorist attack (or mad-cow disease) is considered wholly dreadful; death by heart disease is, for some reason, not.

Obviously; the young and budding manager is more concerned about the 'Process' than he is concerned about 'hiring'. 'Change of Process' and 'Control' mechanisms happen now. Besides; the standard issues that most BDUF processes try to address are just an inherent part of software development. The chaos can hardly be eliminated.

Trying to do formalized 'Change Control' mechanism instead of embracing change and focusing on quality people; is much like trying to control terrorists when the French-fries of simple and subtle incompetence might be destroying your project right now as you read this.

Understanding the human mind has huge implications on how we run and manage our projects. Understanding three things when analyzing project failures is hugely critical:

  1. Our brain has a hard time relating to how small things; like lack of customer feedback; slightly lowered selection standards etc. can have huge impacts on the project.
  2. We are terrible risk assessors; what seems to be the most probable cause of failure for project to us; most probably; isn't.
  3. The 'control factor' can make you do stupid things and lose focus on the much bigger problems at hand.

Now; you can go there and spend thousands of man-hours and dollars defining a 'Process' (with a capital 'P'), a formal 'scope control' document, a formal 'change management' document, and a formal 'risk assessment plan' followed by a million other documents which make you feel in 'control' or you can hire a team of seriously kick ass programmers; set them lose and spend your time listening to your customers.

The complicated reasons why you were told your last project failed; probably aren't true.

With this post; all I am trying to do; dear reader; is suggest that maybe; just maybe; your project failed because of completely different reasons which were not as 'sexy'; not as 'urgent' and not has 'seemingly big' as 'A Formal Process'.

Now; you can get back to watching the CNN report on terrorism on Television as you munch on super-sized packet of french-fries and then when you get a heart attack go blame the terrorists. As absurd as that sounds; and as unlikely it is that you will do that in your real life; that is precisely what most managers do when it comes to project management.

I leave you; dear reader; with a thought worth harping on.

Go take a journey into the depths to time and try to figure out why; any project that you may have been a part of or you may have witnessed failing; failed.

This time; for a change; try to be completely honest to yourself.

Maybe the real reasons for the project failure were not all that complicated after all.

Remember - behind every failed project are reasons which are simple and straight forward; sometimes so simple that our brain has a hard time comprehending them.

posted on Thursday, July 9, 2009 11:46:24 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, July 7, 2009 by Rajiv Popat

Avoiding Never Ending Arguments And Flame-Wars By Using (Twitter) Hash-Tags.

With only three visitors; my mom, me and you dear reader; this blog is a highly unlikely target for threats and intimidation. Having said that; what I often have a problem with; is the fact that; every now and then; I find myself defending my ideas from countless seemingly harmless attacks of Bozoism. The count of these isolated incidences seem to be slowly creeping up with every passing month.

While I completely believe in having strong opinions which are weekly held and the idea of having direct open arguments; it is when these arguments become completely illogical, baseless and turn into personal attacks; they start stressing you out emotionally.

Given all the incidents, emails, conversations, discussions and a few flame-wars that I've witnessed in the last one month I think it's time to wear the gloves and take up a stance that is both defensive and aggressive when it comes to the ideas and opinions expressed on this blog.

This post is about building a few of these psychological constructs that allow me to take that aggressive stance but then switch over to a defensive mode and escape without getting burnt when the flame-wars begin.

Acts Of Bozoism

When I started this blog; and started writing about my thoughts on software development; the idea was to turn my personal experiences and random thoughts into a coherent stream of ideas that others can connect to.

Doing that; has been fun.

It has taught me more than I ever hoped to learn and introduced me to a small number of really smart people I feel lucky to have known. The very start of this blog is an interesting story of me meeting and interacting with a bunch of really smart programmers; that I would have never had the opportunity to work with otherwise. I should probably do a separate post on that story sometime later.

To be honest; the tiny little blog with a small readership; has even brought me professional opportunities which I humbly and politely turned down. This was something I hardly expected could happen. Even though I write for none of these benefits; getting these as a free bonus has been a fun experience overall.

Having said that; lately; I've also started realizing that the act of turning your ideas into something that you can ship out to the world; gives any anonymous bozo out there the right to email you and pass random judgments on not just your work; but your thought process and even your way of life.

This post is supposed to give me some psychological constructs to dodge these random acts of Bozoism.

The Argument Continues

Besides the random acts of Bozoism; another form of argument that I am starting to have serious questions on; is the perfectly-logical-but-never-ending-type.

This is the kind where someone starts a discussion around a seamlessly harmless topic like:

'Hey Pops; do you think we should have detailed project plan for our project?'.

That's when you explain how utterly meaningless and over-rated the whole idea of project-plans is.

'Yes; but you know; this project is different; it's huge; we're building an enterprise system.' --- you are told.

Yes; we've all seen that horse-shit before.

You try to explain that; but it hardly helps.

It just results in another 'Yes-but' argument.

Now; don't get me wrong; there is absolutely nothing wrong with 'Yes-But' discussions. It is just that; when they cross thirty emails back and forth; or five hours of conversation in a cafe; without any clear indicating of coming to an end that they start stressing you out; mentally and emotionally.

You want to help the other person. You want to influence him; which is why you decided to participate in the discussion in the first place.

Having said that; it's when the 'Yes-But' discussions start stressing you out and you find yourself defending your ideas; you realize; that maybe the other person wasn't looking for help. Maybe he was looking for confirmation of his own ideas. This is when you realize that; maybe his ideas mean to him what your ideas mean to you.

That's when you realize that maybe; having a formal Microsoft Project Plan is as important to him as having kick ass developers in your team is important to you.

He is just not ready to throw his project plan out of the window yet.

Put simply; that's when you realize that maybe this isn't just a friendly battle of really strong opinions weekly held; it's a completely different thought process; a different core value or totally different way of life.

When this happens you want to give the person due respect for having a different opinion; wish him luck with his thought process and find an escape route to get out without getting burnt mentally or emotionally.

Besides the random acts of Bozoism; this post is supposed to give me some psychological constructs to end the 'Yes-But' arguments which otherwise have a tendency to continue and end up causing everyone involved a lot of stress.

Twitter Tags To The Rescue.

For all those of you who have been watching my twitter account (@Thousandtyone) activity; I am clearly becoming much more alive and involved at twitter. One thing I find really amusing about twitter is the whole idea of Twitter-Hash-Tags.

The whole embedding of Hash-Tags in Hundred-And-Forty characters is such an amusing idea that we would all be so much happier if; besides using it in twitter; we used the same approach in our lives.

Going forward; dear reader; I would like to propose the use of a few Hash-Tags which I will be using in verbal discussions; emails; twitter and sometimes even comments of this blog.

Put simply; these tags are supposed to provide you ammunition against random acts of Bozoism and Yes-But arguments and allow you to dodge them peacefully without get burnt in a flame-war. 

Lets talk about these tags.

End Of Bozoism - #EOB

If you find this tag embedded in an email; a comment or a twitter message that I send to you; this is my humble way to tell you that I think the argument is turning into a personal attack or a flame-war and that I am pulling out.

When this happens; you are free to continue to flame me; however; you will not hear back from me on the topic.

As far as I am concerned; even if I have arguments to present and more logical thoughts to discuss --- I am done.

End Of Argument - #EOA

If you find me embedding this tag in an email; a comment or a twitter discussion this is my humble way of telling you that the discussion is perfectly logical and that I am loving the ideas and opinions presented.

Having said that; I do not agree with them.

Yes; I do have some more logical arguments; but If you disagree with my ideas with points presented so far; it is highly unlikely that presenting more logical arguments will help.

The discussion has turned into a Never-Ending-Yes-But-Discussion where both of us seem to have not just different opinions but a completely different thought process or completely different set of core values and continuing the discussion on this topic; in all probabilities will not bring us to a conclusion.

I respect your ideas and I hope you respect mine.

You are free to continue the discussion and present more of your ideas but you will not be hearing from me on this discussion even if I may be tempted to present just one more 'Yes-But' argument from my side.

When I include this tag; I'm just saying; as far as this discussion is concerned --- I am done.


Alternately; I will also be using the End-Of-Yes-But-Discussion (#EOYBD) which means the same thing.

The Real Intent of These Hash-Tags

While #EOB, #EOA or #EOYBD sound rude the very first time you hear them; but I assure you dear reader; they are not. The intention here is not to prove that the other person is wrong; or too stupid to argue with. The intention is to give him due respect for this thoughts; acknowledge that there is a difference of opinion on one topic; that we can let the difference of opinion stay and get along really well by talking about other areas where we tend to agree more.

You're Welcome To Use Them Too

Going forward; every time I see myself getting into a argument that seems to be going nowhere or when the situation demands; I might be using these tags. You; dear reader; are free to use them too.

I am hoping that these tags allow you to hugely lower the need that you feel to indulge in discussions and arguments; specially when they become emotionally stressful; mentally tiring or seem to be having no definite end.

Go ahead; fell free to use them in your e-mails; twitter discussions; blog comments and any other arguments from which you want to back out; and quit by wishing others 'Best-Of-Luck'.

Go use them and have a stress free online existence.

I wish you good luck and just in case; if you do not agree with the whole idea of creating these twitter hash-tags; here is all I can say:



I wish you good luck.

posted on Tuesday, July 7, 2009 10:14:05 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Friday, July 3, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 3.

Screen And Pick People For Your Team Like Your Professional Life Depends On It.

A very senior manager at Multiplitaxion Inc, has picked a few candidates from the cream colleges out there based on IQ tests and Math questions. He expects me to on-board them on my team and begin their training.

I am looking at his condescending eyes as I speak the unspeakable - "I'll need to interview them again before they join my team. Not all will qualify."

Suddenly I find myself involved in an argument where I'm being asked if I feel that the selection criteria of Multiplitaxion Inc isn't good enough.

Breathe --- I tell myself.

My professional career as a manager at Multiplitaxion Inc, depends on who works on my team and who doesn't.

This is one thing where intimidation and pressure techniques will not work easily. 

No-one is joining my team; not till they give another interview and pass the team's selection criteria. Not till they convince me that they 'fit' and that they have at-least one super-power.

Of-course; they are all 'good' --- I am sure some even smarter than I am; but the question that is on my head is different.

How many of them can clear the litmus tests? --- I find myself thinking aloud.

The Litmus Tests

During the course of working with multiple teams which worked on some decently interesting products; we came out with a set of litmus tests.

Before we go ahead with the whole idea of litmus tests; it is hugely important; dear reader; that you know and understand one dirty little secret of recruiting genuine builders.

This is big.

So big that most managers go into denial when they are told this secret of recruitment.

Steve Yegge; explains this deep dark secret of recruiting genuine builders with true competence in his post on Smart-And-Getting-Things-Done. He explains:

The second prong, that of the ability to recognize true competence, has major ramifications when we conduct interviews. That's what Joel was writing about in Smart and Gets Things Done, you know: conducting technical interviews.

How do you hire someone who's smarter than you? How do you tell if someone's smarter than you?

This is a problem I've thought about, over nearly twenty years of interviewing, and it appears that the answer is: you can't. You just have to get lucky.

So you can go out there; 'formalize' your interview process; conduct five rounds of interviews; check all the past experiences, educational background and take all the IQ tests you want but if interviews are your only means of selection; chances are; that if you are not lucky; you can land up with a hardcore whiner.

Now that you know you cannot pick the most genuine of builders without getting lucky; the best approach; to take; dear reader; is to eliminate as many whiners and the assholes as possible and throw them out of the pool before you get yourself blind-folded and throw the dart.

The more whiners you have been able to weed out before you take your pick; the higher your chances of picking the genuine builders will be.

This is precisely where the litmus tests of recruitment come in.

If you really want to understand what Litmus Tests are take a look at some out there. A very famous example of a litmus test for programming logic is the famous Fizz-Buzz example illustrated at Imran explains:

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call "FizzBuzz Questions" named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

While FizzBuzz questions act as a good litmus test for programming logic; multiple other litmus tests exist which can help you cover areas ranging from design; testing to general work interest and enthusiasm. Here are some examples of litmus test questions that you; dear reader; can use out of the box to access the overall technical competence, approach and attitude of the candidate.

Tell me any three technical questions that you can answer and then answer them.

Is the candidate lost; can he think of three questions he can answer confidently. Does he stick to simplicity or does he pick a complicated set of questions to impress you and then ends up blowing it. Based on the questions candidates pick; probe deeper and you know who not to hire.

Talk about three of your strengths and three of your weaknesses.

Most candidates when asked these questions describe their strengths rather articulately but come up with ridiculously stupid and artificial weaknesses; the I-cannot-lie weakness being the stupidest example. When you cannot talk about your weaknesses openly it just tells me that either you haven't done any soul-searching what so ever in your career; or you are a blame driven asshole who points a finger at others every time the sky starts falling.

Talk about one project where you were hugely successful and one where you failed miserably.

Any candidate who tells you that he hasn't ever failed falls in either one or all of these categories:

  1. He has never taken a chance and has always remained in the realms of mediocrity.
  2. He is a compulsive liar.
  3. He goes in denial mode every time he encounters a failure. Chances are that he loops in the infinite loop of failure all the time.

Failures in your professional life are just as important successes. After all if you haven't had seriously colossal fu@#k-ups and failures chances are; that you haven't learnt enough and that you're not going to be successful.   

The Thing About Litmus Tests.

"Ok Pops. I get the idea." --- you say.


Now you can go out there and create a few of your very own litmus tests. The one thing to remember about Litmus tests is that they are not supposed to help you pick the genuine builders for hiring. All they are supposed to do is weed the whiners out. Put simply; the fizz-buzz question; for example; will not tell you if a candidate is a good programmer; but it'll tell you if he is a bad one.

Go prepare your own set of litmus tests that are based on your selection criteria and weed out as many whiners as you can. Then take a chance and hope that you get lucky.

I wish you good luck.

What do you do to weed out whiners and pick genuine builders who; if left alone will automatically create remarkable work and play environments?

How many times have you been successful in picking genuine builders and how many times have you failed?

What litmus test questions do you use while interviewing candidates, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Friday, July 3, 2009 9:26:24 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, July 2, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 2.

Hiring - Where It All Begins And Ends.

Recruitment Managers at Multiplitaxion Inc, look at me like I am an alien talking a different language all together. I've interviewed a hundred people; rejected all of them and have proven beyond doubt that there is something wrong with my eyes and scanning abilities.

All hundred of the candidates interviewed cannot be idiots after all.

Or can they?

Sadly enough no one out of those hundred candidates seemed to fit the criteria of people I would love to work with or even closely match people I was already working with.

'If you take this approach we are never going to be able to hire anyone.' --- I am told.

A subtle nudge that is supposed to tell you that it's OK to lower your criteria and pick the best from what you are getting. We would then go out and make a big noise about hiring the best of the employees.

That is exactly what most organizations do.

Put simply; this is one phenomenon Joel Spolsky describes rather elegantly in his post on hiring the best. Joel explains:

Now, when you get those 200 resumes, and hire the best person from the top 200, does that mean you're hiring the top 0.5%?


No. You're not. Think about what happens to the other 199 that you didn't hire.

They go look for another job.

That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one.

So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%.

In the same article Joel also introduces you to the notion that genuine builders are not really going to be sending out their resumes and applying for a job:

In fact, one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all. I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives.

On the other hand there are people out there who appear to be applying to every job on I'm not kidding. They spam their resume to hundreds or thousands of employers.

A lot of times I can see this because there are actually hundreds of "job" aliases in the "To:" line of their email. (Some evil part of me wants to "reply-to-all" the rejection note I send them, but I usually overcome the urge).

What Joel is doing is pushing the idea of reaching out to really smart college interns and hiring them before they get a job opportunity anywhere else.

He is also pushing the idea that in case of genuine builder it is often your organization that might have to approach and quite literally beg them to join. Waiting for the resumes to show up in your inbox is not going to work. Neither is looking out for resumes on job sites going to be a very effective technique.

In multiple organizations around the world I've seen selection criteria come down merely by the virtue of the fact that a hundred candidates have been interviewed and none have been selected. When you cross the magical figure of hundred or more; suddenly; panic strikes. This is when organizations go out there and hire the 'best' out of the pool of idiots they interview.

Having your selection criteria crystal clear and not compromising on it is the first step to hiring a team of seriously kick-ass builders. Of-course Recruitment managers; and teams responsible for hiring candidates; are supposed to pressure you to go out and hire from the bucket of mediocre idiots that are being thrown your way. Providing these gentle nudges is a part of their job.

Most recruitment professionals and placement consultants are evaluated by the number of people that they place. It is therefore no surprise that the expert in them want you to lower your criteria. Most organizations out there actually have a whiner recruitment plan so they want you to lower your criteria as well.

Your job on the other hand is simple --- don't panic.

Hiring people who you are not fully satisfied with is your sure shot step to creating an environment that needs to be managed and anything that needs to be managed actively does not sustain itself in the long run.

Whatever it is that you do; don't panic; don't compromise.

I see multiple versions of the whole 'talented guys are limited'; 'we cannot be hiring all rock-stars'; 'we will never be able to hire at this rate'; arguments being thrown by multiple individuals and organization. Any organization that knows anything about software development turns a deaf ear to these arguments. Steve Jobs; for example; explains the process of hiring and how painful it can be rather articulately in his interview at business week:

Yes, it is. We've interviewed people where nine out of ten employees thought the candidate was terrific, one employee really had a problem with the candidate, and therefore we didn't hire him. The process is very hard, very time-consuming, and can lead to real problems if not managed right. But it's a very good way, all in all.

Most Recruitment professionals will frown when they read this. Steve Jobs; on the other hand; also has a reaction to the argument of managers and organizations not having the time to recruit people at this speed; which he describes rather articulately in the same interview with business week. He explains:

I disagree totally. I think it's the most important job. Assume you're by yourself in a startup and you want a partner. You'd take a lot of time finding the partner, right? He would be half of your company.

Why should you take any less time finding a third of your company or a fourth of your company or a fifth of your company? When you're in a startup, the first ten people will determine whether the company succeeds or not. Each is 10 percent of the company.

So why wouldn't you take as much time as necessary to find all the A players? If three were not so great, why would you want a company where 30 percent of your people are not so great? A small company depends on great people much more than a big company does.

Remember; of all the things that you are going to do to build a genuinely awesome work and play environment where builders thrive and flourish; recruitment is the most important.

It is so important I could quite literally do a complete book on it; but the whole point here is rather simple --- recognize the importance of hiring the right people; have a clear criteria for the team and whatever it is that you do; do *not* compromise on the people you hire.

If you can do that; most of the great work and build environment is pretty much going to happen automatically. If you don't you have lost the battle before it even begins.

Taking the simple approach of We-have-to-live-with-what-we-get does not cut it. All this approach does is create an army of whiners; faster than you know it.

What is your interview to ratio of candidates selected to the number of candidates rejected?

How many times have you been pressured or gently nudged; to settle for less when it comes to selecting candidates for your team?

How many times have you given in to the pressure, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Thursday, July 2, 2009 10:02:18 PM UTC by Rajiv Popat  #    Comments [1]