free html hit counter
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]
Posted on: Friday, January 22, 2010 by Rajiv Popat

Management By Intimidation Is Downright Stupid And Risky.

Fred sits high up on the pecking order of Multiplitaxion Inc. He is notoriously famous for meticulously planning his projects by the man-hour and maintaining hugely elaborate Gantt Charts which he uses to track people by-the-day.

He is in control.

When did Jack the developer come in today morning. How many hours of work did he do today. What did Jack do yesterday.

Fred knows it all.

Panic buttons, artificial deadlines, pressure techniques - Fred has has all the arrows in his management quiver.

Arrows which he fires from time to time.

And then there is a secret arrow which never misses its target, even if all the other arrows do not work.


The use of I-am-highly-disappointed-in-you line of conversation is just for starters. Fred can go far in this line of discussion and he can seriously make you hate yourself after just thirty minutes with him in a meeting room.

Fred is young. Fred is taking his first steps of professional management. Fred is ambitious and merciless. Fred, dear reader, is getting things done.

Fred has tasted success with Management-by-intimidation and he has no intentions of stopping.

I see Fred function and I cringe.

More than I feel sorry for the people that work with Fred, I feel sorry for Fred himself.

What Fred is doing, dear reader, is pretty similar to drunk driving. You feel the rush of adrenalin in your nerves, you feel like the top of the world and you keep moving faster till you crash your way into a sudden accident.

With Management-By-Intimidation the sudden accidents happen when you forget:

  1. There are people sitting higher up than you in pecking order.
  2. Even though some of them are really nice-to-work-with-even-when-the-sky-is-falling they can be really big a@#holes when they spot a@#holes and have to deal with them.
  3. Just when you think that no one is watching you intimidate young engineers fresh out of college, someone who is higher up in the pecking order and can be a bigger a@#hole than you if he wants to be, is either watching you or will find out.

Monica Burns-Capers describes this in her article on Management by intimidation. She explains:

Managing by intimidation is never the right way in any organization. If it has worked for you now or in the past, you’ll soon regret it. While you are busy intimidating your staff, someone in a higher position is paying attention. You think you are getting away with it because nobody has said anything. You’re not. It’s only a matter of time now. The higher-ups are waiting on you to hang yourself. And you will. You can’t possibly think that your intimidation will go on forever. When you hang yourself, watch how far down the hill your career starts to plummet. It’ll go so far down, you won’t be able to see it anymore.

So if you want longevity in your career and you want to gain the respect of your subordinates and your colleagues, learn to give them respect first. Tell them that they are doing a good job sometimes. Reward them for their work.

Manage your staff by the knowledge and people skills that you posses. Besides, isn’t that what got you the position in the first place.

Even in the most bureaucratic of organizations, if you work hard at making yourself hated and disliked, you will eventually be hated and disliked, consistently across the organization.

When you play around with intimidation as a tool, you typically get a lot more attention as a manager and you create huge ripples (sometimes even waves) in the organizational pond.

If you ask me personally, I have seen more than a dozen managers who believed in the idea of intimidation get fired and yet, every year, I bump into at-least one or two managers who tend to practice the art of management-by-intimidation, within closed doors of meeting room. Every single one of them seem to believe that no-one in the pecking order above them will find out and as long as things get done.

Almost invariably, every single one of them tend to become insanely famous as a@#holes and end up collecting dislike and hatred enough to get them fired.

Remember, management by intimidation is pretty much like drunk driving. It is not just a stupid thing to do, it is actually pretty risky.

I leave you, dear reader, with a word of advice: even if you are having a bad day or you are getting a strong urge to shout at someone, be nice. It helps you much more than the person you are being nice to.

Empathy happens to be much more powerful arrow to have in your quicker and it is just as accurate when it comes to hitting the bulls-eye. Go ahead, and replace intimidation with empathy and you just might see some serious magic in your work life.

I wish you good luck.

posted on Friday, January 22, 2010 10:41:46 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Sunday, January 17, 2010 by Rajiv Popat

Avoiding The Typical Software Development World Stereotypes - Part 2.

Your Geek Isn't Shy. He Is Just Not 'At Home' Yet.

Even though I cannot describe my school life in the friendly neighborhood Indian school as traumatic, but I often use the word 'painful' to describe it rather accurately. From arguments with teachers, to being yelled at by the principal for not getting insanely short haircuts, if there is one thing school did in my life, it is that it left painful scars on my personality that took years of passionate software development to wipe out.

Through the twelve years of schooling I was labeled multiple times.

Here is a short and non-extensive list of labels I received in the twelve years of schooling:

  1. Introvert.
  2. Shy.
  3. Complicated.
  4. Pull-through (I was fairly skinny back then).
  5. Trouble maker.
  6. Not a gamer.
  7. A vice captain (amongst sixteen other captains and vice captains).
  8. A very good student.
  9. A geek.

The list is endless and the labels changed every other day based on every single act that I indulged in, the teachers mood, the teachers interaction with his wife the night before and a gazillion other factors which were beyond my comprehension as a teenager.

To put it mildly, I was totally confused about the role of people like me, who had opinions about everything and people who begged to differ on most things, played in an environment which was supposed to be factory for churning out 'responsible citizens' with shinning white uniforms and really short haircuts.

Long story short, I spent years, feeling that there was 'something missing' or more specifically - 'something wrong' with our so-called education system.

Then, school ended.

Of course there were moments to treasure, but basically, I heaved a sigh of relief that it was over and other than keeping in touch with a few friends and having a couple of really bad dreams about exams during my school life, I never made a conscious effort to look back.

Work life for me was a different experience all together. On the very first day at work, I introduced myself with a rather interesting improvised speech and bagged the most interesting introduction prize. From the very first day at work, one message was loud and clear - be a purple cow - and you can actually get rewarded for being different.

A job later, there were tons of realizations I had experienced that I never had during twelve years of schooling:

  1. If you did not feel like reading books, there were tons of podcasts and webcasts you could just watch or listen to, in order to pick things up.
  2. If you did not agree to what your boss was saying, it was ok to interrupt and question him.
  3. If you did not like the idea of going out to a loud party and dancing all night, you could have some serious fun getting together with a bunch of friends and having conversations on technology, life and management.
  4. If you did not like the idea of wearing a tie to office, you could wear jeans and T-Shirts.
  5. If you were late at office, you could work late and still get your work done.

Of all the realizations that I had, here is the most important one: If you did not like things, you were both empowered and free to change them.

Years after school, when I look back to reflect on where my school went utterly wrong and where most organizations that I worked in utterly succeeded at getting the most out of the geek in me, it was all about - making me feel - at home.

What You Need To Know While Working With Geeks.

While schools are busy stereotyping, putting human beings in buckets of categories and labeling them they often tend to miss out of making folks feel 'at home' when they are sitting in a class room listening to a lecture or for that matter, when they are being asked to have 'fun' at school party with loud music.

The thing with the geek within you, is that it likes to live in a nice dark homely cave.

Michael Lopp in his essay on the Nerd Handbook, explains how you can make a nerd venture out of that cave and do something different, like going out on a vacation. He explains how you can get the nerd in you to do new and interesting things:

Map the things he’s bad at to the things he loves. You love to travel, but your nerd would prefer to hide in his cave for hours on end chasing The High. You need to convince him of two things.

First, you need to convince him that you’re going to do your best to recreate his cave in his new surrounding. You’re going to create a quiet, dark place here he can orient himself and figure out which way the water flushes down the toilet. Traveling internationally? Carve out three days somewhere quiet at the beginning of the trip.

Traveling across the US?

How about letting him chill on the bed for a half-day before you drag him out to see the Golden Gate Bridge?

Second, and more importantly, you need to remind him about his insatiable appetite for information. You need to appeal to his deep love of discovering new content and help him understand that there may be no greater content fire hose than waking up in a hotel overlooking the Grand Canal in Venice where you don’t speak a word of Italian.

Today, the once shy geek from high-school interacts with over a hundred people every week, communicates with dozens others. The same shy nerd deeply believes in and nudges other nerds to go out of their way to connect to other human beings.

I enjoy games ranging from ping-pong to ice-skating and the pull-through has been putting on enough weight that he is now thinking of excising to keep his weight under control.

The point here, dear reader, is not to demonstrate how much I have changed over time, but to illustrate how every label that you put on geeks come off, the moment you give the geeks their dark little corner where they feel at home and them allow him to grow from there.

Next time you bump into a geek, and you find yourself attaching labels to the geek, remember, your geek is not shy - he is just not 'at home' yet. Before you label him as shy, introvert, complicated or anything else - try making him feel at home and he just might surprise you.

Something my school never understood, but every organization that employed me, understood rather well.

Something you try spending time to understand as well. Specially If you are a young and budding manager, working with a team of geeks. Go make them feel at home and reap the benefits of having them on your side.

I wish you good luck.

posted on Sunday, January 17, 2010 8:03:17 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, January 16, 2010 by Rajiv Popat

Programmer Tip: Have The Spine To Question Authority (And Your Manager).

Jack has been going around in circles. He is asking me about how I designed that logger in a project that I worked on two years ago. His team is working on a logger and he seems to need some advice. The programmer in me is alive, jumping at the whiteboard and drawing lines with wild vigor explaining the design that was used a couple of years ago and did wonders for us. After listening for sometime Jack breaks the news.

The design I am explaining on the whiteboard is pretty similar to what Jack already had in mind.

But then, there seems to be a problem.

His manager, is going a different route. An approach that Jack knows will not work. Things are bad. The team has already started working using the manager's approach. Jack, is not seeking the programmer in me for help, he is seeking the bullshit buster in me to chime in and talk to his manager. Jack is seeking my help to stop the entire team from moving in the wrong direction.

What started as a discussion around angular brackets of XML has turned into a discussion of confronting the issue and saying 'no' to things that you do not agree to.

My advice to Jack is simple. Instead of talking to his manager, I gently nudge Jack to have that conversation. I nudge Jack to tell his manager that his manager's decision is not correct.

The advice is supposed to have to good effects.

First thing it is supposed to do is help Jack develop a stronger spine and become an individual who is not just capable of having an opinion but standing by it too.

The other really important thing that the advice is supposed to do, is to help Jack's manager from, as Michael Lopp, in his book, Managing Humans, would say, 'Losing it'.  Michael  uses his book to explain:

Losing It.

Managers don’t lose it simply because the pixies showed up with the top hat, they lose it because those they work with forget to look at the back of the hat.

Front: I'm the boss.
Back: ... For now.

Management is a myth, just like the top hat. We, as employees, believe it’s there, so we treat these management types differently. We operate under the assumption that they are the ones who can make decisions.

When the team is stuck on a hard problem, we gather in our manager’s office, present our case, and then the manager nods and says, “Go that way!” More often than not, we’re so happy to be past the hard problem, we don’t even question whether it’s the right decision or not. “He’s got the top hat, so he must be right!”

No no no no. Also? No.

Managers lose it when they are no longer questioned in their decisions. When the team stops questioning authority, the manager slowly starts to believe that his decisions are always good, and while it feels great to be right all the time, it’s statistically impossible.

The most experienced managers in the world make horribly bad decisions all the time. The good ones have learned how to recover from their decisions with dignity, but more importantly, with
help from the team.

Saying no forces an idea to defend itself with facts. It forces a manager under the influence of his top hat to stop and think. Yes, I know that top hat can be intimidating, and yeah, he’s the guy who signs the checks, but each time you allow your manager to charge forward with unchecked blind enthusiasm, you only reinforce his perception that he’s never wrong. That’s a ticket straight to Crazy Town.

If you are a young and budding engineer reading this and if there is one advice I can give you today, it is that you develop a strong spine to constantly ask - why -  and question authority. Even if that means questioning decisions your manager might be taking.

If you believe your manager is taking a wrong decision, go take him for a cup of coffee and ask him to explain his rationale behind his decision.

If his explanations do not make sense, have the spine to say 'no'.

I wrap this post up, dear reader, with an answer to the question Jack asks me when I give him the advice of directly talking to his manager instead of routing it through me. 'What if he feels bad about me questioning him?' - Jack asks.

My answer to the question, dear reader, is a rather simple and direct response- 'That is his problem, not yours'.

What I want you to do dear reader, is look around you. Do you see something wrong? Something that you are doing just because someone higher up in the pecking order or your manager asked you to do it and doing it does not make any sense to you?

Maybe it is time to question authority - not just for your own sake but even for the sake of helping your manager from 'losing it'.

Now give up your mitigated speech and go have that direct discussion that you were so scared to have. Go and gently remind your manager that you think he is taking a wrong decision, and do not stop nudging him gently till either you are convinced he is right or till he changes his decision.

I wish you good luck.

posted on Saturday, January 16, 2010 10:27:15 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, January 15, 2010 by Rajiv Popat

Programmer Tip: Start Re-Investing In Yourself Consistently.

Jack has been on my team for months. Besides being a kickass programmer fresh out of college, Jack is also a gadget freak. From the latest iPhone to the coolest iPod, Jack owns it all.

In a casual discussion on why Jack has not yet bought a domain name or a website yet where he can blog, he responds with a grin on his face, that he is, as he likes to say in situations like these, running seriously low on funds.

I cringe.

Of all the programmers I have worked with, when it comes to spending money, I have come across only two kinds - the kind that sees their career from a passionate entrepreneurial mindset and the kind that does not.

If you fall in the first category, before you grab a fancy-car or a sexy-motor-cycle, a decent part of your paycheck is automatically re-invested towards becoming a better programmer or a better individual. You probably invest in books, own multiple domains, buy tools which improve your productivity as a programmer, enroll for classes or sign up for seminars.

If you fall in the second category, you probably have a dozen excuses on why you do not need to buy your own domain or attend that programming class. If you fall in this category, you are probably also really good at convincing and telling yourself why you need that new car.

A good programmer is difficult to come across. A good programmer, spending time, effort and money to get better at the craft of building software is a rather rare phenomenon. This rare breed, that once walked planet earth and spent their pocket money to play with Altairs because they were passionate about programming these machines, is fast moving towards extinction.

Observe the young and budding programmers you work with and you might easily stumble upon way too programmers who shell out a truck load of money to buy the latest-slick-looking-phone out there, but are totally hesitant while enrolling for a programming class, buying a book on programming or getting their own domain.

Like it or not, programming, dear reader, is a profession which demands that you re-invest a part of what you earn in yourself. If you hesitate in doing so, you are no different than organizations that invest in their buildings much more than they invest in their employees.

Go ahead. This month, buy a few books, enroll in a class, upgrade your internet bandwidth, buy a domain name, try to do a small business venture or just buy a couple of refactoring tools like Resharper and Code-Rush.

Put simply, let this be a month where you begin setting aside some money that you will consciously spend on getting better at the craft of building software and becoming a better individual. Then do it consistently, month after month.

I wish you good luck.

posted on Friday, January 15, 2010 10:36:00 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Sunday, January 10, 2010 by Rajiv Popat

Innovation Tip: Keep Fooling Around Like A Child And Keep Looking For Bird Poop.

Every time I sit down in a meeting where ideas for the next generation of software products are thrown on the whiteboard, I cringe. Something seems fundamentally wrong about the image of a team of nerdy scientists, coming together in a dimly lit meeting room, to conceive and implement ideas which change the world.

Nassim Nicholas Taleb in his thought provoking book, The Black Swan challenges this whole idea and introduces the idea of serendipitous discoveries. He explains:

If you think that the inventions we see around us came from someone sitting in a cubicle and concocting them according to a timetable, think again: almost everything of the moment is the product of serendipity. The term serendipity was coined in a letter by the writer Hugh Walpole, who derived it from a fairy tale, "The Three Princes of Serendip."

These princes "were always making discoveries by accident or sagacity, of things which they were not in quest of."

In other words, you find something you are not looking for and it changes the world, while wondering after its discovery why it "took so long" to arrive at something so obvious. No journalist was present when  the wheel was invented, but I am ready to bet that people did not just embark on the project of inventing the wheel (that main engine of growth) and then complete it according to a timetable. Likewise with most inventions.

Take this dramatic example of a serendipitous discovery. Alexander Fleming was cleaning up his laboratory when he found that pénicillium mold had contaminated one of his old experiments. He thus happened upon the antibacterial properties of penicillin, the reason many of us are alive today (including, as I said (earlier), myself, for typhoid fever is often fatal when untreated).

True, Fleming was looking for "something," but the actual discovery was simply serendipitous. Furthermore, while in hindsight the discovery appears momentous, it took a very long time for health officials to realize the importance of what they had on their hands. Even Fleming lost faith in the idea before it was subsequently revived.

In 1965 two radio astronomists at Bell Labs in New Jersey who were mounting a large antenna were bothered by a background noise, a hiss, like the static that you hear when you have bad reception.

The noise could not be eradicated—even after they cleaned the bird excrement out of the dish, since they were convinced that bird poop was behind the noise. It took a while for them to figure out that what they were hearing was the trace of the birth of the universe, the cosmic background microwave radiation. This discovery revived the big bang theory, a languishing idea that was posited by earlier researchers.

If you think on the lines of Taleb, every innovation in the field of computer science, ranging from the creation of MS-Dos to the building of twitter, does seem like a serendipitous discovery with only one a few things in common:

  1. Their builders were playing around with technology and were involved with projects which were nothing more than what can otherwise be described as 'fun projects' when, as a matter of chance, they bumped into something which was capable of taking a life of its own.
  2. They were not afraid to fail - as a matter of fact, they failed multiple times before the serendipitous innovation which set them apart from the other mere mortals that walk planet earth.
  3. When they bumped into a serendipitous discovery and saw what they had bumped into, they worked hard for years to turn it into a concrete implementation with a real existence. 

The next time you find yourself in a meeting where new ideas for changing the world of software development or redefining how people do business are being thrown on a whiteboard, remember this - the harder you try to desperately innovate ideas in a meeting room, the crappier your ideas will be.

Maybe you should just cancel the meeting and go for a walk. Maybe you should just get back to working on that side project and have fun like a child. Keep your eyes open and be on constant lookout for serendipitous discoveries that take a life of their own. Keep jabbing, keep opening your IDE, and always be on the lookout for bird-poop. When you find the idea worth chasing, work hard - consistently. Rest of it should just workout over time.

I wish you good luck.

posted on Sunday, January 10, 2010 11:31:27 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Saturday, January 9, 2010 by Rajiv Popat

Leadership Tip: Stick To Your Core Values And Pass Them On Across Teams.

You have hand-picked every single member in your team. Every single one of them is a fully competent one man army. When you ask them to do something, things get done.

Your organization is growing faster than you think. There is more work around than your team can possibly complete in years. You tell yourself that you need more people. More small teams like this one.

You scale up.

You hire more kickass programmers.

It is time. You ask your team members to step up, grow and lead their very own teams.

You continue working with your current team. Each of them now has their very own team which in turn is running a module or an entire project. All of these teams are highly effective and getting their job done.

You now have what they call - an organizational structure of self sustaining teams - in the management world.

Collectively, these teams are getting more done than you ever thought was possible.

You are living in a paradise.

Now unless you are seriously lucky, chances are, that you are going to snap out of your dream really fast.

It will happen when a young recruit you placed in one of these teams last year is going to walk up to you one fine morning and say in very clear words that his team culture is nowhere close to the culture you wanted to promote in your team. He might, for example, tell you that he is being micro-managed, bossed around or being pressured to work late three days a week.

It will hit you. Really hard. The realization that some of the core values that you worked really hard to push in your team may not be flowing through to rest of the organizational structure under it.

Jack is a very effective programmer. During his course of working with you, you developed strong respect for his talents and a strong friendship with him. You wanted to help him grow and hence the decision of letting him manage his own team. Now you have a young and budding engineer working under Jack telling you loud and clear that Jack, is not a very good manager or for that matter a very good leader.

Accepting that, dear reader, is going to be a painful reconciliation.

Confronting the issue and doing something about it is going to be even more painful. Your mind will trick you into telling yourself amazing stories in favor of Jack - Maybe his team members are bitching unnecessarily. Maybe he needs more time. His team is effective; maybe it is just the fact that his management style is different. His team is effective - he is getting things done - his team members will eventually get used to his working style.

Put simply, you can either confront the issue or tell yourself stories to avoid it.

What you are doing, dear reader is, making a choice. A choice between whether your organization will live by its core values that got it so far or it will grow big and lose its soul.

Go ahead, cut through to the bone. Confront the issue. Look at Jack in the eye and ask him to make a choice between passing on the core values, happiness and freedom that he receives from you, over to his team or stepping down and letting someone else lead.

That, dear reader, is your own chances at letting your organization retain the magical touch of being small as it grows and letting it retain its soul.

I wish you good luck.

posted on Saturday, January 9, 2010 10:06:27 PM UTC by Rajiv Popat  #    Comments [2]