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.

During the development of Crux I was in the flow or as many would say, I was in the zone. focused and getting things done.  I was productive.

Being in the flow is an amazing feeling. You are working with one sighted focus. Without worrying about other problems of your life. You are consumed with a problem and you are in a state of mind where answers are flowing through you without a lot of conscious effort. You are learning effortlessly, you are stumbling across answers, you are productive and you are getting things done fast.

But then, there is another flow or zone that is often not discussed or talked about. Here is what that zone looks like:

You have a late night status call hangover, you struggle to reach office during mid-afternoon only to find a truckload of emails in your inbox. You browse them, give a reply to a few of them.

Very soon your phone starts ringing. It is the calls again. A couple of development teams want your time.

You promised Jack you will sit down with him, review that application he has been working on and give him ideas. A couple of developers are fighting over a stupid issue and you need to take them in a room and talk.

Time is flying again. You are busy. You are doing things which 'seem' important. You are juggling tasks, you are talking, you are supposedly giving a direction to the team and you are managing human beings. It feels like you are in the zone again.

There is only one problem however - you are getting nothing done.

You, dear reader, are in the zone of nothingness.

In fact, the zone of nothingness is not just a manager thing. It impacts programmers as much as it impacts managers. What Joel Spolsky describes in his article on fire and motion is a classic example of someone being in the zone of nothingness. Joel explains:

Sometimes I just can't get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I'm not in flow. I'm not in the zone. I'm not anywhere.

The scary thing about this zone of nothingness however, is that much like the flow of productivity, even here, time flies faster than you think it does. There have been times in my life where I have snapped out of something that looks like flow, only to realize that I have wasted weeks and have been able to get nothing done.  As of today, If there is one thing that scares the heck out of me and depresses me more than anything else, it is the zone of nothingness.

Having said that, every now and then, even today, I see countless developers get stuck in the zone of nothingness and then desperately hoping and relying on their organizations to get them out of it.

If you are a young and budding developers or a manager, relying on your organization to keep you out of the zone of nothingness, chances are, that more often than not, you will be disappointed. If you are serious about not letting those hours whine away only to leave you with a weird guilt and hangover later, might I suggest that every time you find yourself in the zone of nothingness start by making your life as difficult as you can. You can start by:

1. Committing to speak at a local developer conference that might be getting organized in your area next week or consider announcing that you will be conducting a training at your office.
2. Committing to an open source project or a personal project like writing a book or a specific number of blog-posts a week and announcing this commitment live publicly. 
3. Committing to organizing a community event and publishing the event date live.

There are countless other ways to shake yourself out of the zone of nothingness but the key here is to build an environment around you where you cannot help but jerk yourself out of the zone of nothingness.  A public announcement or promise of getting something done where you ego is at stake often does wonders at shaking you out of the zone of nothingness.

Next time you find yourself doing nothing and weeks are flying by, go ahead and make a public commitment of getting something done. Go put yourself on the spot. Chances are that you might be able to shake yourself out of the zone of nothingness and experience the amazing productive flow again.

I wish you good luck.

Jack sits on the other side of the table with a serious face and heavy eyes as he talks about how he has been trying everything under the sun to get management to care about his project. He is raising legitimate complains about his project not getting any love, attention or energy from the organization.

I play around with his product.

Brilliant idea.

Interesting execution.

Within minutes, I notice that his product has all the ingredients of becoming a successful product and yet it has received very little attention outside the small team working on the product.

I sit there and wonder why no one, other than the development team working on the product seems excited about the product? And then, it dawns on me. The project, dear reader, has lost it's Mojo.

Yes, that Mojo.

The team has been struggling for months now. They are being asked to build feature after feature when any technology savvy layman who might have laid his hand on the product would have told you that the product does not need new features. It needs, packaging, cleaning, simplifying, sophistication on the user interface front, a vibrant community, a free for use business model, adaption and an entire blooming eco-system around the product.

What the product manager aught to have done months ago is blown the whistle and asked the team to stop adding features the day they released their first sprint. They should have stopped the development of new features the moment they had enough features to constitute the soul of the product and they should have focused on adding things which would, in the words  in the words of Austin Powers, gives the product it's mojo.

Things that would make the product generate awe or put simply, things that would give the product it's appeal, get the casual website visitor to watch that product video and click the sign-up button. Things that would have got the management excited about the product and got the product the love it deserved.

Every year, I stumble upon countless engineers and startups spending hours, days and months building more features into their products by quietly working in their cubical, while they keep delaying the packaging, simplifying and garnishing of the product for what they call 'future sprints'.

If you are a young and budding startup working on a product or if you are a young and budding product manager pushing your team to build more and more amazing features into the product, here is my humble advice to you:

Work on the soul of the product and get the product an execution that goes justice to the initial vision or the idea of the product.

Once you have done that, stop your development and focus on the garnishing elements which will give the product it's mojo and differentiate it from the other half heartedly baked products out there. Those bigger fonts. classy design. Ajax driven screens and all the sophisticated packaging that you can get for the product.

Once that is done, ship and make just a little bit of noise about what you have shipped. Not a lot, but just enough for a few good mavens to find out what you were working on.

If you have a product with an interesting idea, a brilliant execution, a strong appeal and a few mavens are sold on your product, chances that your product will catch on. A feature here or a feature there does not matter. Now go focus on getting your product a mojo and then ship.

I wish you good luck.