free html hit counter
Posted on: Wednesday, February 18, 2009 by Rajiv Popat

No-One Cares About You, Your Blog Or Your Product.

Have you ever seen any young and budding blogger, who for the purposes of this post, we shall refer to as Fred, start on his 185th blog? He is as excited as a little baby who has been given a brand new toy which he thinks will allow him to change the world.

He spends hours thinking of a name for his 185th blog; gives special attention at picking the theme and spends hours doing a spanking new absolutely cool-and-happening-web-2-0-CSS-based design for the blog. Then he starts with a first post which he believes will make all his readers fall in love with his writing and make them crave for more.

This time he is firm and decided. This time he is going to write a blog which not just makes him famous but will change the world for good.  There is only one little problem however.

The 'world' that our dear blogger wants to change doesn't give a rat's ass about him.

The millions of readers who were going to love and hang on to every little word that he writes, happen to be just a little busy, doing their job, providing for their family and sometimes, even a little irritated doing chores, managing their spam mail and hanging up random marketing calls made by call centers who specialize in the act of calling individuals when they are least in the mood of accepting random unsolicited calls.

These millions of readers, as it turns out, are so darn irritated that they are not interested in buying anything; not even if it is just ideas; for which the only price to pay is just five minutes of their time daily time.

Long story shot, these millions of users, our dear blogger wants flocking on his blog, don't care; and the ones who care enough to read and listen have, most probably, found the mavens they want to listen to; and have already started trusting them for their transactive memory.

Our dear Fred, continues to blog for a month; during that one month he blogs once; twice; and then thrice, only to realize that he is talking to himself. The comment count is constantly zero. His web-site statistics aren't crossing the three 'returning visitor' count.

Google just doesn't seem to be crawling his website, no-one seems to be linking to him and Feed-burner statistics hardly seems to cross a count of five RSS subscribers, two of which are his own subscriptions; one from office; another from home.

By the third post, the enthusiasm to change the world has started stammering. Our dear blogger has swallowed his pride; but he is not done yet; after all he is not one of those who will give up. He will start again; with yet another fresh start; yet another blog, that will, one day, change the world and get him the million readers he seeks so desperately.

I cite the blogging example here because blog posts have very short release cycles. It is usually less than a couple of days from the moment the author conceptualizes the idea to the moment he publishes or releases it to the world.

Much like programming, the bar of entry for young and budding bloggers is low. In fact it's even lower than programming. Much like programmers, anyone can be a blogger; all you need to do is sign-up at a blog-spot or a word-press. Truly, blogging seems to be representative of every other thing that we usually do in the world of software development; only difference being that it's usually individual and can see a blog post's life cycle in less than a couple of days.

These characteristics makes blogging makes, observing why blogs fail, an excellent 'sampling tool' to investigate where people usually go wrong when it comes to marketing their products and ultimately their 'ideas'.

As programmers we tend to believe that if no-one is using our system or reading our blog, there 'has to be' something wrong with the technicalities and specifics of the blog. Maybe it's name isn't hip and happening enough. Maybe it's user interface is not being catchy enough. Maybe the underlying blogging framework is not being fancy enough. Long story short, we tend to believe that there are 'technical issues' which are causing our readers to not like our blog.

The same is usually true for products and systems that we build.

As developers, we are also great at bulldozing everything that we don't think is perfect starting fresh; again and again. That is what leads us to iterate the infinite loop of failure. We tend to; or should we say, 'like to' believe that if we abandon the current effort and move on to a fresh start, everything will mysteriously work out.

Anyone who has looked at the number of dead projects in source-forge, number of abandoned blogs on blogger and word-press and number of startups in f@#ked-company, before f@#ked company was itself f@#ked, knows what I am talking about here.

As Bloggers, software developers and even marketers we like to think that if we 'build' something or write about something, that we believe is great or cool, people will usually care about it as much as we do. The simple, hard and blatant fact of life is that, like experts, most human beings are creatures who work on incentives and unless you give your users or your readers, depending on what you are doing, a strong enough incentive to care, they will simply ignore you.

Why? Because it's easy for them to ignore you. They have options.

Bloggers and Software Developers taken over by the desire to save the world and save their readers or customers, forget the simple fact of life Seth Godin reiterates again and again in countless of his videos and presentations like this one. He explains:

This is so important, right, ready?

No-One Cares About You.

They invented television to sell ads to you. They invented radio to sell ads to you. They invented news paper to sell ads to you.

That's not why they invented YouTube, That's now why they invented the internet. The internet doesn't care about you.

People don't "have to" watch channel seven any more. They can entertain themselves mindlessly for hours by pressing the stumble upon button.

So if someone is going to watch a video; they are not going to watch it because they care about you. They are going to watch it because they care about "me" (them).

Me-Me-Me-Me-Me - my favorite person - Me. They are not going to read e-mail from you; they are going to read me-mail; because that's who they care about.

So if you make a video like the Blend-tec guy, the Will-it-blend videos, people will watch it because watching Chuck Norris blend in a blender is sort of a hoot but if you make a video of how your factory is twelve percent more efficient than it was last year... (yawn)... I'm not coming.   

No one cares about you; they don't care about what you had for lunch; your cat; or your favorite color; unless of-course you can talk about these things in a way that makes them roll over laughing; keeps them hooked; helps them take better care of their cats; or helps them cook their lunch better; if you can't do that, your cat, your lunch and your favorite color doesn't mean zip in the larger scheme of things.

No-one; I repeat; No-one; not a single human being; unless that human being happens to family or a loved one; cares about you, your latest blog post or the system on which you are spending your weekends. All they care about is, their favorite person; themselves.

This is supposed to be common knowledge in the world of marketing and even software development and yet I see individuals jump from one blog to another, organizations jump from one product to another and programmers jump from one open source project to another; in hope that a 'fresh start' will make their users care.

Whether you write a blog or do a project, what you are ultimately interested in doing is getting people excited about your thoughts or ideas. You are interested in sharing them with people who happen to be busy and in general, don't give a rat's ass about you or your ideas.

The only way of grabbing their attention and getting them to even remotely care about what you want to say, is by putting yourself in their shoes; and thinking about the value your work is giving them. Is it entertaining them; Motivating them; Inspiring them;  Educating them; or simply irritating them.

Adding genuine value through your work and getting people to genuinely care takes time. It requires constantly proving yourself with actions; not words. It takes time to prove that you are serious about delivering whatever it is that you want them to consume; and that you will not just deliver high quality; but that you go out of your way and will deliver constantly.

Gmail took more than three years of persuasion; friend-feed took even longer; Most authors writing inspirational posts on success tend to not even talk about the countless other applications and startups that might have died a painful death along the way. 'Overnight success' in any form usually takes a long time.

Depending on what you are trying to do it might take years. This post isn't supposed to be a motivational post which tries to come out and pamper you; pats you on your back and assumes a if-you-keep-trying-you-will-succeed tone; because we all know you may not succeed; and that, dear reader, is the whole point of this post.

Unless you yourself, are willing to stick to at-least one thing, in spite of your failures; continue to deliver; go beyond shipping; and continue that for months, without expecting any overnight success in return, expecting your users or readers to take you seriously or care about what you have to say is nothing more than stupidity.

Expecting them to believe that you feel passionately about what-ever-it-is-that-you-want-to-say-or-are-working-on, because you said so in a blog post or two or because you rolled out the first sprint of a product, is nothing more than a joke.  

So the next time you sign up for a blog, first remind yourself of this simple little fact of life: no-one cares about you; not even your very own users.

Then ask yourself if you have something interesting to say that your users will really care about. Besides asking yourself why 'you' want to write that  blog post. Ask yourself why they should care to read it. Ask your self this question; constantly as you edit and re-edit your post. Then, ask yourself this question before you publish it live.

Think of the internet as a large room of millions of on-going parallel conversations; people are fairly open to letting your participate and contribute; the rules are simple:

  1. You have to have something to say that adds genuine value to the community.
  2. You have to say it with conviction.
  3. You have to care enough about the idea(s) or whatever it is that you are working on, to keep doing it; even if no-one is listening.

Step one, is highly under-rated and most people in the world of software development know it, but unfortunately, do not seem to 'get it'; which is why we have depressing blogs which talk about how-depressed-Fred-was-feeling-this-morning; personal-life-blog with Fred shouting at the top of his voice about how passionately feels about cats and his pet-cat in particular.

As you browse through countless personal blogs, be prepared to be amazed by how the The 'passionate interest' in cats, for Fred, usually ends in just about two posts, after which Fred decides to just stop talking, goes silent and disappears.

Huh! Wonder what happens to all that 'passion' on cats; you wonder.

Then months later Fred moves to a new blog with a new topic he feels passionately about.

If you want to talk about Cats, be a Cat maven and provide useful information on cats. If you want to talk about your depression, provide a wealth of information on how you fight your depression. If you think it's hard, take a look at Scott Hanselman, getting you involved in his fight against diabetes. There are countless other great examples out there.

Oh and by the way, changing your blog URL, adding a new theme, changing your project name or constantly changing your jobs does not result in a 'fresh start' that will magically change your life Hollywood style and make 'them' care about you.

Unless you have something concrete which you can offer to the world; and unless you can offer it consistently; I am here to tell you dear reader, the world does not care about you. Unless you can get them to give a shit by giving them enough value and genuine incentives to, you, your blog and your dream project are all doomed to be ignored like unsolicited marketing calls.

If you find that unfair; go grab a copy of Atlas Shrugged; and read it ten times over.

Technology of your hosting provider, bad CSS, your blogging framework and not having the bells-and-whittles is not your problem. Lack of features in that open source project that you might be working on, is also not your problem.

Having a cause, a message and then getting people to care about your cause, message or whatever it is that you have to say is.

Unless you can do that, you, your systems and your blogs are no better than spam mail that lands in our inbox every morning.

Now, stop signing up for that new blog or gathering email addresses for your next press release mail blast.

Go build your own tribes instead. I wish you good luck.

posted on Wednesday, February 18, 2009 7:53:34 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Wednesday, February 11, 2009 by Rajiv Popat

Building A Better 'Transactive Memory' - Relying On Mavens Vs. Going By Expert Opinions.

When you are in the business of building software; information, knowledge and wisdom that you carry in your own your head is not the only measure of how successful you are.

With software development it is in fact, the knowledge and wisdom that you have 'access to' that matters much more than how much of it you carry with you in your own head.

Malcolm Gladwell In his book, 'The Tipping Point', explains this concept when he talks about 'Transactive Memory'. He explains:

This is what University of Virginia psychologist Daniel Wegner calls "transactive memory."  When we talk about memory, we aren't just talking about ideas and impressions and facts stored inside our heads. An awful lot of what we remember is actually stored outside our brains. Most of us deliberately don't memorize most of the phone numbers we need. But we do memorize where to find them — in a phone book, or in our personal Rolodex. Or we memorize the number 411, so we can call directory assistance. Nor do most of us know, say, the capital of Paraguay or some other obscure country. Why bother? It's an awful lot easier to buy an atlas and store that kind of information there. Perhaps most important, though, we store information with other people.   

The idea of 'Transactive Memory' is relevant pretty much in all spheres of personal life and work life; including your online time. When it comes to the world of software development, even though a huge number of us may not be open to the idea of contributing on the internet; we use 'Transactive Memory' all the time; while we are looking for information; and particularly when we are going to make decisions based on that information. Ever read a blog to find out what someone thought about a tool or application you were planning on buying? Ever went through Amazon user-reviews before buying that book?

Using transactive memory is exactly what you were indulging in when you were doing all of these or multiple other activities that you do online when you look for information and in particular when you use that information for making purchase decisions; online. You were depending on individuals who you did not even know personally and you were trusting them to provide you with accurate information.

When you are buying a thirty dollar book at Amazon it's easy. However,  when a part of your job includes picking tools and technologies for your organizations and most projects that are implemented in your organization, developing strong 'Transactive Memory' using sources of information you can trust becomes much more important.

As someone who is involved with making technology decisions for multiple development projects for years; I've had my share of successes and failures at picking products and frameworks to be used in projects. I've also learnt some lessons along the way quite a few of which are about building a better 'Transactive Memory'. This post is about one of those lessons.

At Multiplitaxion Inc, for example, during my early years, a client approached us with the need of having a customized user portal done. Someone high up in the pecking order at the client organization had a friend, who turned out to be the SharePoint expert.

This gentleman with his expertise in SharePoint was expected to lead the project; if it materialized. When the client approached us, the decision to use SharePoint was something they has 'defaulted to'. This decision of course, was based on 'expert advice' and they believed, in all sincerity, that it was a correct decision taken under the guidance of a true expert.

For days we struggled back and forth; trying to do a 'proof of concept' with SharePoint; the SharePoint expert helping us out every time we were up against a road-block. This guy, was amazing with band-aids, workaround, tips and tricks up. He always seemed to have some cards up his sleeves; especially every time we were going to hit a wall.

This was the early SharePoint version where if you were going to do custom development, you were pretty much stuck with writing .NET-Custom-Controls and all SharePoint did was act as a liability slowing you down in development instead of being this amazing portal framework that the Microsoft marketing folks were busy portraying it to be.

This gentleman, however, wasn't discouraged. To be fair to him; he was good; in fact he was great. He could do things with SharePoint lists that none of us thought made any sense to even attempt and he would get away with it; producing a new magic trick every time a road-block was showed up.

After a few weeks of prototyping, band-aiding and this expert of ours pulling magic tricks out of the his expert head, we decided to quit.

'Freakonomics'  by Steven D. Levitt and Stephen J. Dubner co-incidentally of-course, describes what had gone wrong with us trying to implement SharePoint in that project. We, the allied relationship of the client and us, had relied on an expert, when the best interest of the expert was not aligned with our best interest. Both the client and development team wanted a simple maintainable ASP.NET web application; this expert on the other hand needed consultancy and dependence on him.

In their book Freakonomics; Steven And Stephen provide excellent explanations on what is wrong with working under the assumption that an expert will always provide you the accurate information and work for your best interest if you pay them. In the book, Steven And Stephen describe an experiment conducted to find out if experts always work for the best interest of their clients:

Experts are human, and humans respond to incentives. How any given expert treats you, therefore, will depend on how that expert’s incentives are set up. Sometimes his incentives may work in your favor. For instance: a study of California auto mechanics found they often passed up a small repair bill by letting failing cars pass emissions inspections—the reason being that lenient mechanics are rewarded with repeat business. But in a different case, an expert’s incentives may work against you. In a medical study, it turned out that obstetricians in areas with declining birth rates are much more likely to perform cesarean-section deliveries than obstetricians in growing areas—suggesting that, when business is  tough, doctors try to ring up more expensive procedures.

It is one thing to muse about experts’ abusing their position and another to prove it. The best way to do so would be to measure how an expert treats you versus how he performs the same service for himself. Unfortunately a surgeon doesn’t  operate on himself. Nor is his medical file a matter of public record; neither is an auto mechanic’s repair log for his own car.

Real-estate sales, however, are a matter of public record. And real-estate agents often do sell their own homes. A recent set of data covering the sale of nearly 100,000 houses in suburban Chicago shows that more than 3,000 of those houses were owned by the agents themselves.   

The experiment involved measuring data and coming to a conclusion which describes why relying on experts may not always be the best way to gather information. Steven And Stephen explain:

There’s one way to find out: measure the difference between the sales data for houses that belong to real-estate agents themselves and the houses they sold on behalf of clients. Using the data from the sales of those 100,000 Chicago homes, and controlling for any number of variables—location, age and quality of the
house, aesthetics, and so on—it turns out that a real-estate agent keeps her own home on the market an average of ten days longer and sells it for an extra 3-plus percent, or $10,000 on a $300,000 house. When she sells her own house, an agent holds out for the best offer; when she sells yours, she pushes you to take the first decent offer that comes along. Like  a stockbroker churning commissions, she wants to make deals and make them fast. Why not? Her share of a better offer - $150 - is too puny an incentive to encourage her to do otherwise.   

In the world of software development, especially when you are responsible for picking tools, technologies, directions, trends to follow etc. for your organization and even for your own career, knowing three simple facts is important.

  1. You'll never be able to know or find out everything and keep it in your own head. You will have to use Transactive Memory and depend on 'experts' rather frequently.
  2. When you are building POCs, every tool out there meets your requirements; especially when you have an 'expert' who is convinced it does.
  3. When your best interest doesn't align with the best interest of the experts you are relying on; experts will cheat; most of the times they will do so unknowingly and subconsciously.

If there is one thing I've learnt, in my career as a software development it is this; don't depend individuals who are 'just' experts. If you must depend on someone for the choice of the tool, platform, technology, framework or information in general, depend on individuals who besides being decently good at what they do; are also individuals who can otherwise be defined as Mavens.

Malcolm Gladwell describes these individuals in his book, The Tipping point when talking about Mavens, Connectors And Salesmen. He explains:

The word Maven comes from the Yiddish, and it means one who accumulates knowledge. In recent years, economists have spent a great deal of time studying Mavens, for the obvious reason that if marketplaces depend on information, the people with the most information must be the most important.   

Malcolm in 'The Tipping Point', while talking about one of the Mavens, further describes how these individuals, end up helping others by simply being themselves and indulging in their own nature of gathering, processing and sharing information:

At one point Alpert launched into a complicated story of how to make the best use of coupons in renting videos at Blockbuster. Then he stopped himself, as if he realized what he was saying, and burst out laughing. "Look, you can save a whole dollar! In a year's time I could probably save enough for a whole bottle of wine."

Alpert is almost pathologically helpful. He can't help himself. "A Maven is someone who wants to solve other people's problems, generally by solving his own," Alpert said, which is true, although what I suspect is that the opposite is also true, that a Maven is someone who solves his own problems - his own emotional needs - by solving other people's problems. Alpert is not, it should be said, an obnoxious know-it-all.

It's easy to see how he could be, of course. Even Alpert is aware of that. "I was standing next to a kid in the supermarket who had to show his I.D. to buy cigarettes," Alpert told me. "I was very tempted to tell him I was diagnosed with lung cancer. In a way, that desire to be of service and influence — whatever it is — can be taken too far. You can become nosy. I try to be a very passive Maven... You have to remember that it's their decision. It's their life."

What saves him is that you never get the sense that he's showing off. There's something automatic, reflexive, about his level of involvement in the marketplace. It's not an act.

Anyone who has seen Life-Hacker, Scott Hanselman's Tool List, Scott Guthrie's direct and straight forward elaborate posts on technology Microsoft is working on or seen Rory criticize Microsoft when they make lousy mistakes, while retaining his full time job at Microsoft, knows what Maven-ship is; of course there are countless other examples of true and genuine maven-ship out there.

If you look hard enough for Mavens who are genuinely trying to help by collecting, processing and then distributing accurate, honest and true information; you will find them. Another way to spot them, is that unlike experts, who primarily work on information and see all information that benefits them as 'good', Mavens have an ability to form strong personal opinions about information they gather.

Pick a few Mavens; follow them through their blogs or website for a few months; see if your opinions align. Scrutinize their posts. Are they are making the right judgment calls that work for you most of the time? If your answer is yes for a particular Maven, you can use his knowledge or effort and make it a part of your own 'Transactive Memory'.

Months ago, for example, when I was asked to go looking for a static analysis tool to suggest at work, the nDepend official website was not the source of information I wanted to base my judgment on; I had tried the product and was happy but with; but when a third person who I know to be an honest maven talks about it and helps me get started on it, that is often the personal tipping point for me; something that results in a buy. 

Coderush is another example where multiple Mavens have got me introduced to the product without any hidden interest or incentive; ultimately resulting in me recommending the buy and a license getting purchased.

The list is endless but what is common in the list is that I would say I've never been disappointed with any of my purchase, downloads, recommendation-to-my-organization or recommendations-to-a-client; when the information used for the recommendation, purchase or download was from a genuine Maven I already trust. That, for me at-least, speaks highly of the power of 'Transactive Memory' used correctly. On the other hand, any software purchase or download that I've done based on an 'expert opinion' has turned out to be a lousy decision more than once.

You can take an expert opinion;  but the opinion would be correct only as long as the interests of the expert who is giving you the opinion align with your interests. When given the choice between the Maven and an expert; especially when you are picking sources for your 'Transitive Memory'; irrespective of how talented or awesome the experts you have access to are; don't depend on them.

Look for the quality of maven-ship in people instead. Depend on people who demonstrate that quality and then form your own pragmatic opinions based on theirs. I wish you good luck.

posted on Wednesday, February 11, 2009 4:29:02 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, February 6, 2009 by Rajiv Popat

Insecurity - Use It Till You Lose It. The Art Of Staying Dangerously Close To Getting Fired.

If your manager behaves like an angry tiger; chances are that he is putting up a mask; behind which, lives a timidly scared and insecure individual.

Scott Berkun describes this type of insecurity as one of the ten primary reasons why Project Managers And Development Leads become assholes. He explains why managers often act like assholes:

They are insecure in their role. The psychology of opposites goes a long way in understanding human nature. Overly aggressive people are often quite scared, and their aggression is a pre-emptive attack driven by fear: they attack first because they believe an attack from you is inevitable. Management makes many people nervous since it’s defined by having have less direct control, but more broad influence. A huge percentage of managers never get over this, and micromanage: a clear sign of insecurity and confusion over their role and yours.   

Insecurities manifest themselves in multiple forms but the most serious form I have witnessed till date is the fear of becoming redundant. Most managers who are not from development, programming backgrounds and are managing projects are walking, talking, breathing examples of this form of insecurity.

Even technical managers are not immune to this insecurity.

In fact, to be honest, chances of you having this insecurity exist, even if you are the best developer in your organization.

The act of having written all that code for that critical module in that critical project, for instance, gives us programmers, what can be called, a 'perceived' sense of security. We love the warm and fuzzy feeling of our 'organizations' needing us for a a very long time in the future as much as we hate and fear the feeling of not being needed.

If you are working with a team your first responsibility as a manager; is to lose this sense of insecurity.

Now, that's easier said than done.

As it turns out, this insecurity is not 'that ring' which you can just lose in the sink. The fundamental problem of transitioning to leadership role is that this insecurity, in most cases, has a tendency to multiply rather than getting reduced; especially as you move up the pecking order.

Michael Lopp, in his post, describes this tendency of managers getting sensations of insecurity, rather articulately. He explains:

This sensation will appear at the end of the day when you ask, “What did I build today?” The answer will be a troubling, “Nothing”. The days of fixing ten bugs before noon are gone. You’re no longer going to spend the bus ride home working on code; you’re going to be thinking hard about how to say something important to someone who doesn’t want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting… something.   

It is this sensation of building 'nothing' day after day that makes most managers feel insecure and take their first steps on the path to prickdom. This fear of their team or their organization finding out how easily replaceable they are, is exactly what makes them forget their 'not to do' list and makes them do too much. Most managers jump from creating Gantt charts, to organizing meetings knowing deep down inside that none of these activities do not add any value what-so-ever and yet continuing to sound detail oriented and in charge; instead of just getting out of the way and letting their teams drive.

Having said that however, turns out, depending on what you do with this insecurity, which is usually supposed to get you started on your path to prickdom, matters. This same insecurity that gets you started on your path to prickdom, can help you become a kickass manager, if channeled in the right direction. Used correctly and generously this fear or insecurity can transform you and take you to the next level of genuine competency. It is like taking the devil along with the angel when you head out to war against prickdom.

Used wisely, what this insecurity allows you to do is 'scale up'.

Don't knit your brows.

I'm not asking you to 'scale up' like the VP of sales and marketing expects your development team to scale-up-and-do-more-with-less; that's not what I mean. I'm not talking Managementese here.

The fluff aside, scaling up is one thing that needs to be one of the primary things you focus on in your career profile.  Michael talks about the art of scaling up using a writing style that is not just fun to read, but rather motivating . He explains:

As a new manager, whenever the sky falls, you’ll become an engineer again. You’re going to fall back on the familiar because those are the tools you know and trust, but it’s time to trust someone else: your team.

If I could give you one word, a single, brief piece of management advice, the word would be “scale”. Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing.

It’s time to translate and to teach what you’re good at to those who you work with, and that starts by trusting them to do that which you previously only asked of yourself.

The benefits of defining and maintain this trust create a satisfying productivity feedback loop. By trusting your team, you get to scale, and scaling means you hopefully get to do more of what you love. The more you do, the more you build, the more experience you gather, the more lessons you learn. The more lessons you learn, the more you understand, and that means when more shows up you’ll have even greater opportunity to scale.   

Put simply, to me scaling up means that you try to make yourself completely replaceable. You work hard to make yourself a primary candidate who can be fired without any dependency or hassle; because his team knows what they have to do and can continue to do it; even if you are not around or decide to quit. It's like building self sustaining eco systems in fish tanks. Continuously.

I'm not talking about traditional succession planning here. I'm talking about enabling your team to do everything you are doing and encouraging them to do it better; even while you are around. Make them replace you so that you are no longer a critical part to the success of the project.

Yes, that makes you primary candidate for being fired; but if it actually does gets you fired; you didn't deserve your job anyway; or maybe your organization didn't deserve you; either ways; it is best for you to move on.

My first lessons at scaling up came in when a young and budding developer at a client office, working for them, approached me asked me if I could explain the security piece that I was leading. Here's how it happened; he was free, had nothing to do and wanted to contribute. I was way too busy and way too insecure to let go ownership. I politely dodged his question with a - sure-maybe-some-other-time-when-I-am-free answer. As a matter of fact, My being busy wasn't a problem; my being insecure, was.

I'm not sure why I did that, but the very next day, I randomly walked over to his cabin and I think I spent over five hours taking him through the entire module, showing him how to debug the module and running him through the entire implementation. Then I spent a couple of hours showing him where my code sucked and asked him to see if he can come up with better ideas. It was the very next day something creepy; almost Hollywood style, happened. I lost my insecurity - just like that ring aught to have been lost; and most importantly, it was fun. 

Three weeks later this young and budding developer of ours was leading the security module. I moved on to code-reviews; working on the nastiest performance fixes and challenges which were so insane I loved working on them.

Early on in my career, it was divine coincidence, that made me stumble upon my first experience of 'scaling up' by making myself completely replaceable and then working my ass off to take up an even bigger and better challenge. It was like a tame lion, tasting his first few drops of blood. The rest as they say is history. Today, one of my measures of success if I am supposed to be managing it is - how easily will the project continue to run if I were to quit for good without any replacements.

Once this level of temporary uselessness is achieved; I love flaunting it, talking about it rather shamelessly and finding something much more challenging to do.

May I suggest dear reader that you do some serious soul searching on if you have insecurities about your colleagues beating you in the race of getting to the top? If you even heard the mildest whispers of the word 'yes' while asking that question; may suggest you act now and start on your journey to overcome these insecurities. Multiple techniques exist:

  1. Pick what you learnt last week and conduct a knowledge sharing session. You insecurity of having no competitive edge will make you learn more in a desperate attempt to stay ahead in the stupid rat race; then conduct another session again after you've learnt something new. Keep doing this till you no longer feel insecure; and if possible continue doing it even after that; just for the fun of doing it
  2. Take the module you own; explain it to someone and then hand it over. Help the other person when needed; but don't code on it. You insecurity of having nothing to do and not being very needed in your organization will make you probe into other productive areas; then teach those to someone else and hand them over as well. Once you've manage you use and lose all your insecurity; continue doing it anyway.

Long story short; use your insecurity till you lose it. Learn the art of making yourself completely replaceable and dangerously close to getting fired each year; and then, if you still don't end up getting fired year after year, you'll know you're growing. I wish you good luck.

posted on Friday, February 6, 2009 9:37:56 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, February 3, 2009 by Rajiv Popat

You're Not A 'Detail Oriented' Manager. You're Just A Prick.

Every once in a while as I talk to developers around the world it is not uncommon for me come across developers who feel they are under a constant watch.


Managers on the other hand do not hesitate to consider this an integral part of their job and label this as their being 'detail oriented'.

One of the young and budding project managers, that I worked with at Multiplitaxion Inc, who for the purposes of this post, we shall refer to as Fred, described his daily activities to me in an informal conversation. Based on my recollections of the past I may not be quoting this person word-by-word but I do keep the spirit of what he was trying to say one-hundred percent intact. Here is Fred, describing his daily routine.

I start my day by looking at the bug tracking system to see how many bugs are out there in the bug tracking system and what are the pending items in the task list. Then I talk with my development team during the afternoon and check how many they would be able to close for the day. With that done, I check with my QA team how many items they will be able to close in a day. I spend afternoons assigning tasks and bugs to individuals; both in the development and the QA team. During the evening I check up the list again about how many items were actually closed and follow up with the teams if there is a variance in what was expected and what was done.   

I say this at the risk of sounding like a jerk, but the mere act of hearing this individual describe his day was both humorous and pathetically tragic. Here was an individual working hard to destroy his career and turn himself into data entry operator for the bug tracking system and a watchdog merged into one when he thought he was 'managing' the project.

As we spoke I could literally picture a what-would-you-say-you-do-here discussion from office space; and yet; this individual found it his responsibility to be in control and in charge of every single bug that was there in his project.

The desire of being in control was in fact so intense that he took it upon himself to get every single cosmetic bug in the project closed. He didn't close them himself though; he got the developers to do it while he maintained timelines and checked-up on his team to see what the status of the bugs was; regularly; often even twice a day.

Another manager I happened to witness, was notoriously famous for calling up people during the weekend and asking them to come down to office every time she discovered a bug while he was testing the build herself during the weekend. QA was called and questioned on why the bug wasn't detected. The individual actually did consider himself very detailed-and-organized. Everyone else of-course, considered him a notorious asshole.

These are but just two examples. Look around you and you'll find many others. The act of getting into too many details about your project sends a subtle signal  to you team. It tells them that you, do not trust them to take the correct decisions and get things done. It de-motivates kick-ass performers to an extent most 'detail oriented' managers cannot even begin to imagine. Cube Queen for example, expresses her frustration with her managers desire to indulge in every little minutia of her job:

This week in our fabulously fun staff meeting, I made sure that I talked for at least 15 minutes. That’s 14 minutes longer than I usually participate. My colleague and I were testing out a theory. She thought the reason behind our leader’s strange behavior towards me — ignoring and discounting me, pretending like I’m not standing right in front of her so she doesn’t have to say good morning to me — was the result of my lack of communication during staff meetings.

So today, I blabbed on and on about the boring nitty gritty details of everything I worked on, including phone conversations I’ve had within the last week. Sure enough, directly after the meeting I got a, “Great job at staff, boy you’re really busy.” Right on cue!

Don’t ever forget and don’t ever underestimate the power of minutia with leaders who have small brains. And that would be about 90% of them! If you work for a short-sighted, incompetent idiot who is incapable of strategy development and only focused on the tactics that it takes to get a project done, you must — I mean must — live in those details and broadcast them proudly. Even if it’s against your nature.

Yes, this is also in line with kissing A**, which I don’t like to promote, but in this case it’s a necessity! The incompetent leader lives for that crap. There’s also a bit of narcissism here. The incompetent boss looks for lame things like staff meetings for his/her underlings to express their subordinate positions. Meaning, bow to the king or queen. This personality gets off on the power that comes with “this is my staff meeting and these are my servants reporting. Bow to me!” So bow!

I want you to try something tomorrow. When you see your incompetent boss or senior leader in the hallway, stop and tell them about that great process you just finished, or the phone calls you had to get the project done. Live in minutia!   

If you are a manager does it sound like cube queen is being unfair and overly critical? At the end of the day, all the poor-little-manager is expecting from his team is that they brief him with details of the work they are doing. Yes, he gives attention to details and wants to get things done the first time. Is that such a bad thing?  Dave Taylor tactfully uses sarcasm to answer this same question by turning the tables on a potential micro-manager:

Question Asked:

I just had someone tell me I'm a "micromanager", but I have no idea what this really means. Yeah, I have a high attention to detail and I like to have things done right the first time, but why is this a negative?

Dave's Answer:

Well, when you submitted this question, you shouldn't have used the word "Yeah" in your question, and you originally had single quotes around "micromanager", but I fixed that, and, well, your grammar isn't quite what it could be.

Oh? You just wanted me to answer your question? Not tell you how to ask your question in the first place? Now you're starting to see the difference between interacting with people and trying to manage their every breath, to control rather than manage, to project the message "you're incompetent and I just don't trust you to do even the simplest thing correctly."

That's what a micromanager is: someone who manages at a level far lower, far more detailed than is necessary or appropriate.    

The next time you feel the need to 'drill down' into more details when you team gives you a status; consider if the drilling down is really necessary or it is just your egoistic itch that you simply feel like satisfying. Ask yourself if you just 'have to' know and understand every moving part in that CRUD form your team worked. Question yourself on why you 'must' know who introduced that bug.

Hire smart teams of  kickass developers who have great chemistry. Get them on a project, be there if they need something, get out of their way and let them manage themselves.  After all, you were hired to help your team so that nobody comes in their way to success; and that includes you too.

If you developers are excited about what they are doing and they genuinely respect you they won't stop talking about their project and what they are working on. If they are not excited, find out why they're not and get them excited. Have informal conversations, and fun filled stand up scrums; not never-ending status meetings.  For anything else that you want to know, use the right tools.

Check-ins and your version control system can give you as much details about the project as you want; a daily build provides you with all the status you might be interested in. If you need more details, teach yourself how to write code, grab the latest copy of your team's codebase, read and help them if you genuinely can.  If possible, be an active member and own a task yourself. What ever you do; don't bother them with lengthy meetings, full of stupid questions which make you sound like you lack trust. Don't indulge in random policing  under the name of being 'detail oriented'.

If you cannot 'sense' the health of your project and have to constantly peck on people and drill deep into irrelevant details to figure out how healthy your project is; you might not be the 'detail oriented manager' that you think you are after-all; You might, in fact, be a micro-manager or yet another classical prick; and you may not even know it.

posted on Tuesday, February 3, 2009 9:12:12 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, January 30, 2009 by Rajiv Popat

Reducing The Number Of Clicks Is Highly Overrated.

The phenomenon of clicking, since the mouse was invented and demoed for the first time was supposed to make computers easy. Today when I watch computer users surfing the web it is not uncommon to come across users who are 'thinking' with their hand on the mouse. Thinking about what to click next.


This post is that 'click'.

The whole idea of a hyperlink has philosophy elements attached to it. The statement, that on the web, you're just one click away from anything is a rather philosophical concept that the early internet veterans were very excited about. Visit any modern day portals and you'll find this idea bastardized to its limit.

MSN for instance, while I was investigating for this post, was literally over twenty-two-inches long, containing over two hundred hyperlinks (counted through Anchor elements in HTML), each of which appeared to be desperately trying to help you so that you are just a click away from everything MSN had to offer you that day. 


If you want to get an idea of the real scale of the size of the whole MSN front page you can take a look at full blown portal home page screenshot in real size.

Yahoo faces similar problems and so do tons of other portals out there. 

Remember the good old days of CD-ROMS where 'interactive' CD's were in and happening?  If there was one underlying idea in all successful CD-ROMs, it was this: they were 'interactive'.

You application is supposed to 'interact' with the user. It is not supposed to be a helicopter with complicated levers and switches the user is supposed to pull, turn on or turn off. What the interactive CD-ROMs in those days taught us about usability, is something most modern programmers drooling over technology, and most user interface drooling over pretty looking pictures and user interface elements seem miss out completely now-a-days.

Steve Krug in his book Don't Make Me Think suggests that working with a great web application should be an experience that is as interactive as playing 'Animal, Vegetable, Mineral'; the famous 'Twenty Questions' variant. My personal rationale behind this is fairly straight forward and simple. If you think about all the time that you spend online and the emotions that you experience in that time, chances are that most of your web experience is primarily composed of two types of emotions; or should we say two types of moments.

Put simply these moments can be classified as:

  1. The Question-Mark moments - when you are thinking about what to click next; usually because you are looking for something and aren't sure where to find it.
  2. The Exciting Exclamation Mark moments - when you are happy or excited; usually because you found what you were looking for.

The basic premise under which 'Twenty Questions' works is one of on making the journey of finding the answer as interesting as the answer itself. The trick is to make your question-mark moments really short, mindless and effortless. Every question mark moment should be followed by quick confirmations. Every confirmation of being right and being on the right track that you get; should be like a pat on a back; resulting in more excitement moments for you and encouraging you to stay hooked on to the application.

As the philosophers often say - if your journey isn't rewarding; reaching your destination faster just doesn't matter. Twenty Questions takes this premise and turns the journey to the answer into a fun-filled game. Steve in his book, 'Don't Make Me Think' suggests that web designers and web developers should do just that with web applications. Put simply Steve suggests that your web applications experience should be like playing 'Animal, Vegetable, Mineral'.

Deep. Don't you think?

Awesome; now let's do some more soul searching, get philosophical and talk about life and happiness.

On a serious note, besides just appreciating the philosophical aspect of things we're discussing here, let's talk a bit of about how you take a concept which is as abstract as this and turn it into something practical that you can use to make your applications better. 

That is what the folks at Google seems to have done when designing the iGoogle portal. What iGoogle does on its home page, for instance, is an amazing example of a portal playing the 'Twenty Questions' host for me. iGoogle doesn't know what I would like to see; so instead of confusing me with switches, levers or a gazillion hyperlinks like MSN, Yahoo and others, it offers me a courteous, polite question  on what I would like to see based on my interests.

If you were reading and were to take a look at the full blown screen-shot of the image above and compare with the full blown versions of MSN, Yahoo or other portals, chances are high that you will notice what iGoogle is fundamentally doing here.

It's interacting with you by asking you simple a mindless question; from the moment you land of the site.

On a side note, the message of the question itself - 'start by selecting some of our most popular content' - is confusing but the overall intent is pure and polite. The next time you visit iGoogle, it remembers your selection using a cookie and doesn't bother you with the same question again. What's really important here is that iGoogle doesn't worry about how many clicks might have to go in to tell it your interests. In fact, it expects you to start clicking right away; by keeping the clicks mindless.

Put simply, iGoogle is playing the host for 'Twenty Questions' and the game begins with a simple mindless question whose answer you already know based on your interests, the very moment you land on their home page. iGoogle doesn't work hard at reducing your number of clicks. On the other hand it works hard at making your clicks interactive, mindless and enjoyable.

When compared to the driving, while the MSN Home-Page and the Yahoo Home-Page are much like maps of their online city, landing on iGoogle Home Page is like landing on a freeway will really big billboards where it's really easy to find your way around, come back if you are lost and start drive again. You don't even need a map. Steve Krug talks about this analogy in his book Don't Make Me Think. He explains:

If You've ever spent time in Los Angeles, you understand that it's not a song lyric - L.A. really is a great big freeway. And because people in L.A. take driving seriously, they have the best street signs I've ever seen. In L.A.,

  1. Street Signs are big. When you're stopped at an intersection, you can read the sign for the next cross street.
  2. They're in the right place - hanging over the street you're driving on, so all you have to do is glance up.

Now, I'll admin I'm a sucker for this kind of treatment because I come from Boston, where you consider yourself lucky if you can manage to read the street sign while there's still time to make the turn.

The result? When I'm driving in L.A., I devote less energy and attention to dealing with where I am and more to traffic, conversation, and listening to 'All Things Considered'. I love driving in L.A.   

While most user interface folks spend sweat and blood in trying to offer you easiest way to get to where you want to go, sometimes, a long enjoyable journey is much more rewarding than just getting from point a to point b. Ever took that slightly longer drive through the freeway just to avoid the city traffic in the shorter route? Thought so.

Just like most modern day drivers aren't deeply worried about saving a little bit of gas, over a generally pleasurable experience and getting there faster; most modern day web users aren't worried about clicking a couple of times more, provided your application is interactive, the clicks don't require thinking and your page loads are blazing fast. In Don't Make Me Think, Steve Krug calls this 'Krug's second law of usability'. He explains:

It doesn't matter how many times I have to click, as long as each click is a mindless, unambiguous choice - Krug's second law of usability.

On the face of it, "number of clicks to get anywhere" seems like a useful criteria. But over time I've come to think that what really counts is not the number of clicks it takes me to get to what I want (although there are limits), but rather how hard each click is - the amount of thought required and the amount of uncertainty about whether I'm making the right choice.    

In general, I think it's safe to say that users don't mind a lot of clicks as long as each click is painless and they have continued confidence that they're on the right track. I think the rule of  thumb might be something like "three mindless, unambiguous clicks equal one click that requires thought"

Of course, there are exceptions. If I'm going to have to drill down through the same parts of a site repeatedly, for instance, or if the pages are going to take a long time to load, then the value of fewer clicks increase.

While in some cases less is more; when it comes to clicks, lesser number of clicks are not always better. The next time you spend a lot of time worrying about reducing the number of clicks you might actually be spending your time in making the application less interactive and cluttering your screens with elements which requires your users to use their brains instead of their fingers.

May I suggest, dear reader, that we spend our time in making our applications blazing fast by reducing the page load time and focusing on adding interactivity without worrying too much about the number of clicks. When you're cruising through high speed freeway, no sensible driver cares about the trickles of fuel he might have saved had he taken the shorter busy road with congestions. After all, speed still matters.

Is browsing through your application as rewarding as playing 'Twenty Questions'?

Is Your application blazing fast when it comes to page loads and responsiveness?

No matter how hard you try, they'll never be just one click away from everything.

Let's get our priorities straight. Remember, when it comes to user interface, less is more; even today speed matters much more than number of post-backs and when it comes to clicks, three mindless, unambiguous clicks are better than one requiring thought.

If you genuinely worry about your users, worrying about their brains having to work hard is much more important than worrying about their fingers having to work hard. In fact, if you can pull it off well, like iGoogle does, they might even enjoy and appreciate a couple of extra clicks here and there.

The idea of reducing the number of clicks in applications and websites is highly overrated. Unless you hear otherwise from  your users; start with the assumption that nobody is counting the number of clicks. Stop hurting their brains and start working on giving them an overall better experience; even if it means adding a couple of extra clicks.

posted on Friday, January 30, 2009 9:20:40 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Tuesday, January 27, 2009 by Rajiv Popat

You Could Be A Micro-Manager Or A Prick - And You May Not Even Know It.

Have you ever had a discussion with your manager where you felt that there was something wrong?

On the face of it, things are normal and you guys are just having, what can be classified as, a difference of opinion; but somewhere at the back of your mind; it feels like you're being pressured to give in and accept what you are being told to do without any further discussion. You've not been given a direct order or asked to shut up. On the face of it, things look like you're just having a 'logical discussion' except one tiny little problem; you don't feel like saying much or even presenting your point. Maybe it's just you; or maybe it's your managers body language. 


At Multiplitaxion Inc, during my early management days, while working at one of our client's place, we stumbled upon a couple of individuals who were basically monkeys needing to be sedated or removed from the project. When I walked into the cabin of one of one of their Vice Presidents something told me that things would not work out.  After quite a bit of soul searching, convincing myself and telling myself that I was just being paranoid I decided to have the meeting with him anyways.

What followed was a free lesson of management with nuggets of wisdom on how to increase efficiency of team members, how some people need to be 'managed', some people don't need to be managed, how some people cannot work without the pressure of a deadline, how a strong process or documentation can make some people work harder and how I need to pay a much more proactive role at keeping people under pressure. Put simply, I was being told to follow up with disinterested paycheck programmers much more frequently and get them to work by keeping on top of the status of their tasks.

To give due credit to this gentleman what he was saying may not have been outright stupid, but that wasn't my fundamental problem. My fundamental problem was this; the free lecture on management had started even before I had completed explaining my problem. I had been cut off and the nuggets of wisdom, often found in chapter-one-of-any-management-book-out-there were being thrown at me in no particular sequence. After wasting two hours of my already busy day I walked out of the cabin. During these two hours I wasn't even given a decent chance to explain my problem, leave aside expecting some help on it.

For the first thirty minutes as I heard him go on and on about how some people need motivation and how I should try to motivate these individuals rather than removing them from the project, there was a very soft gentle whisper deep down in my head. I couldn't quite hear what it said, but something seemed wrong.

I continued listening; and opening my mouth every now and then, under the expectation that I would be allowed to speak. soon. For every-thing that I said, I was being cut off, asked for facts, numbers, matrices and then I was being scrutinized to see if I had tried hard enough to 'monitor' these guys. After some time if felt like a police investigation to check if I had followed proper 'management processes'. 

Then as he moved on, about how I should objectively assess individuals based on their technical qualifications and how penalizing them for their laziness was a part of my job, the whispers only went louder. After I while I knew and I could say it to myself; confidently; and then I finally did it. I told myself - 'this guy is a prick'.

During my next six months in the project, as I spent more time with the rest of the client team in the project I learnt how this individual had a reputation of being an asshole. This guy, who for the purposes of this post, we shall refer to as Fred, had been give names ranging from 'The Mafia' to 'The Undertaker'; by his team. Each of these names had an interesting supporting story that the team would be more than happy to share with you at length over lunch if you cared to mention this individual's name.

At times I did feel sorry for Fred though. He was neither aware of his multiple names existing nor did he remember any of these stories which he had himself been a part of. I'm sure Fred felt that he had done an amazing job at motivating his team; just like he felt he had motivated me by teaching me how to 'manage' my team when I walked out of his cabin. I was of-course, utterly confused and intimidated by his indirect interrogation and body-language. If there was anything about management I learnt that day, from that meeting, it was that prickdom works on stealth. If you are an asshole or have acted like one in an isolated event, chances are, that you don't even know you are one.

Are you a Micro-Manager? Are you encouraging prickdom and creating Micro Management Zombies?

If you are reading this chances are high that you shook your head hard and said - 'Who me? Heck, no way!' - and you probably did it as soon as you heard the question.

Being fair to the question however, requires some solid soul searching and some serious conscious effort because if you happen to be a Micro-Manager, an asshole or a prick, chances are you don't even know it.

Kathy Sierra provides a sensible litmus test to figure out if you are a Micro-Manager or in danger of becoming one:

Do you have a micromanager? Or are you a micromanager? If you demonstrate any of these seemingly admirable qualities, there's a big clue that you might be making zombies.

1) Do you pride yourself on being "on top of" the projects or your direct reports? Do you have a solid grasp of the details of every project?

2) Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?

3) Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?

4) Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?

5) Do you believe that you care about things (quality, deadlines, etc.) more than your employees?

Answering even a weak "yes" to any one of these might mean you either are--or are in danger of becoming--a micromanager. And once you go down that road, it's tough to return. A quote from Dune (can't remember exactly) applies here, and goes something like:
"Be careful of every order you give. Once you give an order on a particular topic, you are responsible for always giving orders on that topic." 

The questions provide a very good litmus test to begin with, but not being a micro-manager and not being an asshole requires constant checks at each step of your life. It is a way of life that needs discipline, commitment and above all a thick-skin to accept your fault and apologize when you act like a jerk.

Success-Factors CEO Lars Dalgaard has a particularly interesting CNBC feature on this on topic. The interview ends with a funny but rather profound note:

Dalgaard says - 'it takes one to know one' - and he says he sees on in the mirror about ten times a day; but when he acts like a jerk; and we all do once in a while; Dalgaard says he tries to immediately apologize; Becky & Lissie says he had to apologize just about forty minutes before our interview.   

We all act like jerks once in a while. If you don't believe me, pause and look back at your life. Chances are, you'll easily spot a couple of incidents where you may have acted like one too. If you can't think of any such incidents, you might be acting like one right now; unknowingly. What sounds obvious and is the title for the first chapter of Michael Loop's book, is often not missed out by most people.

What separates a thick-skinned-life-long-learner from a certified asshole is the relentless ability to question yourself; answer the question honestly; apologize when you make mistakes and move on with a persistent desire to change. The trick is to, slowly evolve and morph into a better manager and much more importantly, a better human being, with every passing day.

It is with this spirit that we start a series of posts with an attempt to, every now and then, bring from the real life battlefields of software development, stories that will help you constantly ask yourself the important questions; Are you an asshole? Are you starting to take your first steps on the path of prickdom through micro-management?

Your direct reports or colleagues may indulge in mitigated speech; they may not be able to break the bad news to you as easily as you think they should; but I do hope that the stories or incidents will hopefully help you (and me) pause, step back, realize and recover, before it's too late to turn around. After all, you might be walking the path of prickdom through micro-management and you may not even know it.

posted on Tuesday, January 27, 2009 3:15:13 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Friday, January 23, 2009 by Rajiv Popat

Optimum Utilization Of Product Teams, Bullshit Busters And Sleeping Pills For Monkeys.

For years, software shops of this world have worried about the 'optimum utilization' of their people and their people's time. The Pareto Principal, when related to resource utilization, says that twenty percent of the people usually do eighty percent of the work in most organizations. Turns out, this fact, worries most organization and makes them uncomfortable. This is often cited by many, as the primary reason why projects and organizations fail. After all when you have big things resting on a small group of people, you have a little bit of a problem.

Or do you?

At Multiplitaxion Inc, we discussed this problem in really long meetings where we spent countless hours trying to figure out how we can make the other eighty percent efficient. The discussions continued for days; but after the first couple of days there were a bunch of us who had realized 'something'. This is a post about that 'something'.

If you've ever discussed the Pareto Principal and have worried about its effect on your organization; knowing what we realized back then helps. That 'something' that we realized, consisted of some serious dark secrets; and I am going to let you on to those really dark little secrets right now.

Even though I personally dislike referring to people as 'resources', chances are, that knowing these secrets will change your perspective on 'optimizing the allocation of resources' and will help you with 'resource management'. I want you to get your pen and diary and take some serious notes. Ready?

Secret #1: Projects don't fail because twenty percent of the people end up doing eighty percent of the work; That is why your HR or Resource-Management-Group 'thinks' projects fail.

Secret #2: Your HR or Resource-Management-Group doesn't know a shit about software development.

Secret #3: Projects don't fail because twenty percent of the people do eighty percent of the work. Projects fail because organizations go out there and expect the other eighty percent who have never done any real work their entire life and are not even supposed to be doing anything real, to get their asses off the couch and start doing 'something' without clearly defining what that 'something' is.

Now if you followed along carefully and took notes when I asked you to, chances are you probably know more about 'optimum allocation of resources' than your HR, the Resource-Management-Group or whatever it is that you call that group of people in your organization, ever will.

Don't believe me? It's story time!

I take you back into the depths of time and bring back from the days that have rolled behind a rather interesting conversation between a young and budding manager, who we shall call Jack and a young and budding developer who we shall call John. It's been a long time since I heard this discussion and I may not be quoting the guys exactly, but I do try to keep the heart and the soul of the conversation as close to reality as possible.

Jack: The HR called. I think they're going to allocate Fred to our project. He's free, wants some work and they think he can help you guys with business analysis and a few new ideas.
John: I thought you said you want us to deliver this project successfully?
Jack: (smile) What do you want me to do?
John: Anything. If you want us to ship, I don't want him anywhere near the project. Give him something to play with, keep him busy; give him a sleeping pill or something. He's a monkey Jack; you know it. (Long silence; followed by a feeling of awkwardness as Jack thinks.)
John: What!?
Jack: Don't worry about it. I'll give him sleeping pill. (smile)

And that was that. The project lasted for over a year and during the course of that project we never heard of, saw or worked with Fred. We saw him in the final project end party; after the project had ended; successfully. He was there to congratulate us. 

What this project manager had done was put the naughty monkey to sleep so that he wouldn't go mucking around the project and getting in the way of people who were getting the real work done. 

The specifics of how he did it, remained a mystery however. The project rolled out five successive phases; during the course of these five phases more than one monkey joined the project under the name of 'optimum utilization of resources' and every single one of them was sedated; quickly and quietly. None of them did any major harm. Starting that day; if you were a manager working with anyone who had worked in that team, how many sleeping pills you had for the monkeys became a measure of how much the development team respected you.

Scott Berkun describes the importance of this ability to eliminate bull-shit and why kick-ass project managers should have this ability, while talking about 'The Lost Cult of Microsoft Program Managers':

When I was hired 1994 there was a cult around the role. Program Managers had a reputation for being people worthy of being afraid of for one reason: they knew how to get things done. If you got in their way, they would smile. And then eat you. They drove, led, ran, persuaded, hunted, fought and stuck their necks out for their teams with an intensity most people couldn’t match. The sort of people who eliminated all bullshit within a 10 foot radius of their presence. How to be this way, and do it without being an asshole, was one of the things I tried to capture in my book, Making things happen. All teams need at least one leader who has this kind of passion and talent regardless of where you work or what you’re working on. 

Put simply, every project requires at-least one, what we shall call, a 'bullshit buster'. 

Now, this might sound simple; but like all simple things, it is not something you can take lightly or casually. This is serious stuff.  Bottom line; your project is only going to be as good as the quality of your team, their chemistry and the quality of your 'bullshit buster'. You can have a kick-ass team building a mind blowing product, but if you've left a few monkeys awake, chances are, that your project will suffer and while using your product, your customers will smell the shit those monkeys have leave behind.

If you've used windows live writer to write a blog post you probably love the product.  However, the very fact that you had to go through the pathetic installation process while getting the windows live writer installed on your box makes me feel sorry for you. The product installer yells out loud that the windows live writer team probably missed out on doing a good job at bullshit busting. Rory in his post on the live writer installation process explains his frustration with the product and the probable cause of why an amazing product like the windows live writer can end up having a really shitty installer:

I love Windows Live Writer - the app itself. It's one of the few reasons I run Windows XP inside Parallels on my Mac. It's one of the apps I didn't want to leave behind when making the switch. It's simple, easy to use, and, despite being a Microsoft app, doesn't get in the way of itself. The interface is a little cluttered for what it is, but a couple settings can clear that right up.

What I can't stand is how difficult it is to get the stupid thing. I headed over to the Windows Live Writer Blog and started the download there. It was about a 2 MB file. It was a nice change from the usual bloated downloads you get from Microsoft.

Of course, it turns out that it's just an installer, and not one specific to Windows Live Writer. As many of you have probably learned, it's a full on assault on your sanity. Instead of simply installing the one app I want, I have to negotiate with the god damned thing just to get the "real" installation started.

It reminded me of the old Real Player days when, before finally agreeing to install the app, the installer wanted your social security number, a list of any STDs you have or have had, your checking account number along with the ABA, an agreement to subscribe to eighty magazines you'd never read, and an offer to be put in a drawing to win a trip for two to Cancun if you mail them your passport.

When Real Player crossed the line from being self-promotional to being a scourge on your computing life, people stopped using it. Not everybody - there are still a few victims out there who don't know any better - but it's widely hated in geek circles where tolerance for bullshit is minimal.

Given the advantage of hindsight, it's mind-boggling that the Windows Live Writer team has gone down the same path. And, given my experience on the Inside, I'm sure that the Windows Live Writer team has little to do with the stupidity of the install experience, but as an end-user now, it's not my job to figure it out or to care. They're being represented by this crap, and their product is going to take a hit because of it. It's unfortunate, as it's likely some dipshit-originated system imposed on the Live Writer team by some grand Initiative in the Microsoft tradition. Someone does something good, and other people, eager for success and recognition internally, hijack and then ruin the product. This happened to me, albeit in a different way (and not when I was with Channel 9). I was in shock at how easy it was for someone else to swoop in and destroy something I was just getting right. The Windows Live Writer team probably - hopefully - feels the same way about what happened to their product.

That's Microsoft for you. 

The web is littered with examples of amazing software that were either sabotaged, destroyed or sometimes even killed because the bullshit-busters didn't have enough sleeping pills. Then there are a few awesome products out there that are just being closed-down under the name of 'best utilization of resources'. You don't really have to be an employee of these companies or a rocket scientist to guess what might be going on in some of these product meetings and who is making the final decisions about the products future and health. Yahoo Messenger for Vista is a classic example.

The story for this really cute and sexy little piece of software was simple. It was a Yahoo initiative and one of the most-used applications built on top of Windows Presentation Foundation that wasn't built by Microsoft. What set it apart was that it built ground up for Windows Vista. Yahoo built it, announced it, advertised it and promoted it big time for vista users. Most vista users loved it; not just because of its sex appeal but some decently interesting features like tabbed chatting, awesome skinning features and the fact that it kicked some serious ass.

Personally, I loved it too; but that's not important. What is in fact more important is that with the release of this little piece of software it finally sounded like the whole stupid anti-windows zealotry would end and differences between software giants would reduce. It looked like companies were bending over their back to use the best tools and give the best user interface and usability experience to their end users.

My dream of this beautiful software-development-world where organizations work on commonsense however, lasted till I ended up formatting my notebook a few weeks later and suddenly realized that Yahoo Messenger for Vista didn't exist. It was gone. Disappeared. Zip. It was almost as if the thing had never existed. Yahoo had not just stopped development on this version of the messenger but they had removed the existing version from their servers so that no future downloads were possible. The official announcement on the Yahoo Messenger Blog clearly indicated lack of bullshit busters at Yahoo:

As of today, Yahoo! Messenger for Vista will no longer be available for download from the Yahoo! Messenger website. We have discontinued stand-alone releases of the Yahoo! Messenger for Vista application in order to focus on delivering one Windows experience that is optimized for all Windows users.

This decision will help us increase efficiencies on our team and deliver one consistent, full-featured product for all of our Windows users. Our application was based on the Windows Presentation Foundation (WPF) platform which we will continue to experiment with and invest in. The knowledge we gathered from developing Yahoo! Messenger for Vista will also help us improve future versions of our Windows software.

We realize many of you have been with us from the first launch of Yahoo! Messenger for Vista and we want to thank you for trying it and providing great feedback with each new release. 

A few speculations on the web, like this one from Jonathan Kay for instance, have it that it was because of the 'cost cutting measures' at Yahoo that Yahoo Messenger for Vista was murdered.

Anyone with a little bit of an imagination might be able to guess what that meeting directed towards increasing the 'efficiencies' of the team, would have been like and how it must felt for the core team that was working on this version of the Yahoo messenger, was starting to kick some serious ass and taste success.

Personally, as far as I am concerned as an end user, I think the Yahoo-Messenger-For-Vista team were doing a mind blowing job when they were 'not efficient' and Yahoo shouldn't have worried a lot about increasing the 'efficiencies' on their team. After all, they were shipping and they were kicking some serious ass. They were doing just fine.

On a serious note, If nothing else, I use the live writer installer, real player and yahoo messenger for vista as examples of what happens people who have nothing to do with the core product teams get in really big rooms, give their ideas and then insist that these ideas be implemented.

Shit happens; even in some of the best organizations of the software development world; and if you don't have enough bullshit busters in your team your product could be next.

The Pareto Principal usually takes care of itself if you can simply retain your best and hire people who are 'done and get things smart'. You don't need to organize big meetings to discuss how to utilize your people better. Twenty percent of your people doing eighty percent of your work won't kill your organization or your product. It is expecting the other eighty percent who have never done any real work their entire life and are not supposed to be doing anything real, to get their asses off the couch and start doing 'something' without clearly defining what that 'something' is, will.

Having a kick-ass team of developers who are tightly knit, flock well, support their code and are continuously shipping; isn't enough. Every team needs at-least one bullshit buster who carries a lot of sleeping pills; even when you're a Microsoft, a Real-Networks, or a Yahoo.

If you happen to be at your workplace, look around you; if not think of everyone who you work with. How many monkeys can you see or think of? How many bullshit busters can you  see or think of? How many sleep pills do you think these bullshit busters carry with them? Are they enough to sedate all the monkeys and send them to sleep?

If you answered yes to the last question, you chances are you're going to have a great product, a work life full of fun and a decent number of innovations happening. I wish you good luck.

If you answered no to the last question however, you're going to have to attend a few really long meetings, do a lot of 'resource management' and deal with a lot of new ideas as people who have a lot of time and nothing else to do muck around with your project; we wish you and your team good luck anyways; you guys just might need all the luck you can get; every single bit of it.

posted on Friday, January 23, 2009 4:43:52 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, January 20, 2009 by Rajiv Popat

Why Kick-Ass Developers Should Become Managers - If You Don't Run Your Projects 'They' Will.

If you've told yourself that you've been a developer long enough and that you need to 'grow to the next level' and become a manager, or if you've been hopping jobs in your relentless quest of managerial power may I suggest that you close your browser right now, leave and never come back to this URL.

This post, is not for you.  Neither is it about you. Seriously. If you fall in this category of I-need-to-grow-and-become-a-manager developers or you want to become a manager because you find programming depressing,  this post is not for you. Trust us. Just close the browser and leave. Now.

Actually,  on a side note, you can also try out this URL and if that doesn't make you very happy you can go here for relevant content that might satisfy your needs.

Ok, 'they' have left.

Now, with the highly irrelevant audience filtered out, let's get this out in the open, shall we?

If you're still reading this, and you love writing code, you're probably on your life long path of trying to become kick-ass programmer and a one man army, who hates meetings and loves what he does. Long story short, you love programming; and you think it is fun.

Chances are also high, that you're probably an introvert who loves talking to the compiler because it's much more rewarding and predictable than trying to figure out human beings who happen to be fairly unpredictable and act funny at times. You're happy; you're content and satisfied your work keeps you 'in the flow' for a good part of the day. In a world where most programmers can't program let's just say, you're a rather rare breed. Go ahead; pat yourself on your back.

What I'm going to say now, will make you feel a little insulted. It'll make you feel like serializing yourself into XML, flowing over HTTP, appearing right out of my monitor, grabbing me by my throat and strangling me to death; but before you plan any of that; hear me out.

You need to become a --- manager.

Ok, easy. Breath. Let it sink in.

If you thought my giving that advice to you meant that I had lost my mind and that I should be strangled to death for hinting that you move over to management, Rob Walling has sensible advice for you in his post 'Becoming a Better Developer Part 6: Become a Manager':

Many of you gasped at the title of this post:

“Become a manager? Has he lost his mind?! I'll be a coder 'til the day I die!”

I'm not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you've managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle. 

Rob suggests five primary reasons why you should think of becoming a manager if you happen to be a kick-ass developer. These include:

  1. Observing your best developers and Learning what makes your best developers, the best.
  2. Judging your boss from a pragmatic perspective - It's Easy to Complain about Your Boss Until You Have to Do His Job.
  3. Learning How To Self Manage.
  4. Doing what it takes to achieve results.
  5. Pushing the  no surprise culture in the organization.

It is an rather interesting post with valid reasons why really kick-ass programmers and one man armies out there, should try their hand at management; but none of these reasons explains reasons why I relentlessly nudge kick-ass developers and one man armies to try their hand at management.

Here's my reason: If you don't step up, 'they' will. Scott Hanselman, accidently describes this what I mean by 'they', in his rather interesting post on 'Cake-mail, Ninjas on Fire, and other Anecdotes', through an incident he recollects:

When I worked with Travis Illig (who is the origin of the term "Hanselminute," by the way) and Stuart Thompson at Corillian/CheckFree, we had a project manager who didn't totally "get" stuff.

What I mean is that we'd be in a meeting, perhaps a feature meeting or something, and we'd be firing on all cylinders. Everyone was working well together, communicating clearly, finishing each other's sentences, just an all around great day. Designs become clear, backlog items were created at a furious pace, and it was generally felt that everyone in the meeting "grokked" what we needed to do.

At this point this particular project manager, who had been quiet until this point, would ask something like

"Now, wait, are you saying that Java replaces XML?"

...and silence. Crickets. We were hearing English *words*, but not a cohesive sentence. After all that, the last hour of banging through stuff, he had not just a disconnect, but a total fundamental misunderstanding of some aspect of computers and systems design. 

Reflect back and chances are you've been through one of these meetings. Unless you're very lucky you're probably flocked by some of these project manages. 'They' are all around you and if you don't manage your projects, 'they' will.

I see a talented programmer knitting his brows at me right now:

Hey Pops, you're telling me to turn myself into a do-nothing manager who does absolutely nothing, runs around with Gantt charts in his hands, sits in those lousy meetings and talks big even when he is completely clue-less about software development. I want to stay connected to programming and I want to write code; I love computers and there is nothing that is going to change that! 

Absolutely. I love computers too. In fact, in the past, I've gone ahead and said that even young and budding managers should write code. I avoid those meetings too; but consider this; as much as you might feel that managers don't do any real work; as much as you would rather stick to software development and as much as you might hate those stupid never ending meetings, depending on when you are reading this, chances are, that in the real world, in your very own organization, a couple of these stupid meetings are going-on right now even as you read this.

It is in these meetings that a bunch of Freds who know nothing about software development are estimating your timelines and developing the project plan for your next project. They're taking important decisions that'll impact you and your team. You need to be in some of those meetings and tell them that they've got planning all wrong. You need to be there; express your opinions openly, speak up with spine and conviction, show them how stupid some of these decisions are and more importantly, set timers to end those meetings.

Steve Yegge, in his post on (Not) Managing Developers explains why budding programmers wanting to 'grow up' and desperately become managers should not be allowed to.  He also describes the problem from an organizational perspective and how most organizations out there are killing themselves by considering developers, irrespective of how good they are, to be second class citizens. He explains:

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.

Unfortunately, many tech companies do exactly that, because they don't know any better. And they exacerbate the problem by setting up a bad feedback loop, in which managers get to make all the decisions and effectively have all the power, or at any rate too much of it. A company may say they value their engineers, but if compensation decisions are all made by managers, guess who gets all the compensation? And then everyone sets a long-term goal of becoming a manager, at which point the company is no longer focused on innovation.

If you're an engineer at a company where becoming a manager is considered a promotion, then you only have three choices: become a manager yourself, or leave, or resign yourself to being a second-class employee. 

Sadly most companies around the world that I've visited, consulted for or worked with, besides a couple of rather rare cases, fall in the range of organizations who consider managers to be a superior breed of employees. I've had my share of being considered a non-decision-maker or yet-another-developer whose feedback hardly mattered and having experienced it first hand I can easily relate to most developer complaining about having bosses who have no freaking clue of how software development is done; but there's a small flip side to  the story.

As I continue to work with and visit multiple organizations across countries I've heard stories of lost-and-clueless-bosses-and-managers multiple times and yet I see highly capable developers and kick-ass programmers, who know what they are doing and how software development is done, being highly reluctant to take up added responsibilities including genuinely leading and helping a team of other kick-ass programmers.

Most kick-ass programmers don't even what to try their hand at it. The Freds on the other hand, are, for obvious reasons of course, dying to move forward and take up 'more responsibility' only to make the problem Steve describes in his post, even worse.

If you're stuck in an organization where you have incompetent managers who have no idea of software development all around you and you think you can make your projects move smoother without them, you are primarily left with two options: "You can Change Your Organization or Change Your Organization." 

Unless, you plan on changing your job or you happen to be one lucky son of a gun who has stumbled upon an organization that lends him a boss who knows how an 'engineering and organizational culture' gets formed; you need to make small and progressive changes in your current workplace. Next time, they offer you a promotion, don't shrug and go 'Nah, I just want to write some code'. Accept it. Step up if needed; and then try your best to 'not manage developers' and not be a prick.

If you don't step up, 'they' will; and then, before you know it, Java will indeed replace XML and the world will end.

Ok maybe it's not that bad; maybe the world won't come to and end; but on a serious note, we have enough Freds flocking the world of software development, trying to 'grow' in their professional life, trying to 'manage developers' and screwing things up repeatedly. We really won't mind a few more competent developers who know what they are talking about, failing often, failing early and running projects pragmatically.

That's it. I'm done. I've committed the ultimate sin of insulting competent developers and decently good human beings by asking them to try their hand at management and morph themselves into managers if they can. If you happen to be one a kick-ass developer, who also happens to be decently good with human beings; or if you just happen to be someone who loves writing code, chances are that you may have perhaps felt slightly turned off by my gentle nudging and trying to push you to the other side of the wall.

If my gentle nudge ended up insulting you, go ahead; serialize yourself into XML, stream over HTTP, come out of my monitor and strangle me to death if you must; and then you can whine about how incompetent your managers are; or we can talk about how your team has been taking a lot of stupid decisions lately. Alternately, you accept leadership roles, make small differences and maybe even make the whole traditional 'manager' role redundant. 

If you're a kick-ass programmer capable of shipping, see if you can morph yourself into a manager; mentor one or more small yet smart teams of other kick-ass developers and then see if you can continue writing that kick-ass code you always loved writing. I wish you good luck.

posted on Tuesday, January 20, 2009 8:30:14 PM UTC by Rajiv Popat  #    Comments [2]