The moment you have an idea for an application, if you're like most people, you get really excited about what the product will be called. As you fancy a world where the product exists and people love it, you tell yourself, "Hmm, I wonder what a good name for the product will be".

Now, for those of us who have tried to name anything, from a baby to a website, we know that naming is hard.

"I wonder if this one is taken", you think of a name and before you know it you are spending your mental cycles in thinking a happening name and giving in one futile attempt after another only to find that all those names that you can think of are taken.

Then you get lucky and get a domain name, but then the twitter account for that name is taken.

"Those pathetic twitter squatters! I mean he is not using this account. I wonder if I can email him and ask him if he would be willing to sell the account to me.", you tell yourself.

See where you are going with this? Again, if (and I am just saying if) you are like most people, you are going to run thought loops in your brain, think of dozens of hot happening name for your product and wear yourself out before you even write a single line of code.

Naming a product you do not have is just about one of the stupidest things you can do. Ok, wait, actually there is one thing even more stupider than that. You know what that is? Naming a company that you do not have.

No, Seriously. How difficult is it to stick a logo with a sexy name on your template file once your product is built? How difficult is it to register a company after you have your first customer willing to pay you for your work?

If you spend days thinking about the name of the product, before you even write a single line of code you are a dreamer.

Wake up kid.

Write the damn product first. The pleasure of naming a product is supposed to be a reward for nearing the shipping of your product and you, are nowhere close to shipping your product yet. So snap out of it, open that IDE and start working. Let's see if you can build something which is even worthy of being named.

Oh and by the way, now that you have the IDE open, I wish you good luck.

When you hired Fred he was one of the few fairly productive employees you could lay your hands on.

There were a few minor glitches during the interview but then he seemed technically competent.

His demands were simple and very legitimate:

1. Some autonomy and ownership over his own work.
2. Good work with the latest technologies and frameworks out there.
3. A pay package that does not insult his capabilities.

A couple of years in the organization and you can see clearly that the cost of keeping Fred happy and satisfied is increasing steadily. Fred now just wants to work with the European clients because he has never visited Europe and is expecting a nice little business trip there. All of a sudden he cares little about the technology this European client is using or the autonomy that he has in his work. His primary focus is a big extravagant business trip to Europe.

You Cringe.

Fred in the last couple of years has morphed from someone who was highly innovative and driven by intrinsic motivation into someone who is high maintenance, low productivity and highly calculative about extrinsic factors. 

Once the barrier for being low maintenance is broken, it is a slippery slope down the hill. Fred suddenly feels that he is underpaid and overworked. Autonomy and quality of work mean nothing for him. Oh and by the way,  Fred also expects a promotion in this year's appraisal, even though he did not do a lot of 'real work' this year.

He is a borderline case of venting his frustrations on the employees and the organization.

Like it or not, when these symptoms show up, chances are, that you are going to lose Fred.

And then one fine morning Fred knocks on your cubical to talk about his resignation.

Your instant impulse? To offer him a raise. Match the offer that he is getting in his new organization.

After all he was once a productive member of your team.

My advice: Don't even think about it.

You lost Fred, the day his productivity curve started going down. In fact, you lost Fred, the day he stopped working for intrinsic motivation and starting whining like a baby for that European trip.

You can either take my word for it or you can try and match Fred's salary. If you went the later route, chances are that within six months to a year, you are going to see Fred knocking at your cubical, wanting to talk about his resignation again, this time with a higher offer letter.

Instead of trying to get Fred to stay, you are much better off letting him move on and letting someone else in his team take up his responsibilities, even if Fred is your alpha geek.

As scary as it seems sometimes new faces and thoughts are good for your organization. Stop your negations with Fred, let someone else in the team take up his responsibility and  let life get back to normal. Or you can go hire but if you choose to do that, do it like your professional life depends on it.

Either way, I wish you good luck.

Oh and if you are sitting there negotiating with Fred you are just wasting your time and energy.

You have gathered for a meeting. This one is not the casual sitting around the fire, chatting about the meaning of life and discussing the movie at the theatre in the next block, meeting.

This is serious business. You know it. Your boss knows it. His boss knows it too. They are all there. Pumped up. There to take a decision about the features that we will need to build in the next one month to wipe out the competition or maybe to pick a framework for your next project.

"So, do you think we can ship by end of this month?"

"Which framework do you think we should build this using?"

"How many more people do we need to get this done by the end of the month?"

Yeah. I know. Its tempting.

"Gee Boss, I think we should build this using Dot Net Nuke and hire about three interns and a senior engineer on the team."

Bad move.

Shut up!

When you are in a meeting your job, as a manager, leader or whatever it is that you call yourself or see yourself as, is to avoid decisions from being taken over a single meeting. Classical business analysts and managers will tell you that this is because you need to protect the team from your upper management. That explanation is almost always bullshit. Your team does not need protection from the upper management.

If your upper management is getting you on a meeting and asking you these questions chances are that you are one lucky son of a gun who has landed with a really strong senior management team who cares enough to ask you what you need.

That doesn't mean that you have to give them an answer right away though. Like I said, Shut up. You need some think time on the time your team is going to take working on this. You need to see if Dot Net Nuke really fits what you are trying to build, or will you just end up building yet another Frankenstein.

Overall organizational decisions taken in a single meeting are equally risky. So Fred miss utilized the corporate credit card. You are in a meeting discussing the problem. Someone three levels above you hastily panics. "So, do you think we need to stop the corporate credit cards for everyone? Are they really needed?" - Again, temptation to give your instant opinions. This is one isolated incident. Maybe it needs an overall organization policy change. Maybe it does not.

Whatever it is, the only thing that I can tell you is that you do not need to decide the solution over that meeting.

Breathe. What you need to do in this situation is protect yourself and your management from one of the biggest threats of the software development world: Panic.

When you are in a meeting, the pressure to take the right decision is  immense. Chances are that you are not going to be able to Blink well in this scenario. The solution, the right solution to the problem is most likely to show up tomorrow morning, in the shower.

When you answer in a meeting, your management listens to you and decides to move in a particular direction, all of it happening during that one meeting, you block the possibility of the best solution showing, in the shower the next day.

As tempted as you might be to open your mouth during that meeting, shut up. Sleep over the problem. Give it some soak time. Chances are that the solution you have the next morning will be much better than the solution you have during the meeting .

When it doubt, choose silence over spontaneous reactions in meetings. You are not going to make the best of the decisions in a meeting when you are surrounded by people and have precisely a couple of minutes to react and take a decision. Go on. Defer your decisions. Ask for soak time. Most of your important decisions deserve at least a night long think time and what you need to do, is learn how to ask for it. Blatantly and clearly.

I wish you good luck.

Neuroscientist around the globe now believe that human beings can be classified into two primary groups when it comes to their sleeping habits and productivity. Some of us are much more effective during the day while others are much more effective at night struggling to get up every morning.

The whole idea of having a common work time where everyone does a nine to six is really counter productive as per this theory, but that is not what this post is all about.

One of the building blocks of the theory that some people are much more effective during the early morning while others are much more productive during the late night dates back to the days where our ancestors were living in the woods and were gatherers.

It is believed that during that rather large number of years of evolution, the human race had figured out how to collaborate better for survival. Each tribe was comprised of typically two kinds of human beings. There was a group that was responsible for getting up early and gathering food for the tribe. Then there was the group that was responsible for staying up late and guarding the tribe against attacks from wild animals.

Years of evolution, morphed the neural pathways of these two groups in such a way that the first group was much more attentive and functional during early mornings, while the other group was much more attentive and functional during late nights. This theory, received a lot of attention in a book called Brain Rules  by John Medina

Once you start comparing the modern day world with it's roots from the prehistoric era when our ancestors were barely getting down the tree and lighting fire,  behaviors or individuals and how the human race might have morphed start making a lot of sense.

Take for instance the classic act of gathering in meeting rooms, sitting around a table and talking at length for hours about what is wrong and how we (the collective we) should fix it. The meeting room is typically filled with two kinds of people:

The First Kind: The young and enthusiastic developer, who is clearly not very comfortable there. He is fidgeting in the chair, looking at his watch to see the time, wondering when the meeting is going to get over, thinking about the memory leak in his code and how he is going to fix it and talking occasionally only when asked a specific question.

The Second Kind: The manager from the best management school in town, who is contributing actively to the discussion. Asking a lot of questions. Dragging the meeting longer, is in no hurry to end the meeting and in all probabilities is going to go and watch you tube videos after the meeting.    

Your meeting is a Bonfire from the Pre Historic Era.

No. Seriously. Dive back into the depths of time. Our ancestors lighted up pieces of wood every night and gathered around it too feel the warmth of the fire. The fire was a symbol of safety. If you were a tribe from those days, who do you think would have liked the idea of spending an entire day and night around that fire?

The gatherers had stuff to do in the morning. They had to catch enough sleep, get up and get out there to get as much food for the tribe as possible. The guarders had stuff to do during the night. They had to catch enough sleep during the day, get their spears sharpened and be on the lookout for wild animals during the night. It was the sick and the old, that loved the fire the most and liked the idea of sitting around these fires for most of their time.

Nothing really changes all that much in the formation of the human brain in just a few hundred years. The fundamentals still remain the same. Look around you and you will discover that the people who enjoy the meetings the most are either incompetent, out of shape, out of touch or not very productive. They are not bad human beings.

They are just the 'sick' and the 'old'' of the software development world. The meeting to them is pretty much the bonfire. It is symbolic to safety, because they can almost never introduce a bug while in a meeting. It is symbol of warmth because nobody every shouts at each other in a meeting. It gives them a sense of belonging because they can now contribute (anyone can give ideas) without having to work really hard for it.

The meeting is their only way to stay connected to the tribe and get a share of the food and protection by the gatherers and the guarders.

The point of this post, was to remind you that if (and I am just saying if) you start enjoying your meetings, you are not gathering food and neither are you guarding the tribe against wild animals.  You are just squatting around the warm and cozy fire expecting your share of free food. Contribute. Do some real work. Even if it is small. The least you can do is, stop enjoying those meetings and stop dragging the rest of the tribe into it.

Go on. Say no to those meetings.

I wish you good luck.

Most organizations seem to have an itch for logging timecards of employees. What time did they enter the workplace? When did they leave? Did they spend nine hours at work? Policing is stupid. Number of hours you spend at work have no direct correlation with your productivity.

If you are starting an organization and have an unending itch for logging something, start out by logging the number of hours everyone in your organization spends on meetings.

Nine programmers gather for a 'quick discussion' which blows from a five minute discussion to a one hour meeting is nine man hours wasted.

Being in a meeting is worse than not being in office. When you are not at your workplace there is a possibility you are working from somewhere else. When you are out having fun, your chances of coming back fresh and putting in more productive hours are high.

When you are in a meeting, we know for sure, you are not working and you are getting drained out.

Of all the things that most typical organizations log or care about (time spent in office, processor cycles, dress code), most things do not have any direct correlation with developer productivity.

Number of hours spent in meetings per day is one Metric however, which does have a strong direct correlation to productivity.

If you are not actively measuring and logging this metric your organization is a classic case of an ostrich burying its neck in the sand.

If you are logging this metric, chances are that the three hundred unproductive man hours that you spent on meetings last month are going to make you lose some sleep, specially when the reports are in your face and that is a good thing. Now its time to do something about it.

That something is not another meeting on how you can reduce your meeting time.

Can a ten minute detailed email do what an hour long meeting would have taken? Can you use screen capturing utilities to do videos to give to the clients instead of getting the entire team to demo a new feature to them? Are there any better ways to capture and pass information than people being hustled into meeting rooms. Ask the difficult questions that you avoided for months or even years.

If you can spend three hours to do a video and avoid a one hour meeting, you should. Videos typically just require one person to create them. Videos aren't intrusive. Videos are permanent and reusable. You are much better better off investing the three hours, rather than inviting ten people in a meeting, interrupting their flow and blowing up the talk time of your organization to ten hours.

Meetings are not just toxic. Meetings are emotionally stressful. Meetings interrupt flow.

So here is a golden rule for your startup: Log your meetings. See how man hours you drain into sitting in meeting rooms and talking and then rage your very own organizational war against meetings.

I wish you good luck.

You. Yes, you. You can get fired too.

Years ago, this was one realization that dawned on me during a rather strange project.

I was a talented young engineer, minding my own business, learning, growing and staying as far away from office politics as I possibly could. My chances of getting fired were fairly tiny.

Then suddenly, on a fine Monday morning that I found myself in a meeting room with two other programmers and a rather strange project manager, drawing a line on a white board and pasting yellow post-it notes on it left and right. We had been assigned to a nine month project, which the client wanted done in three months.

The timelines that this guy was pasting the board were not making any sense. He was using intimidation left and right to make us say yes to his timelines. We sat there nodding, telling ourselves: how bad can this be. we will work late nights. we will make it work.

If this was now, I would have just said no. On further intimidation, chances are that I would have gotten up, said "screw you" politely with a broad smile on my face and left the meeting.

When you are young the idea of giving up seems insulting. You think of yourself as a super hero ready to rip off your shirt, jump out of the window, fly and rescue the sexy young girl stuck with the evil guy. Besides the fear of getting fired from your first job is pretty much like being rejected or dumped by your one of your first stupid crushes.

Three months later we were struggling with the project. This same manager was grabbing us by our collars and making us ship. The client was throwing their tantrums and we, like any other software development team, in a typical consulting shop, were trying our best to hurry up, ship shit, run away to the next project and not look back.

At the end of third month,  when a particular memory leak error refused to go and the application kept crashing left and right, the realization dawned on us. We realized that we might be fired if we cannot ship this thing on time. It took me another three months and a lot of good luck to overcome the fear, make up my mind to stick around, clean up the shit, ship a decently acceptable version and get rewarded the best programmer award in my organization.

The award did not mean a thing and even today I preferred to refer to this project as the biggest successful failure in my professional life till date. Even today the certificate hangs on a dark wall of a small room in my home, reminds me, every time I look at it, that:

1. Your organization typically cares much less about the integrity of your work than you do.
2. Your organization typically does not care about differentiating your true successes from colossal f@#kups and failures in your professional life.
3. You can get certificates and recognition by shipping crap, if you just meet the timelines your manager wants you to meet.

But of all the things that the certificate reminds me, the most important thing that it reminds me is this: If your organization expects you to do the undoable, you are already F@#CKED. You are better off, showing some spine, saying you cannot do it and getting fired right now rather than waiting for things to get messy and then getting fired like a spineless, gutless dolt.

Don't compromise with your integrity and lower the basic standards of what you ship. If you are going to get fired, at least get over your insecurities and get fired for the right reasons.

I wish you good luck.

Fred is overworked, underpaid and frustrated. He carries his grievances, miseries and frustrations, both personal and professional, with him to work. Ask him to work on something more than the scope of his official business card and Fred gives you a look that makes you feel sorry you asked.

Fred also has a lot of complaints from life in general and his organization in particular. He is out there to make you, the customer or his colleague, pay for it. 

They are not paying him what he deserves. They are making him slog. They are not professional enough. It is all their fault.

My advice to Fred is to stop. Stop whining like a baby and think. You only have three options:

1. Quit your job and go find a new one.
2. Start something on your own.
3. (And if you cannot do one and two) Shut up, stop whining and leave your frustrations at home when you come to work.

Every workplace is going to have their share of problems. Yours has its problems too. Big deal. Whining is almost never the solution to any problem. Two people gossiping about the problems in their organization but neither one of them having the spinal cord strong enough to do something about these problems, is just a waste of their time and a toxic thing for the overall culture of the entire organization.

Making your organization, customer or manager pay for it by scoring fouls is even worse.

Venting frustrations is a part of whining. It is not particularly difficult to do. In fact, it is really easy to do. It is also the stupidest things that you can do. You are much better off writing a constructive email, bringing up the problem with the right people, dropping your mitigated speech, saying how bad things are openly  and taking the hit for it.

When you work for an organization and you do not like it, there are only two things that you can do, you can change your organization or you can change your organization, either way, going to work with a frowning face and a truck load of frustration so that you can vent those out on your managers, colleagues and customers is the stupidest harmful thing that you can do to your own career and character. Stop knitting your eyebrows now.

Stop. Smile. Say cheese. Now go to work.

I wish you good luck.

I hate rules. Having said that, I also find the idea of "Rules which break all rules" fairly interesting.

So you have thought about leading your own team? Leading an organization? Or starting something on your own?

Close your eyes and imagine that I am handing you your dream organization. Giving it to you. Just like that. What I want you to do instead, is give me a detailed Rulebook of things that you will absolutely do and not do in your organization.

Well not the 'rules' per say but the overall guiding principals.

Things that will become the foundational building block for your organization.

A couple of days ago I asked this question on Twitter:

Scott Berkun one of my favorite mavens on the subject of innovation, responded to the question with a rather interesting tweet.

His interesting response:

@thousandtyone *only* hire people 1) who love to work 2) who like/trust each other 3) who are self-aware 4) have a sense of humor

The response is particularly interesting because even though I have always enjoyed working with folks who have a sense of humor and have always been a little uncomfortable around people who take themselves way too seriously, I never quite saw it as a criteria for hiring individuals.

Sometimes you need someone else to pin it down in exact words for you to realize how strongly you believe in an idea.

A new idea was born.

A collection of really small posts highlighting things that matter to me (and hopefully you) when building your own team or your very own small organization.

It's the organizational rulebook for a kickass environment.

If you had a startup and were to write down a few rules for a kickass environment which rules would you pick?

Time to compile a few of these that come to mind and any others you might think of in a series of post.

Go on. Click the comment link, send me an email or send me tweet at @thousandtyone and contribute.