Those of you who follow my twitter handle are probably aware of my involvement with TEDxCalcutta.

The last few days we have been working really hard in organizing the event, picking the right participants, getting the right speakers and doing a truckload of work that is associated with organizing an event.

The event was an absolutely stunning experience which ended up teaching me much more than what I had initially expected.

If you are reading this and you were an organizer, a speaker or a participant, here is big fat thank you for being associated with the event. We were touched by your involvement with the event, the passion and the encouragement that you guys have given us.

As a small team of organizers start working towards post-event activities like publishing the videos and getting you to give a feedback about the event, some of us have already started thinking about how we make the next year's event even better than this year.

Pictures and videos of this years event coming soon.

More information about the next years event will also start coming out on the website in a couple of weeks. If you were there at the event and liked it, go spread the word. We look forward to having you at the event next year as well.

Stay tuned for more announcements.

We will be publishing them on the TEDxCalcutta website in the next few days.

As developers who believe in participating and contributing one of the things that I do often is tweet using Tweetdeck. 

As much as I love Twitter and Tweetdeck, one of the things I find deeply painful is keeping Tweetdeck or any twitter client open as I work. I have tried it over a zillion times now and if I have Tweetdeck or for that matter any twitter client open on my desktop I just cannot seem to get anything done.

It is the very core of the twitter design, the very thing that makes twitter tick that starts playing against you when you are trying to focus on a piece of work and get it done while keeping a twitter client like Tweetdeck open.

At the very core of the twitter design lies a fundamental component that makes twitter tick and makes you addicted to it: your ego.

Human beings by their very nature are playful beings.

We love playing and above all we love the idea of winning.

Winning allows us to feel good about ourselves and pampers our self-ego.

What twitter allows you to do through its one-forty-character-long-text-box and showing you your twitter mussel power on your timeline dashboard, is that it allows you to take a shot at the game of finding one more follower. You post an random tweet and if someone is searching the topic, likes what you say you get a plus one on your follower count. A minor boost of self-ego.

Of all the reasons that we tweet, one is that tweeting is almost like gambling where your prize is new followers.

Every time you do not have a meaningful insight or a meaningful piece of information that just has to be shared with the world and you go ahead and decide to tweet anyway, all you might be doing by publishing a tweet is taking a shot at the twitter-slot-machine where the reward is a bump-up on your follower count.

Stop playing the twitter-slot-machine while you are trying to get a focused piece of work done. In fact, I may even go so far as suggesting that you stop playing the Twitter Game all together and go tweet about something meaningful.

I wish you good luck.

After weeks of deliberation we have run out of time. Decisions are being taken, things are moving and work is getting done – really fast.

What had taken us three weeks to discuss is getting built in less than a week. What seemed hugely important during deliberation sounds utterly useless now. Priorities are changing. People are focusing on the right things and they are not wasting a lot of time, talking.

When that happens you know - It is the last hour.

The last hour is the time when you start running out of time. It is the time when you stop, take a gasp and you tell yourself – “shit, there is no time left!”

You are scared.

You are holding your ground.

Things are getting done.

Last hours are tremendously productive times. The good thing about them is that they test your limits. They provide you with some real constraints to work with and constraints are good.

Think of last hours as an exhaustive exercise for your brain. Too little of it, makes your brain weak. Too much of it can push you into a fire fighting mode.

Last-hours are often also an indicator that you are doing something new, or at-least something that you have not yet become very good at doing.

If you have never faced a last hour, chances are that you are playing it safe.

If you face too many of them you might be working in a reactive mode.

So, if you have just come out of a last hour and it made you stronger, smarter or wiser, pat yourself on your back. Then go and work harder so that you do not face another last-hour. Well, at-least not when you do the same thing next time.

I wish you good luck.

Jack has been having a hard time in his personal life. Its been days since he been able to ship anything. I am worried. Not because of the fact that we would miss out on a timeline or because the project would slip.

None of that worries me.

The project is fully covered either ways.

Yet there is something about Jack not shipping for a long time that bothers me.

I decide to leave Jack alone for a while, waiting to see when he would be fully back instead of rushing to take his band-aids off.

A week later Jack approaches me. He wants to take over a new module and start working on it.

What makes my day is the fact that Jack is thinking of shipping again. He is back to doing what he is most known, liked and respected for doing in the organization. Soon he is shipping again. He is picking up the hardest of the problems and then getting them done.

But there is still a small gripe that is bothering me deep down inside as I monitor the check-ins on a pet open source project Jack had been working on for two years.

Nothing.

A couple of weeks later however, I see a new post on Jack's blog and a new check-ins on his open source project.

Jack is his usual self again.

I heave a sigh of relief.

Not because Jack is doing his job again or because he is contributing towards the project again, but because smack in the middle of work and personal problems Jack did not give up his commitment to his pet project or or his blog which was making him the kick-ass programmer he was. He is back in no time. He is participating and contributing, again.

While Jack's story has a happy ending, every once in a while, I see programmers, budding entrepreneurs and even bloggers go down the path of a personal or professional tangent so much so that they switch to a do-my-job-and-nothing-more mode for weeks, sometimes even months at a stretch.

The problem with pet projects, blogs, talks that you do at developer conferences and training sessions that you conduct in your organization or your local developer community, is that these are things you do not get paid for. Your immediate life, does not depend on these things and because you see no direct impact of stopping these things, they are the first to get impacted every time you get the smallest hit on your personal or professional life.

You have a really difficult project at work which is keeping you busy for ten hours a day. Why not just stop working on your pet project and focus on work?

You are having a small fight with your girl-friend. You don't feel like blogging about software development right now, do you?

Going on a holiday this weekend. Your blog can wait till next week, can't it?

Wrong decision.

What most developers around the world fail to realize however, is that as a developer, you are not just shipping within your organization. There is a different category of work and shipping which you do that ultimately defines who you are or who you become. These are those concrete, tiny, small deliverables that you ship to your people. Your tiny community. People who hang around in the same third place as you do.

These are those deliverables that rest on nothing more than a thin string of personal commitment. Deliverables that ultimately help you form your weak ties,  deliverables that land you with job offers and most importantly deliverables that help you learn from the best of people out there, overcome your insecurities and become a better programmer, even in your work life.

The next time you have a minor digression, in your work life or professional life and you feel like stopping work on your open source project or not sticking to your blogging schedule, remember that these activities are just as important as your going to work every morning.

If you can go to office and work, your digressions or your problems are probably not big enough for you to stop shipping outside of your work life.

Whether it is work connected to your work life or outside your work life, as far as you can, always be shipping.

We know you because you ship. The day you stop shipping for long enough, we might stop caring about you, your blog or your product.

Yes, of course we know your cat is sick and you need to take it to the vet this weekend, but we are still expecting you to stay up a little late and do that blog-post or that check-in to your pet project. Now, go pick a schedule for blogging or a schedule for checking-in to your pet project and be honest to yourself about trying really hard to stick to it.

I wish you good luck.

Jack in engaged in a deep conversation with his manager. The topic of the conversation is hugely stereotypical. Here is the story so far: his manager wants to know how much time a module will take to build, Jack has given an estimate, his manager is a little surprised and has asked him why it would take that much time. Jack is giving explanations and his manager is giving counter arguments on the but-we-already-have-that-code-in-a-different-module line.

The scene should have resembled exactly the kind of haggling that you would need to do in an Asian or Indian fruit market.

But sadly enough, it just resembles something I have seen so often, that I don't even find it remotely funny.

Every other day I see countless young and budding developers cribbing about how their manager does not understand their problems and does not give them enough time to get things done. Then I see the same developers struggling day and night till they emerge victorious as undefeated heroes who saved the day for the organization. 

As a developer, if you have ever allowed your manager to get into a haggle mode with timelines you have made three classical mistakes which will just make things worse moving forward.

Firstly, you have told your manager that you are not sure of your own velocity and that its OK to haggle.

Secondly, if you have compromised or changed your schedule (even by just a couple of days) you have actually told your manager that haggling helps. You have told your manager that you are typically the kind where it requires 'pushing you harder' to get things done.

Thirdly, if you have managed to complete everything you were supposed to in the newly haggled time frame, you have reconfirmed your managers belief that he was right in pushing you a 'little harder'.

Next time, before you see a negotiation meeting coming, think hard on the estimates you have given. If you have unrealistic estimates behave with integrity, fix them before you attend that meeting and send them over to your manager. If however, you believe that you have realistic estimates and that you are doing all you can to get a quality job done, have the spine to say 'no' to haggling. 

Realistically, finding yourself in a situation where the sky is falling, once or twice is unavoidable. Having said that, if you find regularly yourself working in a fire fighting mode and the reason is haggled deadlines, chances are that you are not acting responsibly and you do not have the spine to say no.

When you allow haggling over timelines, you reconfirm was your managers belief that if he gets you to a meeting-room and uses all the arrows in the management quicker, he can get you to perform magical acts which you otherwise do not perform.

Next time you find yourself haggling over timelines, do some soul searching and ask yourself if you are doing all you can to get the release out without impacting quality.

Are you behaving with integrity and already putting in all you can?

If the answer is yes, don't be bullied or intimidated and have the spine to say no to haggling.

I wish you good luck.

If you read this blog you have probably seen me cite Steve McConnell mention that optimism is one of the biggest reasons for projects failing in the software development world. You probably have also seen me mention that I am basically a pessimist.

Jokes apart, I do not truly consider myself a hardcore pessimist. What I like doing however, is listening to the critic inside of me. Michael Lopp explains this thought approach rather articulately in his legendary book, Managing Humans. He explains:

This is your internal voice, which does careful and critical analysis of your life, and he’s gained a powerful place in your head because he’s saved your butt more than once.

He’s the one who told you that offer from the startup smelled too good to be true. You remember that company, right? The one that simply vanished three months after you declined that stunning offer letter. It was the Critic who said, “How in the world can they afford to give anyone this type of offer when I don’t even understand their business model?”

The Critic was the one who calmed you inner nerd and convinced you to not buy HDTV three years ago, and he told you not to trust that fast-talking engineering manager who emphatically guaranteed his team would be done on schedule.

The Critic said, “People who talk fast are moving quickly to cover up the gaps in their knowledge.”

The Critic was right.

If you have ever worked with a team when the sky is falling you probably know that the first part of the deal with getting out of the shitty situation is that you do not panic.

The second part is weaving an inspirational story which you yourself believe in and then telling it to your team. Its the absolutely amazing inspirational pep-talk that you see in Hollywood movies after which the team goes out and wins the game. 

Its the third part that is actually more tricky. While your entire team is pepped up and working the third part involves listening to the critic within you when he starts calculating the possibility of your team not being able to make it in time.

It is your critic who nudges you to start thinking of alternate ways of getting out of shit.

It is your critic who tells you to start talking to the customers in advance and let them know that the cute user interface you promised them is not going to be a part of the next sprint.

It is your critic who tells you to start talking to the right people in the culture chart and tell them that you might be missing out on features in the next release.

It pays to listen to your critic, because when Jack comes to you a day before the release and tells you that the last three items in the backlog might not ship, you don't give him that intimidating look. Instead, you smile back and tell him it is not a problem at all.

Your critic can be really helpful at times.

When it starts mumbling in its usual soft voice, it is time to shut up and listen.

I wish you good luck.

Have you ever sat in one of those meetings where really senior people get together and scratch their heads on aligning the organization under one process? If you have, then chances are, you know what trying to create an army of clones feels likes.

Every now and then I see countless young managers and even budding entrepreneurs of startups make this mistake.

Here is how the story typically unfolds:

During the early startup days of the organization a team is usually seen as out performing. Members of the team and the team as a group seems to stand out. Very soon the team seems to have everyone's attention and anything that they work on seems to get done successfully.

This is when the managers in the organization get together in meeting rooms and start asking each other questions like - Can we not have all other teams in the organization replicate this process and achieve success too?

Asking this question, dear reader, is a big fat mistake that even I, in my early management days have been guilty of. As it turns out, there are multiple issues with trying to replicate success using one standard process across the organization. 

For starters, this approach is flawed because while you are trying your level best to copy the process and everything else that the successful team is doing, you can hardly replicate their secret sauce or their flocking patterns. Both the culture and the flocking pattern of the team is usually the hardest to copy because it is based on silent, subtle, unspoken factors like respect and mutual trust for each other.

Secondly, a successful team is constantly morphing. Which means that by the time you get to copying it, the team has already morphed and discarded its older practices and processes. One example that instantly blazes through my mind and I write this, is my experience with Agile. 

As a team, a bunch of developers and I were the first at Multiplitaxion Inc to adapt agile and swear by it. But then, by the time the decision to copy and replicate what was working for us over to other teams was made, we were actually done with using Agile by-the-book on our project.

We had stopped having daily scrums. We did not need them.

Communication was flowing freely and lucidly throughout the entire team and daily scrums had been replaced with random coffee breaks where team members were discussing the backlog items. The items were also getting closed. When people wanted help or were getting stuck they were just getting up, walking over and asking for help. Everyone knew what the others were working on and code was truly becoming a shared asset for us.

We, as a team, had morphed before we could be replicated and copied. Clearly, it was not just Agile that was making this team tick. It was their ability to form a creed that had to be copied here and that in essence is not an easy thing to replicate across teams.

Thirdly, when you copy and replicate a process or a team across the organization you close your eyes to other processes and approaches to success. Yes of-course something works, but then something else could work even better. Allow each team to take their own approach. Allow each team to encounter their own set of failures. Allow each team to address their own issues in their very own personal ways and if they cannot, help them.

Remember each team is different. Some are more professional then the others. Some have a strong personal touch element that glues them together and some even have political aspects built right into the core of the team.

Your first responsibility as a manager, leader, entrepreneur or whatever it is that you call yourself, is to accept this diversity. Once you have done that, utilize their strengths and even their weaknesses without constantly feeling the need to change them into one big army of clones.

Embrace diversity and allow your teams to take their own approaches. Let them stumble, fall and recover. If the team consists of kick-ass developers who know what they are doing, they will figure it out, eventually. If you are stuck with incompetent idiots, no amount of replication or process will work anyway.

Go ahead, let them figure out their own problems, work on their own chemistry and form their own approaches to solving problems.

I wish you good luck.

Jakob Nielsen in his classic article on participation inequality describes what he calls the lurker's pyramid using this simple diagram:

Even more depressing than the diagram, are the statistics that Jakob provides in the article. He explains:

There are about 1.1 billion Internet users, yet only 55 million users (5%) have weblogs according to Technorati. Worse, there are only 1.6 million postings per day; because some people post multiple times per day, only 0.1% of users post daily.

Blogs have even worse participation inequality than is evident in the 90-9-1 rule that characterizes most online communities. With blogs, the rule is more like 95-5-0.1.

Inequalities are also found on Wikipedia, where more than 99% of users are lurkers. According to Wikipedia's "about" page, it has only 68,000 active contributors, which is 0.2% of the 32 million unique visitors it has in the US alone.

Wikipedia's most active 1,000 people - 0.003% of its users - contribute about two-thirds of the site's edits. Wikipedia is thus even more skewed than blogs, with a 99.8-0.2-0.003 rule.

Participation inequality exists in many places on the Web. A quick glance at Amazon.com, for example, showed that the site had sold thousands of copies of a book that had only 12 reviews, meaning that less than 1% of customers contribute reviews.

Furthermore, at the time I wrote this, 167,113 of Amazon’s book reviews were contributed by just a few "top-100" reviewers; the most prolific reviewer had written 12,423 reviews. How anybody can write that many reviews - let alone read that many books - is beyond me, but it's a classic example of participation inequality.

As programmers like to think of and fantasize about the web as this amazing medium of delivering content which allows two way communication. We go out an pass generic statements, like 'today anyone who wants to make a difference can make a difference' and then we go out there an nudge the lurkers and the leaches to come out and participate.

Jackob however has a different opinion. Instead of trying to alter the basic behavior pattern of a lurker, Jakob suggests a variety of techniques for getting feedback from lurkers in the article. Some of these techniques are really interesting. Think of the people-who-bought-this-also-bought-Amazon-feature for instance, where the mere behavior of the lurker: the act of buying a book for instance, actually acts as a feedback for others. Smart.

You may not be able to change the fundamental behavior pattern of a lurker overnight just by nudging him to participate or contribute. You might be able to make him publish a blog post or have him comment on one, but be rest assured that if you are targeting a lurker and expecting him to change he will hide back in his cave again, faster than you can think.

It is a painful reconciliation and an insight that you gain with time, but irrespective of what you are trying to do, building a community, promoting a product, service or an event, your only chance of converting lurkers into participants is by letting them hang around, making them comfortable, making them believe that no-one is watching them, making it really easy for them to get involved in tiny little ways if they want to and most importantly, having them keep coming back.

If they do stick around for long enough or keep coming back every now and then, chances are that some day, you might actually touch them, connect to them or even rub them the wrong way. This is when they might slowly and reluctantly take the leap from being a lurker to an occasional contributor.

If you are reading this and you are a lurker who has never commented here, it's okay. Just keep coming back and some day, we just might 'connect'. Some day we might have a discussion over a blog post that inspires you, moves you or maybe just pisses you off really badly.

Till then, happy lurking.

I wish you good luck.