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.

I’ve often insisted that project managers should write code and lead from the front. As you dive in, roll your sleeves and fight the battle hand in hand with your team it is equally important for you to consider them as comrades and not mere soldiers ready to charge or strike at your command.

When engineers, sometimes even smart and able ones, come to you expecting you to take their decisions for them it is often very tempting to take a decision and establish your ‘seniority’. The more you do it, the stronger you feel about your role in the organization and the dependence of your team on you. After all, it makes you feel wanted and it makes you feel in control. A whole lot of managers I’ve seen in multiple organizations around the world enjoy their involvement in any decision that happens in the project. Do you, dear reader, love being in charge of the driving wheel in your project or organization?

If you answered yes to that question with knitted brows wondering what’s so wrong with your being in-charge and in-control of your project, what you may not realize however, is that you might be, silently introducing the culture of mitigated speech in your organization.

Joel Spolsky describes how he himself, failing to give up the driving wheel on the right time and giving a careless tacit approval for a feature to be built in the product, nudged his team to start working on the feature without giving a lot of thought on whether the feature should have been actually built in the first place. He ends his post with a resolution to the problem that takes a lot of conviction on the part of the manager. His suggested recommendation is simple:

The solution, of course, is what I’ve been saying all along. STOP FRIGGIN’ LISTENING TO ME. I don’t know what I’m talking about. If you work for me, you’re welcome to get my advice, but you have to make your own decision because chances are you’ve thought MUCH MORE about the issue than I have and in fact we probably hired you because you’re smarter than I am.

The idea of lending control to your team members might sound a little absurd and often makes young, budding and even the most veteran leaders just-a-little insecure at first but is has a lot of obvious advantages:

1. It frees you up to take bigger and better challenges.
2. It enables your team to make smart and honest decisions.
3. It helps avoid the perils of mitigated speech.

Malcolm Gladwell, in his latest book, Outliers, describes how important handing over the driving wheel to juniors in your team is when he talks about the perils of mitigated speech. He explains:

Mitigation explains one of the great anomalies of plane crashes. In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat”. At first that seems to make no sense, since the captain is almost always the pilot with the most experience. But think about Air Florida crash. If the first office had been the captain, would he have hinted three times? No, he would have commanded – and the plane wouldn’t have crashed. Planes are safer when the least experienced pilot is flying, because it means that the second pilot isn’t going to be afraid to speak up.

The next time someone walks up to you with a Should-We-Build-This-Feature or for that matter any question, take him to a whiteboard and turn the table on him by triggering a I-am-not-sure-lets-see-what-you-think brain-storming-session. Discuss the pros and the cons, give recommendations, provide suggestions but make sure that it is not you who is making the final decision. It is your team that has to learn to do that in the long run. 

Long story short, unless you are heading for a crash, lead from the front, inspire the team, enable them, take sizable development tasks on your project, but don’t always take control of the driver’s wheel, specially when it comes to taking decisions.

If you want to lead, find lots of kickass programmers and one man armies who are capable of driving projects to successful ends. Mentor them and then leave the driving while in their safe and able hands. You can’t be driving multiple cars at once anyways.

Don’t handhold individuals on their way to success. Empower them to have their own share of mistakes and their own share of failures as they slowly attain success without any handholding. If you’ve picked a kickass team, got them to flock well in the right culture, and mentored them genuinely, they will take control, ownership, responsibility and start driving your projects towards success faster than you can think. Go ahead, lead from the front; but remember; you don’t always have to be at the driver’s wheel, taking every single decision in your project, in order to do that. 

During my work at multiple organizations, client offices and multiple cities around the world, I’ve seen individuals get nervous while talking to their CEO’s and Managers. Individuals fumble, sugar-coat discussions and avoid arguing with their clients. Some of them merely hint towards what they believe is correct and then decide to keep their mouths sealed. With time, they turn either disconnected or completely nervous and reluctant to give their ideas.

At the first glance you would classify them as spineless individuals lacking conviction but monitor them closely and you’ll figure out that these guys are indeed capable of fighting harder battles and taking up bigger challenges than their sophisticated counterparts who just happen to be a little more articulate with words.

I could go on and on about my stories on how people not ‘speaking up’ at the right time can lead to project failures and colossal-screw-ups. Here’s one:

Fred was asked by Multiplitaxion Inc, to come up with a data access framework that would assist them build multiple other applications on. Fred had done a couple of consultancy projects before but this was his first time at framework development and he struggled for over a couple of years with a decently big team of programmers. Time flew as Fred struggled. Two years later, Fred had failed; and that, those who understand software, will tell you is not such a bad thing after all. Two years later the stars aligned and a proposal showed up requiring the exact same features Fred and his team had been assigned to build. Fred was asked if the framework would ‘fit’ and if they could roll out the framework and build other enterprise applications using the framework. Fred hesitantly and reluctantly told the management that they 'could indeed build other applications on top of the framework but they would have to do ‘some refactoring’ and tweaking before the application became fully scalable; or something to that effect. Reality of it was that data access framework had broken windows all over the place and was snowballing into one large crappy piece of application right in front of the entire team. The team was clearly not as optimistic as Fed or the management and yet the members barely expressed their concerns in statements like - ‘maybe we ought to change the database server’, ‘maybe we ought to bump up the code quality’ and the like; and then they continued working. When the people who sign the paychecks looked at the framework they weren’t really impressed; but they had already been told that the application required ‘some refactoring’ before it would become fully scalable. It crashed here and there a couple of times and then individuals from the management level wrote back to the team appreciating the team’s effort and mentioning in the passing that the application needed to get better and they were sure it would get better with time. The application rolled out to the client, in semi-broken, fragile state where shaking it up really hard would start breaking things all over the place; this is how far things went and in all this time no-one ever mentioned that the emperor was in fact naked.

If you were reading that real life story that I was a personal witness to from the outside you would think that everyone in the whole episode was either spineless, lacking conviction or both; yet clearly that is not the case. 

Malcolm Gladwell feels that this communication issue is in fact the reason for most airplane crashes happening around the world. The linguists he interviews for his latest book Outliers, gives this phenomenon a name:

“Mitigated Speech”, which refers to downplay or sugarcoat the meaning of what is being said. We mitigate when we’re being polite, or when we are ashamed or embarrassed, or when we are being differential to authority. If you want your boss to do you a favor, you don’t say, “I’ll need this by Monday.” You mitigate. You say, “Don’t bother, if it’s too much trouble, but if you have a chance to look at this over the weekend, that would be wonderful.” In a situation like that, mitigation is entirely appropriate. In other situations, however – like a cockpit on a stormy night – it’s a problem.

Outliers provides chilling transcripts from the black boxes of crashed airplanes which clearly show how the plane crews were busy indulging in mitigated speech and worrying about what the captain or their air traffic controllers would think even when their plane was rapidly approaching a disastrous crash.

Outliers also does an amazing job at doing is describing the importance Power Distance Index (PDI) and cross culture mitigations in airplane crashes. The book describes how the country in which you were brought up and your culture will eventually have an influence how you deal with crisis situations. In Outliers, Malcolm uses the example of Columbian pilots landing an airplane which is low on fuel to illustrate how people from different countries and cultures deal with authority and superiors, even when involved in crisis situations.   A lot of it also ends up being very relevant even in the software development world:

There was something more profound – more structural going on in the cockpit. What if there was something about the pilots’ being Columbian that led to the crash? “Look, no American pilot would have put up with that. That’s the thing, Ratwatte said. “They would say, ‘Listen, buddy, I have to land.’”.

Ever wondered why a huge number of Indian programmers fail miserably at communicating the accurate health of their project to their counterparts around the world and why some of them fumble all over the place in conference calls with their clients? Read Outliers and you might just stumble across that answer and many more. 

The book provides stories of how the Korean airline turned from the worst airline with the highest number of air-crashes to an airline which was highly reputed and very safe simply by overcoming mitigation resulting out of their fundamental underlying cultural background. According To Malcolm mitigation has been the primary reason for most air-crashes in the history of the aviation industry. He explains:

Combating Mitigation has become one of the great crusades in commercial aviation in the past fifteen years. Every major airline now has what is called “Crew Resource Management” training, which is designed to teach junior crew members how to communicate clearly and assertively. For  example, many airlines teach a standardized procedure for copilots to challenge the pilot if he or she thinks something has gone terribly awry (“Captain, I’m concerned about…”, Then, “Captain, I’m uncomfortable with…”, And then if the captain still doesn’t respond, “Captain, I believe the situation is unsafe.” And if that fails, the first officer is required to take over the airplane.) Aviation experts will tell you that it is the success of this war on mitigation as much as anything else that accounts for extraordinary decline in airplane incidents in recent years.

After years of airplane-crashes the aviation industry may have learnt the lesson; but after iterating in the infinite loop of failure for years neither software-developers nor software development shops seem to be putting in any conscious effort to battle mitigation.

Do you have a problem of mitigation in your team? Do you yourself indulge in mitigated speech at work when dealing with your seniors or while making your juniors feel good, even when things are badly messed up?

If you answered yes to any of the above questions go walk up to your manager and express your opinions bluntly and openly or pass on some honestly blunt constructive criticism to your juniors. I dare you.

On a serious note, Don’t underestimate the perils of mitigation in software development. Create an open culture where mitigated speech is discouraged and ideas are thrown out in the open, freely. Rage your battle against the problem of mitigated speech before it leads your future projects to disastrous crashes. I wish you good luck.