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.

Jack had taken three rounds of convincing before he agreed to show up at a meeting. Now as we sit there and watch people talk about the insignificantly stupid things like building a uniform process for improving developer productivity, I can here the clicks and ticks of Jack's keyboard.

A few of us decide to peek into his monitor to see what he is up to. Jack has picked up a small class in his project to refractor, has disconnected from the meeting and has decided that he is going to utilize the magic minutes we are whining away doing nothing in the meeting.

It is almost as if Jack is alone in the room and the meeting or all of us do not even exist.

What all of us, other than Jack, are doing in that meeting however is what Seth Godin, in his post, refers to as modern procrastination. Seth explains:

The lizard brain adores a deadline that slips, an item that doesn't ship and most of all, busywork.

Laziness in a white collar job has nothing to do with avoiding hard physical labor. “Who wants to help me move this box!” Instead, it has to do with avoiding difficult (and apparently risky) intellectual labor.

"Honey, how was your day?"

"Oh, I was busy, incredibly busy."

"I get that you were busy. But did you do anything important?"

Busy does not equal important. Measured doesn't mean mattered.

When the resistance pushes you to do the quick reaction, the instant message, the 'ping-are-you-still-there', perhaps it pays to push in precisely the opposite direction. Perhaps it's time for the blank sheet of paper, the cancellation of a long-time money loser, the difficult conversation, the creative breakthrough...

Or you could check your email.

The key insight here is that most of our days, these days are not made up of long work hours. They are in fact made up of magic-minutes sandwiched between reptilian lizard brain grunt work that keeps you busy with nothingness. 

How you disconnect with this nothingness and make the most of these magic minutes ultimately decides how much genuine work you can do on any given day. I am not talking about multi-tasking here. What I am talking about is totally disconnecting from what does not matter to you and utilizing minutes of nothingness on things that matter.

Go ahead, download that podcast on programming or that audio-book and listen to it while you are whining your time away on a cab, bus or car to office. Keep your list of small-classes-that-need-refactoring ready and work on a class in a meeting that is becoming excruciatingly boring.

Go utilize those magic minutes and go get something done.

I wish you good luck.

Jack just earned a promotion. A rather well deserved promotion it is. I hand him a promotion letter. He turns around and thanks me deeply for it. The Thank-You is not a causal, thank-you-so-much kind of a thank-you. It is an intense, deep thank you.

I cringe.

I am in a serious problem. A problem I which I refer to as the in-the-frame problem.

After a year of hard work, effort and his very own good luck, Jack has just won a gold medal. Suddenly, for no particular reason I am in the frame of the victory photograph as someone who is responsible for the win. Suddenly I am on the spot as someone who is awarding him his medal.

It sucks being held responsible for Jack's effort, hard work and luck that ultimately got him the promotion.

Most young and budding managers that I worked with in my early life as a developer, loved being in-the-frame when the victory photograph was being taken.

During my career, I have seen managers who will go out of their way to push themselves into-the-frame. Managers who will go so far as politically remind team members how hard they recommended their promotion and how hard they worked to 'convince' the folks high up in the pecking order before the promotion was granted.

I have also seen a few who will go so far as reminding you that their recommendation had weight and impact on the promotion decision that was much more than your own effort, hard working, timing and luck.

You got the monkeys out of their path, you kept them away from long winded meetings, you mentored them and you got them to flock together. Most young managers tend to think of themselves as the captain of the team and when the team is being awarded the gold medal it is but natural for the captain to be in-the-frame of the victory photograph.

Right?

Actually, wrong.

This is a lesson that most managers around the world find it hard to reconcile with. It took me years of working with multiple teams to understand this and I; dear reader am going to let you on this dark leadership secret that you may not find very amusing. It might make you feel hugely insecure at first. Understand it well, and it help you go a long way.

This same secret might actually help you build lasting teams that are not just effective but really good as sustaining themselves in your absence.

Ready? Here you go: Your job, primarily revolves around hiring and placing the right person for the right job.

If you have hired a seriously kickass team chances are that they will kick ass. Don't get me wrong. All your pep-talk, one-on-one discussions, getting the shit out of their way and all your mentorship does make a difference but what I am here to tell you dear reader, is that maybe, just maybe all that is not enough to make a difference between whether a team succeeds or fails in the long run.

Besides, if you are doing your job properly, chances are that your team is not even finding out about the colossal f@#k-ups that your organization and team is avoiding because of your work.

Your reminding the team what a great father figure you have been and trying to butt into the frame when the victory snap is being taken, will definitely not make you a successful manager. It will just show your insecurity as a manager and demonstrate weak leadership on your part.

Next time you are giving out a promotion letter and you get a sincere deep thank you, give an equally sincere reply and let Jack know that you had nothing to do with his promotion. It was his own hard work, effort, timing and luck that did the trick.

Next time the victory picture of your team is being taken, try standing on the last line instead of the first. May I suggest that you try moving out of the frame completely. In fact, try being the guy who is taking the picture and take the best freaking picture you can take.

I wish you good luck.