free html hit counter
Posted on: Tuesday, August 4, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 8.

The First Baby-Steps At Prickdom.

You've hired a young and budding engineer and made him a part of team of genuine builders.

This young and budding engineer; who for the purposes of this post we shall refer to as Jack; is serious raw talent --- gold waiting to be polished. He is working hard; putting his sweat and mind to what he does.

He is slowly becoming the young and budding rock-star of your team.

Jack earns his first round of salary hikes and promotions.

You are starting to feel a little proud of your pick; the rate at which he is growing within your own team and your organization.

Then; something creepy happens.

Things change as far as Jack is concerned.

Not the quality of his work.

The quality of his work is just fine.

He is still amazing as far as his work is concerned; but hidden admist the layers of complicated human behavior; you find that Jack has suddenly lost the innocence and the X-Factor that made him a rock star in the first place.

Slow subtle chances are becoming noticeable.

You are starting to see Jack have minor issues with people in his team.

Ego-tussles; really small ones --- sometimes with other developers; sometimes with with the office administration and HR guys.

An email or two where he criticizes and demolishes someone in his project team for their mistakes in front of everyone else.

The reasons could be numerous; but Jack; dear reader; is taking his first steps baby-steps to becoming a fully-qualified-asshole.

Professional Puberty.

Personally; I like prefer calling this process -- Jacks-Professional-Puberty.

Much like puberty --- professional puberty is process when a lot of confusing changes happen to people.

Take Jack's case; for example. During his professional-puberty Jack is delivering; he is becoming successful and to add to it; he is starting to get a sense that he is 'important' without having any true idea of the level of his importance in the larger scheme of things.

Professional puberty is a hard time; that most engineers or veteran engineers go through in their lives. Most people act really stupidly in this phase of their time. Even I did.

Here is the sorry part however --- a very few of us who go through the phases of professional puberty emerge as better human beings. Most others; turn into regular assholes and pricks that flock our world under fancy titles and designations.

Asshole Not Allowed.

How your environment deals with someone who is going through their professional puberty will to a large extent define the kind of culture that eventually prevails at your workplace.

When a young and budding engineer takes his first step on the path of prickdom do you have veteran builders who can confront the issue head-on or does your organization avoid the issue; hoping that the issue will fix itself?

Does your environment have experienced veteran builders who can help Jack grow out of his professional-puberty into a better human being?

Does your environment have builders who are experienced and strong enough when it comes to getting straight to the bone and explaining the No-Asshole-Rule to Jack in terms which are simple and clear.

If change in attitude not happening after continuous efforts; is your organization; strong enough to pay the price and gently nudge Jack out of the organization; or does your organization take the safe-mediocre path of tolerating assholes just because they are rock-stars at what they do; 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, August 4, 2009 9:06:02 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, July 31, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 7.

Where Saying 'No' Is An Option.

Do you know who the 'idea man' in your project is?

Usually this is going to be a manager who doesn't do any real work or a business analyst who doesn't do any real or even un-real work.

Identifying the idea man is easy:

  1. Idea man does not like to be associated with one project for a longer duration.
  2. Idea man is bubbling with ideas that he 'thinks' your clients 'must have'.
  3. Idea man understands the culture chart and knows the people high up in the pecking order well enough to pull a few strings and get his  ideas of '(not so) nice to have' features or suggestions magically transformed into 'must have' requirements overnight.

Now; the idea man might work with multiple motives; some of which include:

  1. Working for the best interest of the organization and the client ---  You may have click the link to capture the underlying tone of sarcasm here.
  2. Desperate attempts of finding his place in the larger scheme of things --- and an inability to find healthy ways to over come his insecurities.
  3. Showing those pesky programmers their real place.

One of the major thing that differentiates a remarkable environment from a mediocre one is the number of strings the idea-man can pull on genuine builders and story-tellers.

Joel Spolsky's rather famous post on the topic; where he talks about his experience of being attacked by a bunch of these idea-men as a manager on the excel macro team; is rather fascinating. Joel uses his post to tell a fascinating real story:

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.

I asked around. Who's the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.

"Blah blah!" said one of them. "Blah blah blah, blah blah blah!" said another. I don't think they quite had anything interesting to say. They were very enamored of the idea of sub-classing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, "Well, this is all very interesting. What's next? Who has to approve your spec?"

I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec.

The same story describes the whole string pulling exercise which is a rather common trait amongst idea-men:

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him.

Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?)

My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

Joel effectively goes on to describe what made Microsoft a special environment to work at in the very same story:

I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office -- I knew who he was, of course, but didn't expect that he knew me very well. 

"How's it going, Joel?" he asked. "I hear you've been having some issues with the App Architecture group."

"Oh no!" I said. "Nothing I can't handle."

"Say no more," he said, "I understand." He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.

While the story is a fascinating example of a work environment where eventual builders are given room to maneuver it is also an interesting case-study of what results in the development an environment where genuine builders who indulge in the act of building stuff can flourish and innovate.

If you've been in the business of building software for any period of time; you've probably found yourself demoing your product to the-idea-man.

The idea-man is usually not an involved client; he is not a regular user; he is not even an active team member --- because all three of these require time and commitment and a typical idea-man has neither time nor commitment.

Chances are; that the idea-man will not even log-in in to your application after you are done with demoing your application to him --- but based on his infinite wisdom and experience --- he is going to leave you with a few ideas that your 'absolutely must' implement.

Once you spot an idea-man; be informed; that he will pull any strings he can to get his ideas implemented.

When that happens:

Does your work environment leave you with no other option besides; dealing with the idea-man diplomatically?

Do you have enough genuine builders or story-tellers around you who are masters in the art of sedating monkeys and getting them out of your way?

Is saying 'no' even an option in your environment; 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 31, 2009 9:13:36 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, July 30, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 3.

 Following The Rules Vs. Acting Responsibly And With Passion.

If you have been a reader for this blog for any period of time; you probably know how much respect I have for Processes and Rules.

On one hand; I detest nine-to-five organizations with rules or policies for everything.

On the other hand however; when it comes to my own project; I spend countless hours tweaking my code; fixing the casing of my variable names; measuring lines-of-code-per-function; constantly looking the cyclomatic complexity of the functions; desperately trying to bring the complexity down and indulging in dozens of other painstaking exercises which might sound un-necessary to a young and budding developer.

I even push the idea of constantly following 'DRY' and 'YAGNI' --- sometimes a little too strongly to disappoint others.

Isn't all of what I do in my projects a classic illustration of me contradicting myself?

Am I not going against the very core thought-process of having little or no respect for rules?

While I go out there; comment and claim that contradictions do not exist; isn't my behavior on my projects a classic example me contracting my own thought-process of having very little respect for rules and the status-quo?

Of-course it is not.

Allow me; dear reader; to put my point across to you using a rather inspiring post written by Jurgen AppeloJurgen describes the idea of following rules using the example of driving. He explains:

I love driving my car. It’s a male thing, I suppose. It’s somewhere in my Y-chromosome. I embrace every opportunity I can find to hop in my car and start driving.

And (like every other male on the planet) I think I’m a good driver.

You see, I always watch the other cars around me on the road. When changing lanes I check all sides and mirrors. My distance to the cars in front of me is enough to allow for occasional extreme speed reduction.

I match my speed with the weather conditions. I play music in my car (loudly) but I don’t wear headphones. I don’t use my mobile phone while driving. And, as far as I can tell, I am the only person in the world who is able not to cross the lines that mark my lane while taking a curve to the left or the right.

I have adopted this behavior myself.

I might have copied some stuff from other people, but it was my choice to learn these rules and use them, always.

Jurgen illustrates the difference between following-the-rules and acting-responsibly. He explains:

Only thinking and talking about something doesn’t make it so. Just like making up official rules won’t turn your business into a success, traffic signs won’t make you a good driver.

In fact, I often don’t notice many of the signs.

It is my attitude and actual behavior on the road that makes all the difference.

Craftsmanship is something agile doesn’t introduce by itself. And just thinking and talking about it doesn’t give you successful projects.

Managers who want better results must acknowledge that they have to actively change the attitudes and behavior of their people. They must stimulate craftsmanship and discipline. Or else...

Or else accidents will happen.

They say changing people's behavior starts by giving them a good example. So let the world know that yesterday night, while many people were watching the Champions League Final, I myself was learning how to do test-driven development with Python.

I hope to have inspired you.

If you live in the same planet as I do; you will be given rules at every step and corner of your personal and professional life. Every time you are given a rule; you can do multiple things with it. You can follow it; question why; bend it; tweak it; work around it or sometimes even break it outright blatantly and shamelessly.

Remember; what you do with your rules will *not* decide anything --- your attitude; passion for what you do; wisdom; competence; ability-to-make-good-judgment-calls and responsible behavior will.

Go break the rules that don't make sense to you and make new ones that do.

If nothing makes sense fly free --- but flock responsibly.

I wish you good luck.

posted on Thursday, July 30, 2009 10:36:41 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, July 28, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 2.

Stupidity Is Not Always Loud And Clear.

Of all the seemingly harmless things that destroy projects in general and organizations in particular; thoughtless optimism mixed with wishful thinking is one of the items that tops the chart. Every year countless startups fall flat on their face and every year new startups with more thoughtless optimism replace them.

The amazing story of the shut-down of fly-clear by Joel Spolsky is a classic tale of thoughtless optimism gone wrong. The story is Intriguing of multiple fronts. The first front is the actual service that fly-clear was providing; which Joel describes rather well. He explains:

Here's how it worked while it was in business. You paid $200 for a one-year membership. You underwent a big, complicated background check to prove that you were extra-super-trustworthy.

In exchange, in a few big airports, you got to skip to the front of the TSA line for screening.

Now, you didn't skip the screening itself. You still went through the X-ray machine and had to remove your shoes, belt, pocket contents, laptops, and plastic quart zip-lock bag of toiletries.

You just got to cut to the front of the line.

A few people signed up. In certain airports, it was, indeed, worth actual money to cut to the front of the line.

This wasn't Clear's actual business plan. The actual business plan was that Clear would do detailed background checks on travelers, who would then be trusted to bypass security completely because they were extra-super-trustworthy

When TSA rejected the whole idea of skipping the security check and only allowed fly-clear users to just move to the front of the security check line; still leaving the requirement of a security check mandatory; Clear continued with their initial plan --- which was to charge money for their service and continue to do detailed background checks on all their users before they registered them.

Joel describes the stupidity rather articulately:

At this point, and here's the interesting part, at this point, a rational businessperson would say, "Well, does the Clear idea still make sense if we can’t actually let you skip the screening?"

OK, maybe it still makes sense to charge to skip to the front of the line. Maybe there's a business model in that.

In that case, though, why did they still do background checks? It doesn't make any sense.

The environment changed. It turns out that Clear's business model of prescreening wasn't going to be possible. But they kept doing it anyway. What kind of organizational dysfunction does it take to completely ignore the changed circumstances and keep at a money-losing business?

Joel ends the post with a note of wisdom and sarcasm:

What's even funnier is that Clear could probably have been profitable if they had just skipped the one unnecessarily stupid part of their business model: the detailed background checks on all their customers.

Nobody at Clear did any thinking.

They had a business model, the business model wasn't actually possible, everybody knew it, and they still plugged away at it. Thoughtless optimism. I don't know whether to salute them or laugh.

I find these stories really fascinating because based on the little facts that we as outsiders are privy to; these stories allow us to do black-box-investigations into huge colossal fu@#kups-ups orchestrated by smart people who had the means and the measures to organize fu@#kups of this magnitude.

Joel does his fascinating and thought provoking analysis of the story and comes to a simple logical conclusion --- Nobody at clear did any thinking.

Take that analysis one step forward and you realize that thoughtless optimism in real life; isn't as simple as a team of lousy-thoughtless-bozos coming together; moving into a dark cave and writing random software after they have lost all touch with reality.

Put simply; thought-less optimism is a slow process that happens over time; and by the time it takes it's toll on your organization; your organization; in all probabilities; has already lost the sight of the stupidity that surrounds it.

While it is easy to conclude that everyone working at Fly-Clear was a bozo indulging in thoughtless optimism; my guess; is that like any other typical startup out there Fly-Clear had its bunch of builders, story-tellers and whiners.

Now; if you assume that Fly-Clear was a decent startup like any others with an idea and an implementation --- it makes you wonder what got them from the great-fun-filled-start-up days to a miserable shutdown.

Multiple possibilities exist.

Maybe the leadership at Fly-Clear was too arrogant to consider the idea of surrendering; giving-up and starting something else.

Maybe they started off with smart and talented employees who lacked the spine to come out and announce that the king was in fact, naked.

Maybe the young and smart employees in the corridors of Fly-Clear spoke their mind but then decided to hibernate while the folks higher up in the pecking order could not care less.

Maybe just one senior vice-president high up in the pecking order at Fly-Clear believed that he could still get TSA to agree at skipping the security checks and then all those background checks they did would suddenly become appropriate.

Sometimes you need a team of monkeys to turn a project into a failure or shut-down an organization; sometimes; just one monkey left un-sedated is enough to bring an organization to a shut-down.

Maybe it was just mitigated speech and complete in-ability to accept; that the whole idea of continuing background checks; even after TSA refusing to skip the security check; was; as a matter of fact; fu@#ked up that brought them where they are today.

Maybe; and here is the creepy part; maybe it was all of the above in small dozes which were barely noticeable.

While it is easy to read stories of failure and discard them as --- Oh-they-were-stupid-we-are-not --- why these stories of failure with very little forensic evidence to base your analysis on; are still useful --- is because they show the level of fu@#kup-ups some decently intelligent teams; sometimes even having a few really smart people; are capable of orchestrating.

Remember; the problems that eventually cause your project or your organization to fail are much more subtle than we think.

Every time you read a story of failure; take a deep hard look at your organization; your team and your project.

Random acts of stupidity might be happening; really slowly; around you; right now as you read this.

Being consciously aware of the fact and knowing that a fu@#kup as big as some of these glamorous fu@#kups could be cooking right in the corridors of your organization is your only chance at avoiding these fu@#kups.

When you are on the look-out for stupidity in your very own project, team or organization; keep your eyes open dear reader; because total random stupidity is not usually very loud and clear.

It all begins with one isolated act; and then it grows from there --- usually in small doses and unannounced till it becomes big enough to cause your entire organization to go-down; without any prior warning.

Next time you look around you and see what is going on in your project, team or organization; keep your eyes open; really wide.

I wish you good luck.

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 28, 2009 10:01:03 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, July 24, 2009 by Rajiv Popat

Stitch And Use Approach To Developing Intellectual Property Is Highly Overrated.

Years ago at Multiplitaxion Inc, I witnessed a project which was a collection of multiple source frameworks out there; that were somehow held together with band-aids. When the final product evolved by the virtue of hooking up random open source frameworks; we called it our 'Intellectual Property'.

Soon the band-aid wore off and our product crumbled to pieces before moving to a stable production environment.

Any engineer with an eye and taste for genuine software would clearly seen the different components oddly stitched together by interns fresh out of college and laughed at the idea of calling it our Intellectual Property.

Here is the tragic truth however; we were neither able to sense the oddness in the whole design nor question how you can create intellectual property by hooking up five open source components out there together with weak a band-aid. Anyone who was intelligent enough to understand the oddness of the design decided to keep their gob-shut and tactfully disassociated themselves with the project. 

After multiple man-months of efforts; a huge team slogging away trying to contain and control components which were like beasts running in different direction; started facing and ignoring small broken windows which soon snowballed into an explosion that destroyed the project.

The stitch-and-go approach to intellectual property destroyed the project.

Years later; at work; in my current organization; I was asked to build a system which would allow us to build applications for our clients who had a lot of long-running workflows and wanted to take these workflows online. That is when Crux was born.

Even today; I am viewed with paranoid eyes of capable programmers when I tell them that Crux includes a custom-made application framework along with a light-weight, open source workflow engine that I wrote using new language features of C#.

'But Pops, why didn't you just use windows workflow foundation' --- is one of the most common question that comes up during training session for Crux.

A part of me; which is a pragmatic programmer answers this question with logic and reason --- we have used Windows Workflow Foundation for months; found it to be a decently good workflow engine but it is way too complicated for the kind of long running workflow requirements most of our clients were are going to have. Besides the learning curve associated with it is steep and the benefits gained out of using it for what we were trying to do; aren't high enough.

The real answer however is deeper than that. The real reason for not using Windows-Workflow-Foundation in Crux was the fact; that Windows-Workflow-Foundation in it's current version needs 'stitches' and 'compromises' all over the place to be hooked on to anything.

Put simply; Windows Workflow Foundation; in it's current version; is a beast in itself which requires feeding or caring and that feeding or caring; dear reader; was too much of a price to pay for the simple web based long running workflow systems we were trying to build.

This post dear reader; is not about me trying to illustrate how a product that tried to hook on multiple components out there failed and how me deciding to not use Windows-Workflow-Foundation in Crux ultimately gave us multiple successful client implementations.

This post; dear reader; on the other hand addresses an aspect of software development that is much larger than the two examples I talked about.

Talk to most CTOs, Vice Presidents and even consultants around the world and it is not un-common to come across words like 'leverage and re-use of components out there'. Talk about building something which sounds a little off-track; in-house and it is not un-common to hear the sound of fifty thousand heads of programmers exploding all at once.

While I am all for the idea that we as developers are code addicts who are constantly wanting to bull-doze what exist and start from scratch; it is also important to realize and stop; particularly when your desire to 'leverage' the components starts taking you down the slippery slope of creating Software that can be best described as Frankenstein's monster. A monster that will eventually chase it's developer and make his life miserable.

As a general rule; if you are trying to roll out something that is going to be your core-intellectual-property you are better off building the stuff yourself; or at-least working at a level of abstraction where you can control and tweak every minor detail; rather than trying to hook up multiple ready made components out there in to get something out quick and dirty.

The Stitch And Use approach to building intellectual property is highly overrated.

On the other hand if you are just trying to get a processes automated or get a solution implemented that does not involve your core intellectual property you might be better off buying the stuff that's already out there. When it comes to tools; which allow you sufficient level of abstraction that you need; again; you are better of buying than building.

Either way; always remember - if buying is an option; building is an option too --- even if your Vice President looks at you like you just dropped a filthy rat on his table when you utter the words 'build'.

The next time you are faced with the question of building vs buying or using something already available; keep your biases aside and take a pragmatic decision based on your past experience; logic and your very own gut-feeling.

I wish you good luck.

posted on Friday, July 24, 2009 10:44:30 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Thursday, July 23, 2009 by Rajiv Popat

Random Thoughts On Builders At Work - Part 1.

As I continue to struggle mulishly towards writing the book I started to set out months ago I am starting to realize that there is a lot more to be read; researched and said on the topic of how genuine builders and storytellers function. The 'Random Thoughts On Builders At Work' series of posts is supposed to help me organize of some my random thoughts for inclusion in the book without feeling the urgent need to organize them sequentially.

All of these posts; will be eventually added to the book; but for now; dear reader; you can read them as isolated blog posts without any direct sequential connection with the post that came before it or the one that will follow.

So; dear reader; here is one such random thought of genuine builders.

Why We Build Stuff Decides How Long We Continue Doing It.

Early on; in my post on consistency; I announced that consistency is one quality present in all genuine builders and storytellers. Having said that I continue to be disappointed by the lack of overall consistency in the world of software development in general.

You don't have to take my word for it; dear reader. Go look for:

  1. The number of abandoned blogs on word-press or blog-spot that never crossed the post count of ten.
  2. The number of abandoned open source projects on source-forge.
  3. The number of software programmers who upload and update their resume on a job portal every year.
  4. Number of startups that come to an end each year.
  5. Number of ideas on which work is started and then abandoned each year.

Somewhere deep down inside;  the question that really kept bothering me was this --- Does this mean that we are all quitters and whiners who start things which we neither want to finish nor support; in the long run.

After a decent bit of soul searching; reading; and one flash of lightning later; I figured out that the answer to these questions; dear reader; really lies in 'why we indulge in the act of building stuff'.

As it turns out; most people; indulge in the all of the acts mentioned above; starting from launching their blog to signing up for an open source project; for the same reasons that crack dealers indulge in the risky business of selling crack.

Steven D. Levitt and Stephen J. Dubner explain the phenomenon in their book; Freakonomics. They explain:

A 1-in-4 chance of being killed! Compare these odds to being a timber cutter, which the Bureau of Labor Statistics calls the most dangerous job in the United States. Over four years’ time, a timber cutter would stand only a 1-in-200 chance of being killed.

Or compare the crack dealer’s odds to those of a death row inmate in Texas, which executes more prisoners than any other state. In 2003, Texas put to death twenty-four inmates—or just 5 percent of the nearly 500 inmates on its death row during that time.

Which means that you stand a greater chance of dying while dealing crack in a Chicago housing project than you do while sitting on death row in Texas. 

So if crack dealing is the most dangerous job in America, and if the salary is only $3.30 an hour, why on earth would anyone take such a job?

Well, for the same reason that a pretty Wisconsin farm girl moves to Hollywood; for the same reason that a high-school quarterback wakes up at 5 a.m. to lift weights. They all want to succeed in an extremely competitive field in which, if you reach the top, you are paid a fortune; to say nothing of the attendant glory and power.

Analyze the life cycle of a typical young and budding blogger bubbling with enthusiasm about to sign up for a free word-press or blog-spot account and you will realize the similarities. You will also realize this is why a huge number of bloggers never cross the three post count. Here is pretty much how the life of a typical blog works:

  1. Bubbling with enthusiasm and encouragement Fred starts a blog; which he believes will make him rich, famous and so-very-sensational.
  2. Fred does three posts in a month; only to discover that no-one cares about him, his blog or his product.
  3. Fred silently and subconsciously decides that the world doesn't deserve his blog and quits; till he finds something else which seems amusing and exciting.

If this describes your mental process as you sign up for a blog; do your first open source check-in or share your idea with your friend; it just means that you may have striking similarities with the Wisconsin farm girl who moves to Hollywood or the drug paddler who risks his life at only $3.30 an hour.

The problem with that sort of motivation; is that; it doesn't last very long. Once you realize that getting to the top is painstakingly hard and there is nothing much to be obtained by staying at the bottom or in the middle; you are left with no other option but to quit.

Conan O'Brien describes how he avoids this risk very articulately in his interview with the A.V. Club. He explains:

There's a temptation to over-think the whole thing. I've had a Field Of Dreams philosophy to this: If you build it, they will come. I still have no idea.

I don't look at research. I don't look at who's watching, or when they're watching. I've never been interested in any of that. I'm interested in doing what I think is funny.

For the last 13 years, that seems to have worked for me.

If I go to 11:30 and do what I think is funny, and someone comes and tells me it isn't getting enough people in the tent, I'd say, "Well, that's all I can do." If I'm looking at spreadsheets and time-lapse studies of viewing patterns, I think I'm wasting my time.

What I should be worried about the first night I host The Tonight Show is, "How can I make this a funny show?"

The second night, "All right, let's make another funny show doing some different stuff." You do it one show at a time.

And if you're lucky, eight years later, you've alienated a nation.

Whether it is your blog; your open source project or your next big idea; if you have the slightest element of Hollywood-Baby-Dream about the fame and money that is going to come out of all your efforts; chances are that your efforts are going to have take a nose-dive on the path of failure and you are going to quit; whatever-it-is-that-you-are-starting; in the next few days.

On the other hand; if you realize up-front that your blog, open source project or your ideas are not going to make you rich or famous; and decide to do is anyways; for the pleasure of doing it; chances are that you will find it that much more easier to survive as a low maintenance software terror cell and continue doing what you love doing; for a very long time --- consistently.

Remember; why you start something often governs how long you continue doing it.

So before you start; answer the why; very carefully.

Remove the Hollywood element of success out of your idea; right upfront; before you even start.

Stop fooling yourself.

Ask yourself if you will genuinely; truly still love the idea after the money, fame or other Hollywood-Dreams contained in the idea are shattered and removed.

If the answer is 'no' --- drop the distraction and go find something that you genuinely love doing.

If the answer is 'yes' --- start slogging on your idea now.

Either ways; I wish you good luck.

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 23, 2009 9:52:26 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Tuesday, July 21, 2009 by Rajiv Popat

Measuring Your Twitter Power Using Number-Of-Followers Is Highly Overrated.

Honest confession: I love twitter.

Having said that; twitter is by far the loudest when it comes to flaunting your so-called-social-networking-mussel-power on the web. Placed smack in the middle of every user's home page is what I like to call the 'Twitter Power' Dashboard.

As humble and low profile as this dashboard looks; it is one of the features that drives countless users to twitter and keeps them motivated for months as they work hard to 'collect' what twitter calls their 'followers'.

Put simply; the concept of 'followers' and the idea of flaunting the number of followers that follow you on your twitter-home-page is by far one of the biggest psychological gimmicks that I have witnessed in my entire online life till date; and guess what --- it works really well for twitter.

The reasons why it works are pretty obvious.

Joshua Porter in his blog-post on the topic; describes rather articulately why Twitter strikes a note with a huge audience and how it en-cashes on simple fundamental human nature; big time. He explains:

Here’s a question: how would Twitter change for you if you didn’t know how many followers you have? What if the designers at Twitter removed the number from all screens/APIs and forced you to rely on replies or re-tweets to let you know what was going on? Would that be OK with you? How would it change your behavior?

Humans are hard-wired for attention. My newborn girl, for example, cries when she’s not getting attention. My 3 year old, who isn’t used to not having attention, is going through a major psychological shift in her life because she’s realizing that she isn’t the only child in the universe... she now has a sister who will be getting attention as well. Attention is a core human issue for all of us. As designers we need to keep this in mind.

What is actually scary about a feature of this sort is that even someone like Joshua; who is smart enough to understand the whole point cannot help but use the meta-data on every user that twitter flaunts on their twitter-home-page to come to his conclusions about the person. He explains:

I use follower numbers in several ways to judge the type of person who is on the other end. If I’m followed by someone who has very low following/follower numbers, then I know they’re probably new to Twitter.

If someone has really high following/follower numbers, then I know they’re probably an auto-follower, which suggests they might not focus on quality conversation as much as attention.

If someone has high follower numbers and low following numbers, then I know they have an audience for some reason (it might not be a good reason). Obviously, these numbers don’t tell you everything… but I use them to give me an idea. When metadata is available… humans will look at it.

While the analysis seems reasonable enough at the first glance; the fundamental issue here is realizing why twitter decided to throw the Twitter-Power dashboard on your face in the first place.

It was a design decision.

One that benefits Twitter tremendously.

The real question; that you; dear reader; need to ask yourself now is this --- how does it benefit you?

Does it nudge you to go out there and push meaningful content or does it nudge you to increase your follower-count by indulging in the You-Follow-Me-I-Follow-You funny dance that a huge percentage of twitter users dance?

As anyone who has run a blog for more than a year and has had more than a handful of subscribers will tell you; constantly peeking at your traffic and writing with the sole purpose of increasing it; is highly overrated.

Jeff Atwood describes this much more articulately than me:

There's certainly value in audience metrics. But it's easy to overanalyze, too. Instead of obsessing over who does and doesn't link to you, concentrate on writing a blog entry you'd like to read. Instead of worrying about audience feedback, focus on delivering a presentation you'd like to attend.

You should trust your gut more than any metrics. Build it, and they will come.

With it's one-forty-one character limit; twitter makes writing something you would yourself like to read later really hard; With it's constant display of your statistics or traffic-meta-data; it makes worrying about the number of followers you have really easy.

If you; dear reader are on twitter; the real challenge is not how to increase your follower count.

The real challenge; dear reader; is in-fact; to turn a blind eye to your 'twitter-power' dashboard and focus on adding content that your readers and you yourself will love reading.

Now; go visit your twitter home page.

This time; try not to look at your follower count.

Focus on your past tweets section instead.

See if you can read through your very own twitter home page; read it; not get bored and get some genuine value out of it.

If you can't --- the number of followers you have; is just meta-data that doesn't mean a thing.

The whole idea of measuring 'Twitter Power' through number of followers is highly overrated.

Now go find meaningful ways to participate and contribute using that small one-forty-one-character text-box.

I wish you good luck.

posted on Tuesday, July 21, 2009 10:52:20 PM UTC by Rajiv Popat  #    Comments [0]
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]