I am in a conversation with a young and budding manager who has recently been promoted. He has inherited a young team of programmers and a couple of database administrators. He begins his discussion around what is wrong with his new team and how he plans on fixing things.

I cringe.

Besides not realizing the fact that the basic traits of human beings do not change, this budding manager has taken his first tiny step to becoming a micro-manager and a dictator both rolled into one.

The problem that is causing this otherwise wise and experienced programmer to not see the big picture as he takes his first step in leadership can be described in one word: Power.

A quest for power, disguised under multiple excuses (the whole I-want-to-help-people-grow being one of them) remains one of the primary reason which attracts people towards management. Steve Yegge describes this problem in his legendary post on Not Managing Programmers where he believes that most managers consciously choose the management route to purely fulfill their unrelenting quest for power. He explains:

If you want to manage badly enough, then you will manage, badly enough. Hence, before you jump in, stop and think about why you want it. Are you tired of engineering, or were you perhaps never very good at it? If so, technical management isn't much of an escape, because your engineers will know, and they won't respect you. Do you want to manage because you want authority? If so, it's a trap: you'll still be on a leash held by the folks above you.

Or maybe you just want to be a little higher in the pecking order, so you can peck downhill? If so, then you're what we call, colloquially speaking, a "pecker".

Think hard about why you want to be a manager. I've worked with a hundred managers with a hundred different motivations, and all of the underlying reasons, including my own, seem suspicious to me now. Especially now that I work for a company that works, and well, with almost no managers or management overhead. Now that I've seen it working, I question the motivations of anyone who wants to manage.

I'm suspicious of all the mother-hen types: they want to nurture their teams, but tend to smother them. And I'm suspicious of the overly-organized types: they want to bring process to chaos, but process stifles invention, and it can be used to disguise incompetence for an entire career.

I'm suspicious of empire builders; too often they lower their hiring bar. I've heard or seen a hundred reasons for becoming a manager, and I now view all of them with suspicion, because each reason is a potential psychological problem waiting to manifest itself on a soon-to-be-unhappy engineering team.

The point that Steve Yegge makes in the rather long winded post is simple: why you want to become a manager or leader will ultimately define how good a manager you become. More often than not if quest for power is the primary reason that motivates you to become a manager or a leader, chances are that the same reason will start messing up your mind as soon as you get take your first couple of promotions.

I have spent years watching young and budding managers get very excited about their promotion, desperately trying to take control and trying to fix everything that they believe is a wrong in their team. Some of them claiming that they are putting their teams under pressure and trying to bring out the best in them while others claiming that they are working for the best interest of the organization. In most cases however, all they are doing, is satisfying their quest for power.

Put simply, I have seen the quest for insanely insignificant perception of power, corrupt and confuse some of the brightest of the minds that I have worked with.

Today, I leave you, dear reader, a thought worth harping on from Steve's post:

The catch-22 of software management is that the ones who want it most are usually the worst at it. Some people, for worse or for worst, want to be managers because it gives them power over their peers. There's nothing good that can come of this arrangement: you should never give power to someone who craves it, for reasons that I hope are obvious.

If you are a young and budding manager who has just inherited a team and has started out by noticing everything that is wrong with your team or building plans on fixing everything in the next couple of weeks by throwing your new team in an instance pressure environment, I want you to take a long hard pause, do some soul searching and answer the million dollar question:

Why do you want to manage your team, dear reader? Is it really because you want to help, or do you really want to quench your unrelenting thirst for power?

How you answer this question will ultimately decide how you do as a manager. Before you start fixing everything that is wrong in your team, spend some time doing some serious soul searching and find your answer honest answer to this question. If your answer to this question is that you do not want to manage your team at all, chances are, that you will be rather good manager.

I wish you good luck.

Early Monday morning you see Fred approaching your cubical with a usual highly depressed Marvin like look on his face.

You can read his body language and why he is approaching your cubical.

You cringe.

You secretly wish there was something that would make him go away.

Within moments you find yourself listening to sentences which begin with words like we-do-not-have or we-need-to. Every single one of those sentences seems like gibberish to you.

We do not have documentation for all the development scenarios. We need more use-cases. We need a detail design document. We do not have a detailed process. Fred continues and if you spend enough time with Fred you actually start getting convinced about how pathetic both you and your organization are. Fred is depressed and much like Marvin he tends to spread his depression through constant whining, bitching and moaning.

Then it dawns unto you. The realization that Fred is not a bad guy after all. He means no harm. He has just realized that he is not very competent and is having a problem reconciling himself with that fact.  When this happens, it is usually easier to criticize an organization or a 'process' because, well at-lease you are not criticizing a particular human being capable of defending himself.

This, dear reader, is precisely what Fred is doing by criticizing the process or the organization. 

Put simply, Fred, has freaked out. Like a cornered cat, Fred is not looking for a convenient excuse full of complicated jargon where he can burry his incompetence.

Allow him to do that or get away with it and you are setting your precedents loud and clear.

Go ahead, take a deep breadth. Look Fred in the eye and ask him to discuss specific problems connected to the process or people and how to fix them rather than making wide generic statements on a truck load of universal problems. Put simply, ask  Fred to stop whining and start delivering.

I wish you good luck.

In any given year, I get proposals for working on at-least one and sometimes even more than one business idea someone has cooked up. You are sitting with a casual business acquaintance, a sort of a weak tie who introduces you to someone who has been trying to launch a startup. It begins with chit-chat. What I like to call meaningful small talk.

He shares his idea, you tell him why it will not work, he tells you how much he has thought about it, you tell him how he has not thought shit (of course you do this politely). The next thing that happens is you find yourself scribbling things on paper napkins in a restaurant and then you are called for another cup of coffee on the weekend that follows to brainstorm further.

A couple of whiteboard discussion later, people expect you to jump in and get on-board. I don't mean get on-board in an intellectual-exercise-for-the-brain way. I mean get on-board in a get-paid-and-start-working-on-the-project-during-the-weekend way. But what the young and budding entrepreneur does not understand, is that you are not in a committed relationship with the idea. You are just flirting with the idea. I do it all the time.

I like flirting with ideas, stimulating my brain with them. But then, I have serious commitment issues as far as ideas are concerned. So I leave the idea alone and after about a couple of months of no touch, no connection, my relationship with the idea comes to a painful halt. 

That, dear reader, is my typical idea love story.

At any given day my brain is looking at three or more different ideas, flirting with a couple of them for more than a day and then moving on.

These are not the ideas that will make you fall in love with them. These are not the ideas that will keep you up all night. These are not the ideas that will, for lack of a better word, f@#k up your brain and make you slog for hours at the machine. These are not the ideas that will make you give up whatever little personal life you have left on weekends. The ideas that can do all of these are exactly the kind of ideas and projects I love working on.

The problem with genuine ideas that have the potential of making you do all of this, is that no matter how hard you try or for how long you brainstorm on a whiteboard with your weak-ties, you cannot find them.

To put things more specifically, when the time is right, these ideas, find you.

It is a subtle sublime inspiration or incident that brings this idea into your life. You see something drastically wrong with the way the world works and you see how the idea can help you fix it. The idea keeps you up all night. You spend a couple of hours thinking about it. Then you bring up your IDE and code just a couple of screens. A prototype, that would sit there on your machine for weeks as you get busy with your work life.

The difference between this idea and the one you are flirting with, is that you just find yourself opening the IDE and adding just a little bit of code on this project every time you get some free time.

This is not causal flirting. You cannot seem to move on. You keep coming back to the IDE and you keep adding just a couple of functions each day.

Before you know it, you get hooked. Committed. Stuck.

You, dear reader, are in love with the idea.

You have found the idea or to put things slightly more specifically, the idea has found you.

You have no intentions of making money out of the idea, no intentions looking for venture capitalists and turning it into a Google. In fact, chances are that you will not make any money out of the idea and that you are not on your way to becoming a Google either, but you have what we call, a project worth slogging on. A way to make a small dent in the large universe. Something that is fun to work on and a blank canvas where you can draw in bold colors.

If you are a 'practical' entrepreneur who talks about 'business model', 'revenue plans' and 'venture funding' you probably have no freaking idea of what I am talking about here. On the other hand however, if you ever fallen in love with an idea in your life you know exactly what I am talking about here.

What happened to that idea? Are you still slogging away at it during late nights and weekends?

If not, might I use today as an excuse to suggest that you dig from your hard disk, one such idea that had found you, fire up the IDE and just start adding a couple of functions to the project, again. We don't want you to change the universe, just make a dent or two on it. We don't want you to break up with your loved ideas. We want you to bring them to life. Show us what you can build through committed consistency and dedication.

I wish you good luck.

I've always held the opinion that happy programmers are a true reflection of how well your project is going, how much adaption it will get and eventually how much money it will make. After all, it is the happiest programmers within your organization that often, show you the money.

If your programmers do not believe in what they are building and want to quit a project, your only chance of survival or getting that project close to any form of success is letting the unhappy individuals move to projects where they might be happier and getting people who might be more connected to the project, into the project.

If none of the programmers in your organization want to associate themselves with a project, it is high time you rethink what you are building. Maybe even consider closing down the project all together. Chances are, that a team working half heartedly on a project is just going to produce strong or mild variants of f@#k-you code and your project is not going to go anywhere anyways.

Having said that, citing 'Programmer Happiness' as a measure of how successful a project or an organization will be, often causes people to knit their brows and look at you like you just dropped a dead rat on the table.

People in general and organizations in particular that I have talked to, often tend to ask for slightly more objective measures and signs they can use to see if everything is fine at an organizational or a project level.

It is in the interest of a young and budding startups or relatively newer organizations that I present to you, dear reader, my very own personal guidelines on when you should be nudging your team members to raise a red flag, stop working like programmed robots and bring the issue up, even if it involves indulging in what I call a skip.

At an Organizational Or Team Level It Is Time To Raise RED flag If:

1. Your daily meetings or daily project calls are consistently crossing thirty minutes and your team is getting addicted to meetings.
2. Your team is consistently staying late without being particularly excited, happy or passionately connected to the project.
3. Your team is consistently doing regular grunt work, like pushing a build or fixing bugs, even on weekends.
4. Your team is not taking any happy hours.
5. Your team is being constantly asked to build features which are not really needed.
6. Your team or you are confused about where your role stops and where the role of your manager begins.
7. Your team is facing constant intimidation from a client or a manager.
8. Your team is allocated tasks with concrete timelines without having any involvement or say in those timelines.

At a Development Level It Is Time To Raise A RED flag if:

1. Your team has parts of the project or the database which are not being checked into the source control system.
2. Your team crosses more than a month and a half without shipping any new sprint or any new features.
3. Your team works on and ships more than three sprints without any real feedback from a real beta user.
4. Your team consistently writes functions that do not fit a screen. 
5. Your list of 'Active Critical Bugs' consistently shows a scroll bar and does not fit in a screen.
6. Your project requires a developer to carry out more than ten manual steps to get the source control system, set it up and fire a build.
7. Your team tends to have an alpha-geek who often decides all critical design decisions with very little scope for discussion or argument.

The list of course is very basic and will grow over time. In fact, this is where I expect you, dear reader, to throw in some comments.  If you, are a manager running multiple projects or an entrepreneur running an organization which RED flags would you want your team members to bring to your notice as soon as they happen? If you are a developer which RED flags would you like to raise as soon as they happen?

Go ahead, drop in your comments. Discuss.

In a blog-post on your your code being a one way time machine, David Robbins identifies a special enemy from the past that can do you more harm than anyone else: yourself.

David explains:

What type of duress are you under?  The unfortunate among us have been sentenced to slavery by our evil nemesis from the past.  We all have this enemy, and at one time or another have succumbed to the enemy’s evil plot.  The enemy from the past is 'you'.

A huge part of your life as a software development is all about making decisions. How much code do you really need, how much time are you spending on thinking about your functions, do you need to start extracting till you drop or for now are you just going to ship a shitty version with bugs and get better over time. Every decision that you take will define your relationship with the you-from-future.

To be honest, most of these decisions are simple pragmatic decisions based on common sense and yet year after year I see developers building software and projects which are nothing less than Frankensteins. I see young and budding developers letting their desire to flex their engineering mussels guide the platforms or technologies they pick and not even bothering to fix broken windows as the speed along their career highway.

You primary responsibility as a developer is not to build a highly scalable enterprise application or to work on that really complex software development project. Your only true moral responsibility as a developer is to be reasonably good to the you from future and not sentence him through a painful infinite loop of failure. 

The more time and effort you invest in being honestly nice to the-you-from-future, the more at peace you will be with your greatest enemy from the past when the future arrives. Now go spend time and conscious effort in being nice to the you from tomorrow. Try keeping that patterns and practices book or that coolest data access framework on the block aside for one moment and take a few pragmatic decisions that will work for 'you'.

The you-from-future might actually thank you for it.

I wish you good luck.

If you worked with me years or even months ago, chances are that I have lost your phone number. Chances are also high that I have not kept in touch with you. Like most programmers, I knit closely with you when you are working with me and then when our ways part, I disconnect.

But then, I have nothing against you.

It is just that when you move on and do not connect on a daily basis, that familiar system of connection is gone. Conversations with you, have to begin with small talk again and like most programmers, I am not very comfortable with the idea of small talk. So, I tend to totally disconnect totally.

The paragraphs above pretty much sum up a huge part of my school life and a huge part of my early life as a young and budding programmer. Put simply, as a school student, a college graduate and a young programmer, I connected to a very small group of family members, friends and colleagues.

If you did not know me personally and if we did not spend hours having deep conversations every week, you would make me very nervous. What I, dear reader, as a youngster, failed to understand, was the power and value of keeping in touch and learning from acquaintances.

Put simply, as a youngster I did not 'get' the whole point of what Malcolm Gladwell, in his book, the tipping point, describes as 'weak ties'. Malcolm explains the power of 'weak ties' with a very simple example:

In his classic 1974 study Getting a job, Granovetter looked at several hundred professional and technical workers from the Boston suburb of Newton, interviewing them in some detail on their employment history. He found that 56 percent of those he talked to found their job through a
personal connection.

Another 18.8 percent used formal means — advertisements, head hunters — and roughly 20 percent applied directly. This much is not surprising; the best way to get in the door is through a personal contact.

But, curiously, Granovetter found that of those personal connections, the majority were "weak ties." Of those who used a contact to find a job, only 16.7 percent saw that contact "often" — as they would if the contact were a good friend — and 55.6 percent saw their contact only "occasionally." Twenty-eight percent saw the contact "rarely."

People weren't getting their jobs through their friends. They were getting them through their acquaintances.

Why is this? Granovetter argues that it is because when it comes to finding out about new jobs — or, for that matter, new information, or new ideas - "weak ties" are always more important than strong ties. Your friends, after all, occupy the same world that you do. They might work with you, or live near you, and go to the same churches, schools, or parties. How much, then, would they know that you wouldn't know?

Your acquaintances, on the other hand, by definition occupy a very different world than you.

They are much more likely to know something that you don't. To capture this apparent paradox, Granovetter coined a marvelous phrase: the strength of weak ties. Acquaintances, in short, represent a source of social power, and the more acquaintances you have the more powerful you are.

My first hand experience with the power of 'weak ties' came after about a year and a half of blogging when this blog landed me with my first job offer. Months later I received another. While I humbly declined both of them, what deeply moved me, was that I had touched and connected to a person who I hardly knew in real life and who, merely by the virtue of my writing was able to extend an offer to me.

But this isn't just about job offers or the power that 'weak ties' brings you.

After a while that bit, becomes boring.

It wears out.

What remains fascinating is just how much you can learn through some of these 'weak ties'.

This Saturday morning I made a new acquaintance with a hokey player who taught me something about perseverance. He talked at length about how, grace of god, luck and consistency have a great part to play in everything you take up. These two together, he believes, helped him get his Olympics gold medal.

The evening was spent, chatting with a school friend who had drifted into the finance world. He gave me a few tips on making some money in the stock exchange. We discussed investments and the possibility of my being able to help him in a small fun project that would help him build investment models using a SQL server backend and a decent enough front end.

Both conversations, somewhere deep down, inspired me to become a better developer, a better professional and above all a better human being in general.

While we as developers, often spend hours talking to the compiler and our evenings with friends and family, we often miss out of the importance of connecting to your acquaintances or even strangers every now and then. We miss out on the fun of striking meaningful conversations with them and we miss out on the opportunities of learning from these conversations.

Even today, as I reach out to countless 'weak ties' and acquaintances I have been guilty of not making myself accessible to and learning from countless others.

If my statistics serve me right, this blog alone, is visited by, a few acquaintances I can learn from. A few very bright minds I can connect to and have meaningful discussions with. It is in the spirit of learning, participating and sharing experiences that I am starting my very own little corner in facebook.

You, dear reader, are invited to join in.

I will be scribbling on the wall there every now and then, posting a question or a discussion when I need your advice on a specific problem and above all, I will be reaching out and connecting to anyone who wants to connect.

It is an open group so anyone can join in and if you are regular reader of this blog I hope to see you there.

Now, take a pause and go figure out your ways to connect to all your acquaintances or 'weak ties', start meaningful conversations with them and learn from them.

I wish you good luck.

Fred is a young and budding engineers trying to start his new business venture with an idea that he believes will change the world. As he sits right across the table and talks, I can make out that he is attached and almost obsessed with the idea of protecting his idea like a baby:

Long story short, anyone talking to Fred can make out that he has spent weeks in:

1. Cooking up an idea.
2. Doing paperwork around the idea.
3. Building PowerPoint presentations around the idea.
4. Fantasying how he is going to become rich after the idea clicks.
5. Making sure he can screw anyone who tries to steal his idea.

There is, however, just one little problem with his idea. It is not genuine, it has nothing new in it and it is not even worth spreading, leave aside stealing it. The success of this idea, like most others, is truly dependent on the implementation of the idea. Derek Sivers describes the concept much more articulately in his post on the topic. He explains:

It's so funny when I hear people being so protective of ideas. (People who want me to sign an NDA to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

Explanation:

AWFUL IDEA = -1
WEAK IDEA = 1
SO-SO IDEA = 5
GOOD IDEA = 10
GREAT IDEA = 15
BRILLIANT IDEA = 20

NO EXECUTION = $1
WEAK EXECUTION = $1000
SO-SO EXECUTION = $10,000
GOOD EXECUTION = $100,000
GREAT EXECUTION = $1,000,000
BRILLIANT EXECUTION = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20.

The most brilliant idea takes great execution to be worth $20,000,000.

That's why I don't want to hear people's ideas.

I'm not interested until I see their execution.

Now there is reason why Fred has worked for hours on making PowerPoint presentations, word documents and dreams around how he will take the idea to the next level when the idea clicks, but he has not done a single screen to try and implement the idea or do a small prototype. The reason is simple - cooking up ideas and day dreaming is easy. Implementing those ideas and giving shape to those dreams or visions is hard.

Besides, somewhere deep down in his mind, Fred knows that doing an implementation and throwing his idea out in the hands of real people will most probably get his idea a reality check which is the last thing he needs right now.

Paul Buchheit describes his effort during his work during the early Gmail days. He explains:

We starting working on Gmail in August (or September?) 2001. For a long time, almost everyone disliked it. Some people used it anyway because of the search, but they had endless complaints.

Quite a few people thought that we should kill the project, or perhaps "reboot" it as an enterprise product with native client software, not this crazy Javascript stuff.

Even when we got to the point of launching it on April 1, 2004 (two and a half years after starting work on it), many people inside of Google were predicting doom. The product was too weird, and nobody wants to change email services. I was told that we would never get a million users.

Rolling your first prototypes out is usually something which requires nerves of steel. It means quite a few things.

1. It means that you need to be serious and committed to  your idea - so much so that you are actually willing to slog midnights for it and you  are willing to do it consistently, for years.
2. It means that you are capable of shaping the dream into something concrete - you are a doer not just a dreamer.
3. It means that you have the thick skin to take those feedbacks and even at times, acts of bozoism with a grain of salt and continue working on your idea anyways.

All of the above three, tell us, your users, that you are serious about your idea. That your idea is not a quick gimmick to get our money. That your idea is not just a random distraction which you are going to dump tomorrow morning when you wake up and when your dream comes to an abrupt end.

Your ideas don't need you to protect them from getting stolen. They need your implementation, hard work and commitment. For years.

Now, stop discussing that PowerPoint presentation and stop talking about the business model around your idea. Show us a prototype. If you do not have that yet, figure out how you are going to build it. Go build something real and then show it to us.

I wish you good luck.

You have just finished patting yourself on your back for getting a team of seriously kick ass developers up and running. The team has not just flocked together, they have actually proved to you that they actually have the secret sauce for success. Products are on time. Customers love your organization. The sky is blue and it is not even falling.

You think of giving yourself the liberty to feel really happy about the amazing work environment and the work culture of your organization.

That is when Jack walks into your cubical and tells you that he isn't feeling motivated enough.

Jack, dear reader, has a problem.

A problem that he himself, in his very own words, describes as - 'Too much freedom'.

You know where this is going.

You see is that of Morpheus from The Matrix holding up a battery and saying - "The Matrix is a computer-generated dream world built to keep us under control in order to change a human being into this.'

You cringe.

'Shut up and listen to him' - you tell yourself as you intently listen to Jack describing his problem.

Sitting right across the table, Jack, dear reader, is telling you that he needs more monitoring, stringent deadlines and above all what he calls a 'big hard push' so that he can get things done. Not everyone is self motivated - Jack tells you. Jack wraps the discussion by telling you that in the absence of artificial deadlines and constant monitoring he is not feeling motivated enough to get things done.

Then as you sit there and reflect really hard you realize that Jack is not looking for motivation. He is looking for fear. Fear that can drive him to get his job done. Fear that can force him to grow his branches far and wide even if he does not really feel motivated to grow deeper roots.

What Jack is trying to do, dear reader, has its root back in the pre-historic era and how the human race evolved. Dragos Roua describes this phenomenon much more articulately than me. He explains:

Our brain has a very deep connection with fear. Deep in our limbic brain (the oldest part of our brain, also called the “reptilian” brain) lies the centers of fear. On top of them other layers of our brain have grown. But the deeper core is still there and it can still be activated.

Whether we like it or not, we’re still conditioned to act on fear. Our limbic brain is still stimulated by a variety of factors.

We translated our old fears related to survival to our modern indicators of success: we’re afraid of being taken for less than we are or we’re afraid that somebody talks bad about us. We’re afraid that we’re going to lose something if we’re not talking “immediate and aggressive” action towards the potential danger.

What Jack, dear reader, is asking you to do, is basically stimulate his limbic brain. Put simply, Jack is asking for a shot of fear-based-steroids so that he can play a few power-shots in his professional life.

Dragos, in the same article, also describes why the basic approach can be fairly lethal in the long term. He explains:

Negativity is powerful.  Every time you’re afraid, you’re giving your focus and power to the potential danger. All your energy must be there, because your reptilian brain is telling you’ll have to survive. Doesn’t matter for that reptilian brain if the fear was socially induced, if you scream “fear” it will be activated.

The more fear factors you have, the more energy you’ll have to allocate. And you’re going to pay attention to a lot of potential dangers. Sooner than you think, you’ll measure your success by the rate of your survival actions. And you’re becoming accountable to your fear sources. You’ll be actually driven by your fear sources. This is why a fearful person is so easy to manipulate.

Turning human beings into batteries is what most software development shops around the world are so very good at. We tend to refer to people as 'resources' and use every arrow in our management quiver to strike terror in those 'resources' so that we can improve their productivity. You realize how bad things are when the best of your people come to you begging for shots of fear-based-steroids, under the excuse that not-everyone-is-self-motivated.

I leave you, dear reader, with one little thought worth harping on. You might not be self motivated. Motivation may not come from within, but that is not an excuse for not looking for your own motivation yourself; and while you are at it, you might want to look for it really hard; because if you do not look for your motivation, it will not come looking for you.

Take a few shots of fear-based-steroids and you might be a 'resource' that runs on a battery before you know it. And then when that happens do not crib about how big an ass-hole your manager is.

Now go read a few books, watch TED videos, play around with some seriously interesting technology you feel passionately about or find your own avenues of looking for getting constant motivation.

I wish you good luck.