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., Street Signs are big. When you're stopped at an intersection, you can read the sign for the next cross street. 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.

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.

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.

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.

When you're a kickass programmer who spends more time with the compiler than with other human beings you tend to run into problems. You start to think of your code as a way for you to interact with your machine; instead of also considering it a way for you to interact with your end-users and other programmers who maintain your code. Long story short, you become slightly inconsiderate about your end users and you start thinking more-and-more like a machine.

You swing like a pendulum, sometimes expecting your users to understand stack-trace of your exceptions, which you display as error message, and sometimes considering your users to be complete idiots who understand nothing about software; so you lean towards not even telling them what went wrong and lean towards completely lame and generic error messages.

At Multiplitaxion Inc, I happened to witness an application where I saw a team lean towards the later. Someone in the team had found the ultimate way to encourage reuse in code and centralize exception handling. The result: Every crash that the application went through showed one generic error message. 'Error Encountered. Our support staff is working on fixing this'; or at-least, something to that effect.

After we played around with the application for a couple of days we knew exactly what to expect when 'anything' went wrong with the application. After a few weeks it turned into a joke; every time the our-support-team-is-working-on-fixing-this error appeared on the screen, there were remarks which were on the lines of, "awesome! now we know the support staff has some work to do and is finally working". I officially declared this as the forty-two of all error messages ever invented.

As hilarious as some of the jokes regarding the support-staff-is-working-on-fixing-this error were, there was something fundamentally wrong about the error. The ingenious idea of a 'generic error message' seemed to work under the premise that the user is an idiot who doesn't even have to be told what went wrong. To say the least, the error demeaned the ability and intelligence of the end user and whispered gently to the end user telling him - 'you're an idiot'.

The other extreme is telling the user everything that goes wrong in the application and expecting him to understand your code and stack traces. This approach turns out to be equally rude and demeaning. About Faces 2.0 by Alan Cooper and Robert Reimann illustrate the beautiful point about most applications being 'rude' by displaying irrelevant errors to the user and blaming the user for the error. They explain their point by using this error as an example:

Alan and Robert explain how this error and software applications in general are not just loud; but also rude to the end-user. Their initial reactions as they encounter this error are not just humorous but very close to how an end user's mind subconsciously thinks when it sees the above error-dialog for the first time:

Thanks for sharing. Why didn't the program notify the library? What did it want to notify the library about? Why is it telling us? Why do we care? And what are we Ok'ing, anyway? It is not OK that the program failed!   Software is often rude to the user. It blames the user for making mistakes that are not the user's fault, or should not be. Error message boxes like the one in [the picture] pop up like weeds announcing that the user has failed yet again. These messages also demand that user acknowledge his failure by agreeing: OK. Software frequently interrogates the user, peppering him with a string of terse questions that he is neither inclined or prepared to answer: "Where did you hide that file?" Patronizing questions like "Are you sure?" and "Did you really want to delete that file or did you have some other reason for pressing the Delete key?" are equally irritating and demeaning.

If there is one underlying theme in either providing completely irrelevant code related details to the end user or not even telling him what's wrong, it is the programmers inability to think like the end user. As programmers we go from expecting the users of our applications to be just as technically savvy as we are to being a complete idiots.

Most programmers may not admit to looking down on users who are not very technically savvy but the fact of life is that we tend to do just that when we write code. The LiveArt example, which made it's way all the way to the CNN website is a classic proof of this:

Of course, there are degrees of rottenness. "Some bad error messages," Ezzell says, "are just placeholders that slip through. We've all been there." Ezzell acknowledges he once wrote a message that addressed the user as "Dumbkopf" and was mortified when the dialog made its way into production. Thus, he sympathized with Orem, Utah-based Viewpoint DataLabs, which managed to include the following in its LiveArt install: Setup is unable to locate a suitable version of DirectX on your machine. You will need to install DirectX before you can use LiveArt98, dumbass! Sympathy notwithstanding, Ezzell awarded the entry third prize. Red-faced developers at Viewpoint noted that the message had simply slipped through the quality-assurance cracks and that they'd fixed the problem "about 4 seconds after we realized it was still there."

Yes, of-course the 'dumbass' part in the installer of LiveArt was an innocent joke by the programmers; but none the less it is an indication of the fact that most of us programmers tend to find the fact that computer users aren't as technically savvy as us, somewhat funny.

As a matter of fact, the truth is actually a little darker than that. Actually, we don't want our users to be as 'smart' or 'intelligent' as we are. We expect them be just 'like us'. We expect them to be just as connected to the compiler as we are, just as absent minded as we are and sometimes even just as 'stupid' as we are. If you don't really buy my point, the same CNN article, brings to you a few hand-picked error messages from the history of computing from environments ranging from Microsoft Windows to Unix:

1. Error: Keyboard not found. Press F1 to continue.
2. Windows has found an unknown device and is installing a driver for it.
3. Error 0000: No errors found, restarting computer.
4. The procedure failed with the following error: The command completed successfully.
5. Cannot delete tmp150_3.tmp: There is not enough free disk space. Delete one or more files to free disk space, and then try again.

These are classic error messages which may or may not have slipped through the cracks of QA or maybe it is a classic case the technical teams, not even realizing there was anything wrong with any of these messages. Of course, they were neither hoping nor expecting that the end users will feel a little, lost, when they encounter these messages.

Ben Ezzell has an entire site dedicated to the stupidity of the error messages; but Ben is not just critical. His criticism, like any good criticism, happens to be fairly constructive; it goes all the way to writing Developing Windows Error Messages; which provides excellent advice to developers. In his book, Ben advices that developers should work hard at trying to see that at the bare minimum, each of their error messages they write at-least help answer the following three questions that users typically have when an error occurs:

1. What is the problem?
2. Why is it a problem?
3. What can I do to solve the problem?

The task of displaying relevant and appropriate error messages to the user is an art picked with time and experience. As much as using accurate, easy-to-understand-and-act-on  Error messages might sound trivial to us as programmers; the act coding your error message has deeper impact on how people perceive your application and the love they give back to your application.

Of-course you can continue to classify making your error messages meaningful, sensible and genuinely helpful as a 'trivial' task which can be fixed 'later'; after you are done with your functionality; but there's one tiny little problem with that approach; after you're done, the 'later' never comes. Besides, not asking unnecessary questions; and eliminating un-necessary warnings is a way of life which requires considerable discipline throughout the development cycle.  Don't take your error messages and the politeness of your lightly. Consider spending some time thinking about these items as you code.

Go the extra mile and every time you write an error message question yourself - do you really need to inform the user about this error or can you fix it yourself? is your error message full of errors? Is it outright rude? Assuming that the user understands your stack trace is expecting too much from him. Assuming that he is stupid and hiding sufficient details from him  is stupidity on your part.

Making your error messages sound like it's the users fault or making it sound as it was some external factor which caused the error to occur and then providing no clue about how to fix things is even worse.

After all, if your application doesn't work, we all know who is responsible for it.

On a serious note, don't write rude applications, May I suggest that we as programmers, consider introducing some 'politeness' in the applications we build.

Building applications that are not rude and avoiding errors in your errors is an art. The level of politeness you introduce in your application will usually decide the love it gets from it's users. Now go search all the error messages in that codebase you're working with and start reviewing them meticulously; can you find errors and warning which can be avoided or eliminated? Are your error messages full of errors? Are your error messages outright rude or demeaning to the users? Consider putting in some effort and thought towards making them meaningful, polite and genuinely helpful.

If you study some of the awesome kick-ass managers you've worked with in the past or are currently working with, chances are that you'll begin to realize that all kickass project managers and the best team members in your team are much like the 'Men In Black'.

Seriously.

Consider this conversation between agent Jay and agent Kay from the 'Men in Black' for instance:

Kay: We do not discharge our weapons in view of the public! Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's an Arquillian Battle Cruiser that's about to... Kay: There's always an Arquillian Battle Cruiser, or a Corillian Death Ray, or an intergalactic plague that is about to wipe out all life on this miserable little planet, and the only way these people can get on with their happy lives is that they Do... Not... Know about it!

As funny as it might sound, the conversation to a large extent sums up what most kick-ass managers do. Honestly, it does. However there is one subtle way in which kickass managers differ from the 'Men In Black'. Unlike Jay and Kay, most kick-ass managers I've seen in action or worked with aren't even aware of the fact that they are saving worlds and changing cultures. They do so, silently and instinctively.

Tom Demarco and Timothy Lister explain the point I'm trying to make here, much more articulately than I will ever be able to explain it, in their classic book, Peopleware: Productive Projects and Teams. They explain this using the classic example of the Spaghetti Dinner:

Picture yourself a technical worker who's just been assigned to a new project. You know the manager and most of the other project personnel by name, but that's about it. Your first day on the new project is next Monday. On Wednesday before that Monday, you get a call from your boss-to-be. She's having a get-together, she says, for people on the new project. Is there any chance you could come by her place on Thursday evening for dinner with the rest of the team? You're free and want to meet the new group, so you accept. When you arrive, the whole group is sitting around the living room drinking beer and telling war stories. You join in and tell a few of your own. The client liaison, who has also been invited, does a bit about his department head. Everybody has another beer. You begin to wonder about food. There is no smell of anything cooking and no sign of anyone working in the kitchen. Finally your boss-to-be admits that she hasn't had time to make dinner, and suggests that the whole crew walk over to a nearby supermarket and assemble the makings of a meal. "I guess we must be capable of putting a spaghetti dinner together." Team Effects Beginning to Happen. Off you go. In the supermarket, you amble as a group through the aisles. Nobody takes charge. Your boss seems to have anything on her mind but dinner. She chats and laughs and offers up a story about the IRS. In spite of a general lack of direction, some things do get thrown into the cart. One fellow has already gotten the salad pretty well taken care of. There is some talk of making a clam sauce, and when nobody's opposed, two of your new mates begin to talk out the details. You decide to make your patented garlic bread. Someone else picks out a bottle of Chianti. Finally there is a consensus that enough stuff is in the cart for dinner.

If you weren't able to make out what just happened in the little story above or where I was trying to go with this post 'Peopleware: Productive Projects and Teams' also provides a very insightful explanation of what just happened in the story:

So far, nobody has billed a single day of effort to the project, but you've just had your first success as a group. Success breeds success, and productive harmony breeds more productive harmony. Your chances of jelling into a meaningful team are enhanced by your very first experience together. Presented this way, the spaghetti dinner may seem like a contrivance on the manager's part. But it probably wasn't and wouldn't have seemed like it had you been there. If you had asked the manager in question what she had in mind for the evening, she would have probably replied in total sincerity, "Dinner." A natural manager has got a subconscious feel for what's good for the team. This feel may govern decisions throughout the project. The entire experience is organized for small, easy joint successes. You have to look twice to see the manager's hand in any of this, it just seems to be happening.

The act of implicitly, innocently and unknowingly creating excellent work environments and cultures is a well known ability in kickass managers and true leaders. Michael Lopp describes this same act of unknown, silent, subtle and true leadership; in his post on the culture chart; where he talks about a core group of men who defined the engineering culture at Netscape by playing the game of bridge right in the middle of the cafeteria every Wednesday. He explains:

If you looked up the four core bridge players on the org chart, you'd learn a bit. One engineering manager, another guy from some oddly named platform team, another guy who had a manager title, but no direct reports, and the last guy who looked like a program manager. My org chart assessment: Meh. What I learned months later was that the folks sitting at that regular bridge game not only defined much of what became the Netscape browser, they also continued to define the engineering culture or what I think of as a culture chart. Unlike the org chart, you're not going to find the culture chart written down anywhere. It doesn't exist.

Irrespective of how big or small organization that you work for, run or own is, chances are really high that the culture chart has more influence on your organization than any other single factor. Michael, in his post describes elaborately how the culture definers innocently shape a positive environment around them and how you can detect the culture chart within the organization:

To deduce the culture of a company, all you have to do is listen. Culture is an undercurrent of ideas that ties a group of people together. In order for it to exist, it must move from one individual to the next. This is done via the retelling of stories. “Max was this nobody performance nerd and three weeks before we were supposed to ship, he walked into the CEO's office with a single piece of paper with a single graph. He dropped the graph on the table, sat down, and said, 'No way we ship in three weeks. Six months. Maybe.' The CEO ignored the paper, 'We lose three million dollars if we don't.' Max stood up, pointed at the chart, and said, 'We lose ten if we do. We must not ship crap.” Whether this story is true or not is irrelevant. The story about how Max saved the company ten million dollars by telling the CEO “No” is retold daily. In hallways. At the bar over beers. The story continually reinforces an important part of this company's culture. We must not ship crap. There isn't a corporate values statement on the planet that so brutally and beautifully defines the culture of a company.

Most organizations don't seem to realize the importance of these silent culture definers and the role they play in the overall scheme of things. Michael also does a great job at describing how the culture chart has a deep impact on the organization and particularly on the best of your team members:

Culture assessment is an information game and it's never over. Your job is to continually situate yourself in such as a way that, as quickly as possible, you can assess subtle changes in the culture of your company. I wasn't concerned when Netscape started losing market share to Microsoft. I didn't sweat it when the stock price stalled. The reason I started thinking about my next gig was, months before either of these two events occurred, one of the lunchtime bridge team left. The game stopped. The small group of four no longer spent a long lunch quietly, unknowingly defining the culture of the company and everyone who was watching noticed. They noticed when one of those who had humbly done the work that defined the company no longer believed enough to stay.

If you've been reading along so far it does end up sounding like these guys put in a great deal of effort to create an amazing work culture around them; but most of these kickass managers or culture defining team members I've had the privilege of working with or seeing in action, hardly have any such specific intent in mind. The same post on culture charts describes the intent with which the real culture definers work:

The people who are responsible for defining the culture are not deliberately doing so. They do not wake up in the morning and decide, “Today is the day I will steer the culture of the company to value quality design”. They just do it. The individuals who have the biggest impact on the culture and company aren't doing it for any other reason than they believe it is right thing to do, and if you want to grow in this particular company it's a good idea to at least know who they are and where they sit. You need to pay attention to this core group of engineers because as they do, so will the company.

These difference makers, culture definers or whatever it is that you want to call them, are not really thinking of changing the organizational culture, making their teams flock, developing deeper bonds between team members, saving your world or any of that crap. Helping the team in whatever small way they can; an awesome dinner or a nice game of bridge; that's all they have on their minds; especially when they are dealing with their teams.

After our brief digression into books like 'Peopleware: Productive Projects and Teams' and the post on the Culture-chart let's get back to what we started off with in the first place, shall we?

Men In Black. That's where we started, and we said most managers are like them; didn't we? Ok, here's how it goes:

Kay: We do not talk about project timelines in public! It distracts people in the the team and takes their focus off the real work. Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a stupid client who wants all this work done, deployed and running on production in three weeks... Kay: There's always an impractical, slightly lost, confused client that is about to wipe out all chances of success on all miserable little projects like this one, and the only way these developers can get on with their happy lives and code away to glory is that they Do... Not... Know about it!

Or should we say:

Kay: We do not talk about project timelines in public! It distracts people in the the team and takes their focus off the real work. Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a stupid client who wants all this work done, deployed and running on production in three weeks... Kay: You want to play a game of bridge? Hungry? Let's go grab a sandwich.

And before you know it, magic! The team suddenly has six months to ship, the pressure of deadlines has disappeared, people are nicer to each other and work is fun.

Here's another one:

Kay: We do not talk about crappy status reports and project plans in public! It distracts people in the the team and takes their focus off the real work. We help them ship! Jay: Man, we ain't got time for this cover-up bullshit! I don't know whether or not you've forgotten, but there's a vice president sitting at the client's office who wants who wants a weekly status report and a detailed project plan... Kay: You want to play a game of bridge? Hungry? Let's go grab a sandwich.

And before you know what happened, magic again! The neutralizer has been used on the client; those specific details have been wiped off their memory; they don't miss those status reports anymore and everyone seems to be getting the real work done.

The next time your manager calls a lengthy meeting and talks to you about how he plans to change the culture of the organization; chances are, that he has just picked up an inspirational management book from somewhere and is pulling on his awesome-manager-mask. Simply put, most probably, he's faking it. The ones who really change cultures, hardly ever plan to do it. In fact, they tend to do it one small step at a time, without even their own conscious knowledge that they are doing it.

Unlike the ones who spend their careers trying to pull acts of heroism, I've had the pleasure of seeing the real heroes in action working rather silently; taking one step at a time. These are genuinely inspirational individuals who influence and move others without even knowing or realizing that they do.

They will change you, they will influence you, they will make you work harder and turn into better human beings; and the funniest part of it is; you won't even realize they're doing that. I didn't; till I looked really hard and then I saw a couple of them; in action. They were right there; in my very own life and they were making silent, subtle changes in it.

Does going to office on a Monday morning suck? It always used to? If you answered yes chances are you haven't had the pleasure of seeing them in action or the pleasure of working with them. I have one little advice for you; be patient; and keep looking; the world has a very limited supply of these guys and if you're lucky you just might find them. On the other hand, if you do love and feel excited about coming to work on a Monday morning chances are that you have some of these guys around you.

If you do happen to have some of these guys around you, chances are that they are saving your world right now and you don't even know it. In fact, if they are genuinely good at this stuff, there is indeed a high probability that they themselves, don't know it. Now go find them; watch them closely and learn from them. I wish you good luck.

At Multiplitaxion Inc, a lot of us in the product teams were busy building products and shipping features. It was a great team of thick-skinned, competent, one-man armies who felt very strongly and passionately about the products being built. When features didn't work they were out there, willing to take calls in the middle of the night and support what they had written. This was a team of really hard working developers who had a lot on their plate.

They were building the product, enhancing it, supporting it and they were out there to listen to the customer and help them when they had a problem. Obviously they were busy; and because they were all busy, when we started marketing the product to the mainstream market we came up with the idea of having a different team take up the marketing websites, the product videos and the blogs.

The idea seemed innocently simple, efficient and effective at first; and then it happened.

Websites with (In)Frequently Asked Questions started springing up. Blogs having the same content as the marketing website started showing up. Posts started to including a very strong marketing touch to them. Below, I provide an example of one of the many posts that multiple individuals in the team started coming up with:

Do you know the [data-about-your-organization-that-the-application-provides-reports-on]? Or, do you know if [more-data-reported-the-application-includes]? "No"? Then I think you should. Trust me, this is a crucial piece of information that every organization must have. After all, [data-that-the-application-provides] is important for any organization. Your next question would be how I can capture this information. And answer is through [product-name].

The above example, is a rather small one. Overall, the whole bastardization of Blogs, Wikis and even Forums for the purposes of traditional marketing began and that was indeed starting to become a little frustrating for me. On the bright side, however, that wasn't the first time in this history of internet marketing that this was happening. In fact, we weren't even close to misusing blogs compared to a lot of other big names who had indulged into what Wikipedia defines as 'fake blogs':

A fake blog (sometimes shortened to flog or referred to as a flack blog) is an electronic communication form that appears to originate from a credible, non-biased source, but which in fact is created by a company or organization for the purpose of marketing a product, service, or political viewpoint. The purpose of a fake blog is to inspire viral marketing or create an internet meme that generates traffic and interest in a product, much the same as astroturfing (a "fake grassroots" campaign). Fake blogs are corrupted forms of public relations, which as a discipline demands transparency and honesty, according to the Public Relations Society of America's code of ethics and the Word of Mouth Marketing Association's code of ethics. Authenticity and transparency are important in social networking and blogging, as these codes of ethics attest. As social networking tools gain in popularity, corporations and special-interest groups legitimately use their own blogs to promote company agendas without cloaking their identities (one such example is http://www.blogsouthwest.com, a blog sponsored by Southwest Airlines and written by its employees). One notorious example of identity cloaking, resulting in a fake blog, was exposed when Edelman, an international public relations firm, created a fake blog in 2006 called Walmarting Across America. It was purportedly written by two Wal-Mart "enthusiasts" who decided to journey across the United States in an RV, blogging about the experience as they visited Wal-Marts along the way. While two people actually did travel across the United States in an RV, the publicity stunt was revealed to be paid for by Wal-Mart, a client of Edelman.

But, like all things in life, the internet and the software development world in general are real places where common sense, simplicity, transparency and the laws of karma eventually prevails. Tim Nudd describes how Sony was ripped and hugely criticized for their acts of trying to bastardize blogging as a medium to do fake promotion of PSP. He reports the whole incident rather articulately:

All I Want for Christmas Is a PSP pretends to be a fan blog (run by a guy named "Charlie", who says he's helping his buddy Jeremy get a PSP for Christmas), but it's a poorly disguised marketing effort—the URL is registered to Zipatoni. Visitors to the site are letting Sony have it in the comments. Says one: "If you want a PSP badly enough you should get together with an ad agency. Then try to sell the product through a lame website while attempting to speak down to what you consider your target audience." Even more comical: "Charlie" keeps posting his denials, in pseudo hip-hop speak. More than once he writes, "yo where all u hatas com from... juz cuz you aint feelin the flow of PSP dun mean its sum mad faek website or summ... you-all be trippin." Pathetic. Over at the Something Awful message boards, a commenter makes a good point about this effort: "Makes you wonder why they can't cough up the $8 to do private registration, to keep people from easily seeing that their 'blogs' are owned by promotional companies."

Tim describes how the whole Sony PSP episode finally ended:

Sony has now posted this mea culpa on the site: "Busted. Nailed. Snagged. As many of you have figured out (maybe our speech was a little too funky fresh???), Peter isn't a real hip-hop maven and this site was actually developed by Sony. Guess we were trying to be just a little too clever. From this point forward, we will just stick to making cool products, and use this site to give you nothing but the facts on the PSP. Sony Computer Entertainment America.".

Singling out Sony in the whole post seems like a lame thing to do. There have been many more including Wal-mart, Coke and many others. Internet mavens are in fact pushing so far as pursuing criminal prosecution for organizations which indulge in the act of marketing through false blogs. 

What we were doing at Multiplitaxion Inc, was nowhere close to fake-logging; but we had made a big mistake; while our PR teams and business analysts wrote the blogs they forgot two cardinal rules of blogging:

1. Blogging is like life – nobody cares about you or your products; unless you have something for them.
2. Blogging is like great sex – it is very difficult to fake the passion.

If there was one word which described what we were indulging in, it wasn't fake-blogging, it was lame-blogging. Thankfully, we failed early. Before any of these blogs went live we asked our PR team to stop writing posts till they genuinely connected to the product and if they couldn't connect to the products genuinely, they didn't have to write about the product.

Crowd-sourcing, collaboration, social networking and blogging might be seen by organizations as mediums to promote their products and there is absolutely nothing wrong with it. A lot of organizations including Microsoft – through ASP.NET and Channel 9 – do this rather elegantly and honestly. A lot of individuals including Scott Guthrie, Phil Haack, Scott Hanselman and many others also blog honestly, passionately and informatively. They provide genuine knowledge and value along with some really honest feedback to their readers, even when they are talking about their own products or products built by Microsoft.

When people visit your blog, it is your personality, knowledge, spine and conviction that they are relying on. The whole I-was-paid-to-say-good-things-about-my-organization-and-their-products-so-I-did argument doesn't work in the long run. If you want to write about your organization, know your organization inside out and write about crap that goes on in your organization while you sing it's praises. If you want to write about your products break the good news and the bad news; in fact the guys at 37signals suggest that you publicize your screw-ups.

With blogs you are not just pushing content. You're participating in a discussion and you're contributing. You're interacting and connecting with people. You are reaching out and in more ways than one ways, you are asking for their involvement, interaction, time, help or some combination of one or more of these. When you reach out the a huge group of people asking them to give you time, involvement, help, or combinations of one or more of these, you are judged by your integrity, transparency and honesty more than anything else. If communities  can donate a staggering four million to Wikipedia they can also call the Sony PSP blog pathetic and laugh at wall-mart for being caught with it's pants down.

So, go ahead and assume that marketing pitch on your posts and consider your readers to be first grade idiots; go ahead and write those crappy FAQs; go ahead and create fake blogs; go ahead and share your frustration, write your depressing diary or genuinely contribute and participate by being open, honest and transparent. The choices are all yours; make them wisely; because your users will make theirs based on yours. They may decide to abandon your blog, send flame mails, angry-comments or grace you with more visits, appreciation, comments with honest opinions and interesting discussions. Just like everything else, blogs follows the rule of karma – what goes around comes around; In fact, it often comes around 10x magnified.

Next time before you press that submit button, think. Question yourself about what it is that you're sending out - is it knowledge, inspiration, experience, wisdom, lie, sugar-coated-marketing-message-which-you-are-being-paid-to-spread, depression, frustration, random HTML that will get you a higher Google ranking and then cause disappointment to the visitors when they land on your website or is it something else? What ever it is that you're sending out, do you really want it multiplied 10x and coming back in your life? If not, may I suggest that you take your mouse far away from that publish button and delete the post immediately.

Whether you're an individual or an organization, your blog is your third place and one of the best reflector of your personality, don't bastardize it. Write with conviction, add genuine value and then support what you write; after all, what goes around comes around. Now go write something that you genuinely believe in or are genuinely passionate about. Seriously.

To surrender or not to surrender is an age old question in the game of chess when mere mortals are playing; but the most veteran grand masters of chess gracefully drop their kings announcing their surrender as soon as they sense guaranteed defeat. The grand masters often don’t act optimistic and hope that their opponent will make a foolish mistake which in turn will cause the game to completely toss around giving them an undeserving victory. When they know they’ve lost, they surrender, back out and end the game with a graceful acceptance of defeat.

The art and discipline of considering defeat as an integral part of the game also exists in the world of mountain climbing. One of my CEOs and an individual I personally looked up to during the early days of my career, and still do, describes his experience on a climb in our company intranet (I’m not sure if he would like me to publish his name or names of others involved in the climb so names have been changed for obvious reasons):

While we could see the summit, we knew that we were at least an hour away. There were dark thunderstorm clouds looming around the summit - they had appeared gloomy from a 1,000 feet below they looked morbid from where we stood. With tired limbs, faint hopes but determined minds [Jack] and I started climbing towards the summit. However, by 12:15 we were barely at 13,700 feet a good 500 feet short of the summit. [Daniel] and [Rogers] had heard from other guides in the mountain that the weather prediction called for heavy thunderstorms in an hour or so and they sternly signaled us to turnaround and head back. To make matters worse, they had heard that due to the sunny day, the snow had turned slushy further down the slopes, if it continued remaining warm, we could face treacherous conditions - snow sinking - one where the snow is so deep and loose that one falls right through it and sinks under. We pushed our luck to see if our guides will let us buy a bit more time but [Rogers] was obstinate and conveyed his point by saying: My job is not to take you up, but bring you down safely. The mountain will be here, my job is to be sure you can be back for another climb; and to soften the blow further said Jamling Tenzing (Sherpa Tenzing’s son) tried 11 times to summit Mt Everest - so some patience might be in order on our part While these were pacifying words, it did not help us overcome the anguish that we came so close but due to paucity of time could not scale the peak. We were also glad that thanks to our guides prudent judgment prevailed. Most climbers get into trouble because they ignore sound, sagacious advice. We took a brief respite and reluctantly started walking back.

Let’s snap back to the world of software development, shall we? Look around and I’m sure you’ll a rare very-few organizations, managers or even veteran developers giving such sound, sagacious advice to young and budding developers. Most organizations and managers instead seem to be much more optimistic and seem to push a you-can-do-it attitude even in case of obviously desperate and beyond repair situations.

We like to think of our kick-ass teams and one man armies as ‘super-heroes’ who can change the fate of the project by their sheer hard work and determination. We seem to push the idea that physical limitations like the iron triangle just don’t exist and heroes can pull out successful projects like magicians pull rabbits out of their hat or overcome all limitations like the Hollywood hero overcomes all difficulties before the movie ends. We push on, and turn simple mistakes and small defeats into disasters, merely by not accepting them in the first place.

Legendary author Steve McConnell considers heroism to be one of the 36 classical mistakes in book ‘Rapid Development: Taming Wild Software Schedules’. He explains:

Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported up the management chain until the last minute. A small development team held an entire company hostage because they wouldn't admit that they were having trouble meeting their schedule. An emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software-development process. Some managers encourage this behavior when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, such project managers undercut their ability to take corrective action. They don't even know they need to take corrective action until the damage has been done. As Tom DeMarco says, can-do attitudes escalate minor setback into true disasters (DeMarco 1995).

Of-course, Steve McConnell isn’t the only one with a thick skin towards failure. The folks at 37Signals are also particularly unashamed about giving up. In fact they go so far as saying that ‘giving up is good’:

Here’s the problem: You agree that feature X can be done in two hours. But four hours into it, you’re still only a quarter of the way done. The natural instinct is to think “but I can’t give up now, I’ve already spent four hours on this!”. So you go into hero mode. Determined to make this work, but also embarrassed that it isn’t already so. So the hero grabs his hermit cape and isolates himself from feedback. “I really need to get this done, so I’ll turn off IM, Campfire, email, and more for now”. And some times that works. Throwing sheer effort at the problem to get it done. But was it worth it? Probably not. The feature was deemed valuable at a cost of two hours, not sixteen. Sixteen hours of work could have gotten four other things done that individually were at least as important. And you had to cut the feedback loop to avoid feeling too much shame, which is never a good thing to do. That’s where the concept of sunk cost gives us a guide on what to do. It doesn’t matter what you’ve already spent. That time and money is gone. It only matters whether spending what’s left is worth it or not. Business school 101, but one of the hardest lessons to internalize. In other words, stop being so afraid of calling it quits. You’re playing to win the full season, not a single game. Every time you play the hero card, you’re jeopardizing the next game.

While the folks at 37signals talk in terms of two hours and sixteen I’ve seen organizations carry on with huge teams for months and even a couple of years just because the manager and individuals in the team were too ashamed to admit that they had failed. Heroism is exactly the kind of thing that turns simple failures into irrecoverable disasters.

You may not be a mountain climber or a chess player, but if there is one thing you must learn from both these fields, particularly when it comes to your project, it is this: When your logic and gut tells you it is not possible to win or to make it to the end successfully, give up; and use the time and energy saved for the next battle. After all, if you’re around, you can always be back for another climb or another game.

Don’t ruin your career chasing the Hollywood-like-dream of being a hero who fights difficult times and always emerges a winner. Get real; give up a battle or two if you must. Failing is good, as long as you Fail early and Fail often. When you know you won’t make it or when failure is inevitable, surrender shamelessly; move on to the next game and play harder. Don’t waste time trying to be a hero who cannot fail.  After all it’s about winning the full season, not every single game.

With this thought, I wish you, dear reader, a very happy life full of defeats, victories, fulfilling challenges, satisfying experiences and above all relentless passion to pursue whatever it is that you love doing.