free html hit counter
Posted on: Sunday, February 7, 2010 by Rajiv Popat

Understanding The Significance Of Weak Ties In Your Professional Life.

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.

posted on Sunday, February 7, 2010 11:42:47 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Saturday, February 6, 2010 by Rajiv Popat

Leadership Tip: Your Ideas Do Not Need Your Protection - They Need Your Commitment.

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.



GREAT EXECUTION = $1,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.

posted on Saturday, February 6, 2010 11:57:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, February 5, 2010 by Rajiv Popat

Programmer Tip: Consider Looking For Your Own Sources Of Motivation.

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.

posted on Friday, February 5, 2010 7:03:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Sunday, January 31, 2010 by Rajiv Popat

Programmer Tip: Consider Taking A Couple Of Happy Hours Each Day Of Your Life.

On a typical day that looks like any other, for anything between three to ten hours, I am an employee.

Most of that time, I spend firefighting.

Fred wants to a discussion regarding his salary, Jack is having a problem with the data-access layer, somewhere the sky is falling. I'm adapting, prioritizing, talking, taking decisions and above all I am reacting to random uncertainty as it rolls my way.

Then there are days at a stretch when I cannot seem to get much done.

Seventeen emails I have not responded to sitting in my inbox. I just missed a status call. Last I checked I was going to get back to Jack in the couple of minutes. It's been two hours since I told him that.


Then the magical time of the day happens. Usually, this is late evening for me. When the cubical farm is quite. When I am not speeding. When I am not cruising on employee-auto-pilot-reactive-mode. This is when I am not assertive. I am not running around solving problems. I am not in meeting rooms. I am not scribbling things desperately on the whiteboard trying to make a point. This is when I am not ATL+Tabbing between applications.

Late evenings, for me dear reader, are my happy hours.

This is the time, when I set those crazy baby neurons free and let them wander where they feel like wandering. I give these neurons the liberty to fail; even make a fool of myself.

Sometimes, it is a new idea for a blog post. Sometimes, it is a new technology that I am trying to dissect and understand which will later turn into a training session for my team. Sometimes, it's an open source framework I am playing with which I will later release.

Sometimes, it is just a few webcasts or just a few videos containing deeper insights into the human mind. Sometimes it will just be playing with new ideas that will not let go till they become product features or new products.

Put simply, my happy hours are the time when I am working, sometimes even for my organization, but I am doing so without wearing my employee cap. This is when I am going slow. Without trying to prove a point. Without desperately trying to get things done. Not just enjoying, but actually loving, whatever it is that I am working on. This is my disconnect from a system that is designed to turn you into a robot.

I love my happy hours.

Most organizations around the world feel hugely insecure with employees spending happy-hours. I had my share of these organizations until I stumbled upon my current organization, where happy hours were not just acceptable, they were actually encouraged. Today happy hours are an integral part of our leadership.

So much so that every once in a while I find myself giving appraisal feedback to individuals I am promoting: You are way too strongly attached to the organization. You need to detach for a couple of hours, look outside and bring the learning back into the organization. You need your happy-hours.

Its your happy hours that will make you much more valuable as an employee. It is what you learn in these happy hours, that will become your long term investment for your career in your organization. It is your happy hours that will empower you to steer your organization or your team members in directions that they never thought of taking while they were busy fire-fighting or doing what they were told to do.

So the next time you have the outlook window blinking with seven follow up icons, code waiting to be written, problems dying to be solved - ask yourself if you are completely ignoring your happy hours in the midst of blinking meeting reminders, pending email responses and long To-do lists.

The employee mode won't take you far, not even as an employee.

Go ahead. When you get a chance, disconnect and take your happy hours. You will be doing yourself and your organization a favor.

I wish you good luck.

posted on Sunday, January 31, 2010 8:53:00 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, January 30, 2010 by Rajiv Popat

Programmer Tip: No One Really Cares About Your Failures.

Jack, a young and capable developer is starting out his development blog by hiding behind the mask of anonymity.

He is concerned that his blog posts are not mature enough and that he still hasn't found his style of writing. He prefers writing anonymously because it allows him to learn how to write without his friends, family or juniors finding out how much he sucks at it.

When I hear Jack mention this over a conversation at a friendly neighborhood food joint, I cringe.

There is nothing wrong with anonymity. Which name a man writes under, is every man's own choice.

What irks me however, is an overly conscious attitude towards failure and the active effort being put behind hiding how much you suck.

In the world where I live, spending time and effort behind shit-canning how much you suck seems like an utter waste of time. Everyone successful at what they do, that I know of, is often rather open and candid about how much he sucks.

Steve Yegge for example, in his classic post on Languages, makes a rather honest, open and direct confession followed by his attempt at sucking less each year. He explains:

When I started at Amazon, I could recite for you all the incantations, psalms, and voodoo chants that I'd learned, all in lieu of intelligence or experience, the ones that told me Multiple Inheritance is Evil 'cuz Everyone Says So, and Operator Overloading Is Evil, and so on. I even vaguely sort of knew why, but not really.

Since then I've come to realize that it's not MI that sucks, it's developers who suck.

I sucked, and I still do, although hopefully less every year.

Legendary author Steve McConnell describe the idea of accepting how much you suck rather articulately in his classic book Code Complete. He explains:

What? You don’t have to be super intelligent?

No, you don’t. Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time.

The way you focus your intelligence is more important than how much intelligence you have. At the 1972 Turing Award Lecture, Edsger Dijkstra delivered a paper titled “The Humble Programmer.” He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are.

They are humble.

The people who are the worst at programming are the people who refuse to accept the fact that their brains aren’t equal to the task.

Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you’ll be. The more humble you are, the faster you’ll improve.

In one of my earlier post, I describe how no one cares about you and while a couple of people were really angry at the post, the bright side of no-one caring about you, is the fact that they do not even care about failures.

Mark Cuban describes the idea of using this could-not-care-less attitude of the world around you to your advantage using a single quote. He explains:

It doesn’t matter how many times you fail. It doesn’t matter how many times you almost get it right. No one is going to know or care about your failures, and neither should you. All you have to do is learn from them and those around you because... All that matters in business is that you get it right once. Then everyone can tell you how lucky you are.

A good way to start wrapping this post up, would be with an inspirational ad from Nike, where Michael Jordon is heard speaking the words of wisdom:

I've missed more than 9000 shots in my career. I've lost almost 300 games. Twenty-six times I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed.

Today, I leave you, dear reader, with a word of advice: stop taking yourself seriously. Start flaunting your failures, accepting how much you suck and above all start sucking less each year. And no, you don't have to worry about the whole world finding out, because no-one is watching. They just don't care. Remember?

Now, stop shit-canning your failures and fail in remarkable new ways like a baby.

I wish you good luck.

posted on Saturday, January 30, 2010 11:05:22 PM UTC by Rajiv Popat  #    Comments [6]
Posted on: Friday, January 29, 2010 by Rajiv Popat

Programmer Tip: Consider Coding In Silence Or Switching To Pair Of Head Phones.

Jack codes quietly during the day. He is a seriously kick-ass programmer at work. Later during the evening, as the number of people in the cubical farm go down, Jack transforms into a musical rock-star dying to share his musical taste and collection to the whole wide world.

I cringe as I listen to the speakers of Jack's laptop buzzing away to glory.

"Headphones people. Use a freaking set of headphones." --- I think.

Then quietly, I grab my laptop and head in search of a quite conference room that will allow me to work.

Demarco and Lister in their legendary book, the Peopleware discuss issues associated with programming while listening to music:

During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. They polled a group of computer science students and divided the students into two groups, those who liked to have music in the background while they worked (studied) and those who did not. Then they put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection.

Participants in both rooms were given a Fortran programming problem to work out from specification. To no one's surprise, participants in the two rooms performed about the same in speed and accuracy of programming. As any kid who does his arithmetic homework with the music on knows, the part of the brain required for arithmetic and related logic is unbothered by music—there's another brain center that listens to the music.

The Cornell experiment, however, contained a hidden wild card. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream. For example, participants had to shift each number two digits to the left and then divide by one hundred and so on, perhaps completing a dozen operations in total.

Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input number. Some people realized this and others did not. Of those who figured it out, the overwhelming majority came from the quiet room.

Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it's the brain's holistic right side that digests music.

But not all of the work is centered in the left brain. There is that occasional breakthrough that makes you say "Ahah!" and steers you toward an ingenious bypass
that may save months or years of work. The creative leap involves right-brain function. If the right brain, is busy listening to 1001 Strings on Muzak, the opportunity for a creative leap is lost. The creativity penalty exacted by the environment is insidious.

Since creativity is a sometime thing anyway, we often don't notice when there is less of it. People don't have a quota for creative thoughts. The effect of reduced creativity is cumulative over a long period. The organization is less effective, people grind out the work without a spark of excitement, and the best people leave.

The whole left-brain-right-brain argument has been a question of argument amongst neuroscientists for years and I don't know if there is such clear demarcation between left-brain and right-brain. Having said that, the fact that your brain is just not designed to multitask is rather well known.

Quite work environments are so important that I have often gone ahead and proposed a silence room for every office in planet earth. Silence and quite working environments are so important to most kick ass developers that Jeff Atwood has decided to make it a part of his Programmer Bill Of Rights. He explains:

Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.

True, music serves as a nice distraction from other conversations, noises and crazy distractions that you might come across in a typical cubical farm; but when picking between music or silence while programming I would pick silence any day.

You, dear reader, are free to pick music, if you are still not convinced, but if you do pick music over silence, do me a favor. Be a nice citizen of the developer community, think about being considerate to your fellow developers who may not share the same opinion as you. You are not a radio station and unless we tell  you so, we are not interested in listening to songs you want to make us listen today.

Now, if you must listen to music as you code, grab a pair of head phones and use them. Do not make us listen to your collection of songs. Seriously.

posted on Friday, January 29, 2010 9:05:00 PM UTC by Rajiv Popat  #    Comments [4]
Posted on: Sunday, January 24, 2010 by Rajiv Popat

Understanding A Simple Fact Of Life - Basic Traits Of People Usually Do Not Change Easily.

As managers, leaders or whatever it is that we like to call ourselves, we have a tendency to think of ourselves as mentors, helpers and protectors of people who work with us.

As a part of this tendency, it is but natural to get tempted to help your team member change himself every time you see a fault or a weakness in the person. After all, if you can push hard enough the person might change, improve and grow to be a better individual.

If you are a young and budding manager, chances are that every once in a while you find yourself spending time in a one-on-one with a person in your team. You  find yourself trying to mentor him, help him give up a weakness or fix a basic problem in his character.

Then as months go by, you learn that all you did with the person in that one on one was that you wasted his time and you wasted your own time.

As you grow older, you tend to implicitly and unknowingly learn the cardinal rule of management - people do not change their basic traits and character over time.

Markus Buckingham and Curt Coffman, describe this basic rule of management in their book First break all the rules, using a simple research on neuroscience:

At birth the child's brain contains one hundred billion neurons, more brain cells then there are stars on the Milky Way. These cells will grow and die regularly throughout the child's life, but their number will remain roughly the same. These cells are the raw material of the mind. But they are not the mind. The mind of the child lives between these cells. In the connections between the cells. In the synapses.

During the first fifteen years of life, the carving of these synaptic connections is where the drama unfolds.

From the day she was born, the child's mind begins to reach out, aggressively, exuberantly. Beginning at the center of the brain, every neuron sends out thousands and thousands of signals.

They are trying to talk to one another, to communicate, to make a connection. Imagine everyone that is alive today simultaneously trying to  get in touch with 150,000 other people and you will get some idea of the wonderful scale, complexity, and vitality of the young mind.

By the time the child reaches her third birthday the number of connections made is colossal - up to fifteen thousand synaptic connections for each of it's one hundred billion neurons. 

But this is too many. She is overloaded with the volume whirling around inside her head. She needs to make sense of it all. Her sense. So during the next ten years or so, her brain refines and focuses on its network of connections. The stronger synaptic connections become stronger still. The weaker ones wither away.

Dr. Harry Chugani, professor of neurology at Wayne State University Medical School, likens the pruning process to a highway system:

"Roads with the most traffic get widened. The ones that re rarely used fall into disrepair."

If she ends up with a four-lane highway for empathy, she will feel every emotion around her as though it were her own. By contrast, if she has a wasteland for empathy, she will be emotionally blind, forever saying the wrong thing at the wrong time to the wrong person - not out of malice, but simply out of an inability to pick up the frequency of the emotional signals being sent.

The carving for these pathways is the carving of her character. Neuroscience is telling us that beyond her mid-teens, there is a limit to how much of her character she can recarve.

Neuroscience confirms what great managers know. Her filter, and the recurring patterns of behavior that it creates, is enduring. In the most important ways she is permanently, wonderfully, unique.

So are you. And, of course, so are the people you hire.

Your job as a leader is to best utilize the strengths and if possible even harness the weaknesses of your team members. It is not to try to fix every single weaknesses or to eradicate every fault out in your team. People with high degree of emotional attachment being moved over to PR departments and flourishing there is one simple and classic example. Keep your eyes open and you will find multiple others.

You might be able to teach people new skills and technology, but if you are trying to teach someone how he can feel empathy towards others, or why he should be lying less, you are probably wasting his time and your time.

Every time you find an issue with the basic trait or character of a particular individual, trying to fix the issue is a waste of everyone's time. Hoping that you will be able to fix the weakness is hoping for too much. If glaring issues exist with an individuals personality, character or basic trait and you believe that these issues will be a problem in letting him flourish in his work, you might want to:

  1. Consider not hiring the individual if you can (unless of-course you can find a different role where he fits really well).
  2. If you are stuck with an individual, you have spent umpteen numbers of hours trying to fix a problem and your organization lacks another role where he fits, asking a person to leave your organization might be an option. It is hard, but most veteran managers will tell you that you are a management virgin till you have done this at-least once.
  3. Finding him a role where he can utilize his weaknesses and turn those into his strengths - if you can do this, you can pat yourself on your back, because this dear reader, is the biggest 'help' you can extend to someone. This is what leadership is all about.

Remember, next time you see someone in your team with a weakness in one or more of his basic traits, do not focus on trying to fix the weakness. Instead, focus on finding him a role where he can utilize his weaknesses and turn those into his strengths.

I wish you good luck.

posted on Sunday, January 24, 2010 10:43:30 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, January 23, 2010 by Rajiv Popat

Understanding And Avoiding The Serious Perils Of F-You-Code.

During its early days Multiplitaxion Inc, was a dramatic company with equally dramatic projects, every single one of which could have been quite literally turned into a small documentary or a movie. Of those projects a particular one, which for the purposes of this post, we shall refer to as 'Project-Rocket-Science' introduced me to, what I later started referring to as F@#K-YOU-Code.

The story started out with Fred intimidating a team member to write a piece of code that would transmit a file over a message queue which would then, at a later stage, transmit the file over to the client. The message queue was locked down there were serious issues with submitting requests to it.

Both pressure and intimidation on the developer were increased to get the job done on time so much so that we could see the tension in the developer's eye. He was quite literally working sixteen hours a day and was getting seriously nervous about the fact that he was facing a problem and no-one cared to help. Every time he went to Fred seeking help he returned, with his hands full of insulting remarks.

Then one fine morning it happened. The Breakthrough. Clicking the 'transmit' button on the screen showed the message 'file transmitted' and the entire team rejoiced. Soon multiple other complicated problems in the project started getting solved almost magically. The project was back on time, and the pressure and intimidation-levels came down.

A couple weeks later, as the project started nearing the testing phase, two of the best developers, including the developer who was working on the file transmission piece resigned and left the organization. Then others started following.

The couple of guys that remained in the team continued with the project.

A few days later, as the project moved into the testing phase, a tiny little bug appeared on the bug tracking system which was titled --- 'File is not getting transmitted when the transmit button is clicked'.

When Jack, who was a young and budding developer was brought over to the project and assigned this bug; he decided to study the code and get to the root cause of the bug. It took him less than ten minutes to get to the root cause and when he showed us what he had found, every single one of us laughed inwardly and at the same time we felt a chill run down our spines.

Embedded behind the click event of the button were two lines of code which read:

// No immediate fix was found for the file transmission issue. Will be fixed later.
Response.Write("File Transmitted.");

Jack, said in a as-a-matter-of-fact, cold blooded tone - 'it is not a bug. The code never did anything other than display a message of successful transmission'

Then after a long pause, he remarked, 'why would anyone do something like this?'

My response was rather spontaneous and unplanned --- It's F@#K-YOU-Code. That is what he wanted to say when he was writing this.

The person who wrote the two lines wanted to send a very clear message to Fred through these two lines of code, before he got sick and tired of the insults, the intimidation and the pressure. Before he resigned, he had cracked the biggest practical joke that I ever saw in my career and it took us two weeks and a QA cycle to catch his practical joke. By the time we did, he was gone.

But the dramatic twists of this real life story do not end here.

When Jack went back to Fred, and tried to explain to Fred how what he was trying to fix was not just-a-bug. It was functionality that he would implement and that it would take time, Fred pretended like he was not hearing English but a totally different language.

Jack was now under the intimidation and intense pressure spotlight. Jack worked for two weekends and spent more than sixteen hours a day trying to replace the two lines of practical joke with genuine code that actually transmitted the file. Then on a Friday Jack was told that he was causing the project to stall and the fact that he was not being able to resolve a simple bug, was causing serious doubts on his competence.

The following Monday, we heard about Jack's resignation. This bit was expected.

What was not expected however, was that, on his last day, Jack logged into the bug tracking system and marked the bug as 'Resolved' and in the comment field added a line - 'resolved using the same approach of original implementation'.

As you would expect, the bug of course, was not resolved.

When we asked Jack what he meant by what he wrote in the comment field of the bug tracker he responded with a rather sarcastic smile. We knew what it meant - 'F@#K-YOU-Code, F@#K-YOU-Resolution' - the bug was quite literally 'resolved' using the exact same approach of the original implementation. Jack did not do a thing to fix the code. He just went to the bug tracker and marked it as resolved on his last day at work.

Three weeks after Jack resigned, the organization discovered that all the other complicated problems in the project that had started getting fixed were also fixed using F@#K-YOU-Code, written by people who had planned their resignation and left before they were caught.

The project went into a nose dive.

As someone who was not directly connected to the project, I saw the team members who were directly connected run for cover.  As for Fred, no-one did a root cause analysis of why the project failed and Fred was moved to manage another project.

Of-course, no-one in the 'upper management' could have even thought about developers writing F@#K-YOU-Code as a symptom and intimidation as a root cause for a project failure.

They were busy looking for more complicated reasons like - The-Requirements-Were-Not-Clearly-Defined or The-Scope-Was-Not-Correctly-Measured.

Even though this was a hugely dramatic, one in a million example of F@#K-YOU-Code that you get to see in your professional life, even today, every once in a while I see developers write subtle examples of F@#K-YOU-Code every time they are cornered using tools like insult and intimidation. Of-course they don't plan their resignations and crack practical jokes as huge as the one I witnessed, but every time they are cornered, chances are that they will litter the codebase.

They will leave a broken window with a F@#K-YOU-FOR-CORNERING-ME message silently and subtly embedded in the codebase without even knowing or fully realizing that they are doing so.

F@#K-YOU-Code might be causing your project to fail right now and you may not even know it.

Talk to your developers, make them feel at home, do not (and I cannot emphasize this enough) use an intimidating or a condescending tone while talking to them. Encourage them to bring problems out in the open and when they do, stop playing the blame game and help them fix the issues.

I wish you good luck.

posted on Saturday, January 23, 2010 10:29:51 PM UTC by Rajiv Popat  #    Comments [0]