Based on criticism of the last chapter I ended up taking it offline. One of the things that I learnt about writing while doing this book is that you need to give each chapter some soak time where it just sits on your hard disk and you spend days looking at it, refining stuff, adding stuff and most importantly, removing stuff. This chapter is my attempt at doing that. The chapter has been made to soak for few days and has been edited with considerable effort.

The purpose of the chapter is to introduce you to the idea of builders without a lot of preaching.

As always, we would love to hear back from you. Feel free to drop us a comment, send a tweet @thousandtyone, email me, ping me or call me if you have anything to say regarding this chapter or the book in general.

There is something to be said about throwing out "work in progress" versions of chapters for your book online. Last week, I published a chapter of my book live and within a week I heard from more than individuals who had important but varied feedback about that chapter. All their feedback basically boiled down to this: 'Pops, the chapter sucks! Take it down and rewrite it. Now!'.

The three primary reason why most people disliked the chapter was because:

The chapter was written with a timeline in mind and that showed in the writing.

I did not have a lot of fun writing the chapter and that showed in the writing too.

The third feedback was a rather long feedback which came down the fact that writing for a book is very different from writing for a blog post. When you are writing a blog post you have an audience that reads you and is aware of the context you write in. When you write for a book you need to tell a story, set the context and help your reader understand the context. If you don't do that you have lost your readers.

I continue to be amazed at how easily and clearly people can see through the work that is done halfheartedly without a lot of passion or work that is just done to meet a timeline.

So as of now, I am taking the chapter down and giving you a big fat sorry for wasting your time by asking you to read a chapter that was half baked; something that even I did not enjoy writing in the first place.

Going forward, if a chapter goes out, you can be rest assured that I have given it my best shot, have enjoyed writing it and that there is a good chance that you might have a concrete take-away or something to learn from the chapter.

And as far as this post is concerned, what you can take away from it is simple.

Whether it is a new feature, a new software or a new chapter of your book, the same rule applies when you are about to publish something online.

Did you enjoy writing it?

If you did not enjoy writing it, they will not be able to stand it when they download it.

Do not publish it live.

Let it soak. Work on it. Make it better.

Bring it to a level where you can get at least yourself to genuinely like it.

The page is slightly crude in terms of design but the good thing about this page is that it gives you a single URL from where you can download all files associated with this book. Of course, any new chapter added to the book will also get added to the Table of Contents.

It is funny how the guys who talk about management, hikes, career or rapid professional growth hardly ever understand or get to any of these while the folks who are getting a kick out of building stuff often end up getting good at all of this. What is also amusing is how most kickass developers around the world shrug at discussions which involve these topics but get insanely excited when talking tweaking a for-loop which has a database query inside it.

As you read the chapter please do remember that this is a draft version and is open to change. If there are any typos, errors or concerns you have regarding any of these chapters, please feel free to email me or drop in a comment in the comments section.

For those of you who know about my book project. I have started releasing parts of the book live as and when I get considerably 'done' with those parts. This is the first in the series of posts where the Acknowledgement section of the book goes live.

Your past work, when looked back, from a point and time in the present always sucks. Which meant that there were parts of the book that would have to be heavily re-written and parts that would have to be edited out.

The book was not going to let me go till it had received the final touches and till it was released.

So, after a state of panic and denial which lasted for a few days and then jumping over to a couple of added side projects, I came back to the book and decided to pause all other side projects of my life till I am done with releasing this book.

Your Help And Participation Required.

As always, when I sat down to edit the book and give it the final touches, I thought of releasing parts of the book as PDFs which you can download, read, talk about, blog about, tweet about, criticize, comment on and give your feedback on.

With every release of a new chapter, go ahead and grab a copy of the chapter. Go through it. If you find any typos, let me know. If there are parts that you believe are better left out, let me know. If there are parts that you feel would be better re-written let me know.

You can either leave a comment on the post where the chapter is announced for download or just email me using the mail icon on this blog.

The Content.

I've given a decent round of editing and proof reading to the Acknowledgements section of the book which is now available for download.

More chapters and added parts of the books will start following in the weeks to come. Looking forward to your comments, suggestions and opinions. Given the fact that I am a cheap author working without a real editor your help would mean a lot.

The Mango-Warehousing business in India is huge and yet very few people do it.

If you were to look at the business of warehousing mangoes; you might realize that; in order to get into the mango warehousing business; all you need to do is to go stay at the Mango-Farms in remote villages in India; during the mango season; look for the best prices that you can get and stock as many Mangos in your warehouses as you can.

The whole process involves some work; particularly before the mango-season in India.

Usually this translates to about a month worth of work.

Once you have put in that effort and have stocked the mangos; you go back home and sign a few sale-deals with retailers or grocery-stores. The signing of contracts with major groceries and distributors typically takes another month and does not involve any real hard-work.

If you; like a friend of mine; work in the business of warehousing mangoes; chances are that you probably work for just two months a year; and you make a truckload of money.

As tempting as some of these money making stories are; mango warehousing; dear reader; is not what I do for a living.

I build software and weave stories around software development.

Not to bring the people in mango warehousing business down; but I; dear reader; am not particularly interested in stocking mangoes for a living.

Are you?

The Point.

Now; if you have been knitting your brows with my mango-warehousing-commentary or the funny question it ended with; and nothing in this post seems to be making sense to you so far; would you; dear reader; do me a favor and count the number of business domains that you and your organization may have worked with in the last three years.

If the number crosses a dozen; chances are that your organization or you are a free floating developer with no niche or passion for the problem-domains you work in and you should seriously consider mango-warehousing in the farms of India as your next project.

I've witnessed quite a few consulting and product companies out there venture out into random business domains that have nothing to do with their niche and what most of them indulge in; can be referred to as trying-out-mango-warehousing-of-the-software-development-world. The cycle pretty much goes like this:

You find an industry in a remote corner of the world that no-one seems to be interested in; this gets you very little competition.

You spend couple of months building an application with a few CRUD screens around that industry.

You try to sell your CRUD screens to business folks on this industry; and then you make a truck load of money from those CRUD screens; or at-least that is what you try to do.

Put simply; you focus on making quick-buck by targeting obscure domains that have not been targeted yet; and then you build collection of random CRUD screens and PowerPoint presentations on the industry.

My previous organization for example was a classic example of this mode of working. We woke up one fine morning; discovered that there was a lot of money to made in training and literally ventured out in the business of software training.

A few wannabe-programmers; which no passion for teaching; were hired and turned into teachers.

It worked for a few months. Then we started sucking at it.

It ended with students literally rallying on their doors protesting against the poor quality of training they were providing compared to the money they were charging for these trainings.

Not to mention that in parallel; we has also ventured out into the world of retailing computer peripherals.

While this may sound like an extreme example of an organization trying to make easy money; by doing anything that can get them a quick buck; reflect on just how many absurd industries that you as a programmer might have worked in; for your current or past organizations.

Remember specialized accounting and payroll product for the tea-estates of the world that you organization was working on; or that specialized document repository designed specifically so that the oil mine workers can upload their well-files; or that specialized inventory tracking system that was supposed to help hospitals keep a track of their bed sheets.

You didn't feel anything about tea-estates; oil-mines or hospitals; did you? Neither was it your organization's niche. You were just trying to work for two months; get a few CRUD screens stocked and make a quick buck.

Your organization; dear reader; was indulging in act of trying to start mango-warehousing-in-the-software-development-world.

Genuine Mango Warehousing Happens To Be Hard.

Back to digressions. Remember how my friend does mango warehousing; works for just two months a year and makes a truck load of money?

If you were an average Fred looking at the business of Mango warehousing business from the outside; it seems simple. You work for two months; you hardly do any real work and you make a truckload of money; it seems so very easy.

It is only when you try it; that you realize that mango warehousing in India is serious business. It involves:

Owning warehouses; maintaining them; securing them; running them and operating them. All of it requires truck load of money.

Learning local languages (curious side-note: India; has more than twenty local languages); adapting to the local culture and knowing how local cultures work - not knowing this means you can literally get beaten up by the locals.

Developing a deep gut for how much harvest would happen in any given year.

Developing a gut for what a fair deal is; and then buying at the right price in the right time.

Developing contacts with retailers or people who would distribute your stock when the price is right.

The list dear reader; is endless.

As simple as it seems on the surface; Mango warehousing in India; dear reader; is serious business; it is hard; and can take you a life time to master.

For my friend's family; it took them two generations.

And believe it or not; during those two months; I think he feels really passionately about --- mangoes.

Where I am Going With This.

You see where I am going with this; don't you?

If your objective is to make money; it is easy to think of a thousand unexplored industries where you do not have a lot of companies building software. Then build a few CRUD screens around that industry and hope to earn millions through the collection of half-assed CRUD screens.

Next time you target a business domain; only because there is very little competition there and you think you can get away by not feeling-the-pain or just building a few oddly-stitched CRUD screens that save something to the database and spit out a few reports; think again.

Remember; mango warehousing is hard and the amount of passion and work you need to succeed in it is probably just as much as you need to build a project-path; even if; you do not see it at the surface.

Stop hunting un-explored industries and jumping from one domain to other in a desperate attempt to hit a gold mind.

At one of our clients; who for the purposes of this post; we shall refer to Multiplitaxion Inc; I sit through a project meeting with a heavy heart.

We are talking about adding features to a product that just does not seem to have taken off or generated any form of revenue, adaption or excitement; after almost two years of hard-work; effort and sweat of more than five genuine builders.

The marketing team still thinks we have a 'great' product that is gaining a lot of 'interest'. We hear sentences like 'our-product-is-getting-noticed' and 'our-product-is-gaining-traction'.

The vice president of technology; thinks the product just needs a little bit of more work and then it will be golden.

The director of marketing feels a few new features would help us sell the product in completely new markets.

Everyone seems to think that the product will eventually cross the Dip if we keep going at it.

Everyone; thinks; and has been continuing to think since the last three months; that we are really close to a version that customers will love and buy.

Something tells me we are nowhere close; we are just what I call --- 'lost'.

I cringe as I sit there and watch people preparing to-do-lists and backlogs of features which they believe will rescue the product and get us adaption.

What I am feeling right now; is what Malcolm Gladwell defines when he talks about Vic Braden who is able to predict with impeccable accuracy which one of the serves by a tennis player will be a double fault; every time he is watching a match. In his book; Blink; Malcolm explains:

Braden is now in his seventies. When he was young, he was a world-class tennis player, and over the past fifty years, he has coached and counseled and known many of the greatest tennis players in the history of the game.

He is a small and irrepressible man with the energy of someone half his age, and if you were to talk to people in the tennis world, they’d tell you that Vic Braden knows as much about the nuances and subtleties of the game as any man alive.

It isn’t surprising, then, that Vic Braden should be really good at reading a serve in the blink of an eye. It really isn’t any different from the ability of an art expert to look at the Getty kouros and know, instantly, that it’s a fake.

Something in the way the tennis players hold themselves, or the way they toss the ball, or the fluidity of their motion triggers something in his unconscious. He instinctively picks up the “giss” of a double fault.

He thin-slices some part of the service motion and - blink! - he just knows. But here’s the catch: much to Braden’s frustration, he simply cannot figure out how he knows.

I can smell something weird. I can tell you with utmost confidence that the project will not get any adoption, excitement or revenue in the years to come.

There is nothing technical that brings me to this belief though. Not the code; Not the implementation.

To be fair; we have a clean code base built to sustain the test of time.

And yet; something seems 'wrong'.

It does not seem like a half done project. It seems like a half-assed project; without any meaning; designed for the soul purposes of 'somehow' gaining revue in an unexplored business domain. Maybe it is the idea; maybe the industry; I cannot clearly lay my finger on the issue or explain it articulately in the meeting; but I can hear myself thinking out loud - 'This thing will not work'.

None of these 'feelings' can be found on the initial project documentation though. The project has an amazing 'Project Charter' document. It has a strong business case document and a flashy PowerPoint presentation which makes the 'marketing' and the 'business' very excited about it.

And yet; as everyone in the meeting room sits there trying to nudge us to do one more sprint - we; the team building the product know rather well; that another sprint and a few new features will not change anything.

After the meeting none of us speak; we just get to work for the next sprint.

Simple Reality Check; Watch your builders.

Within a couple of weeks; three of the best developers associated with the project contact me multiple times asking me if they can be removed from the project and moved into a different project.

When asked specific reasons on why they wanted to be moved - their responses are nowhere close to specific. Some of them 'think' the product would never get adaption. Others are not 'feeling it' while one goes so far as saying that he feels he is just wasting his time after an idea that would never work.

Developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.

I am sure there is some level of exaggeration here; but then having said let us assume that you work at Google and you end up proposing a really lousy idea that you think is great and will change the world.

Now; assuming that you know people in the right places inside Google; even if you were to get the product funded by Google you probably might not find a team to build a product based on this idea; primarily because your builders will probably just move to a new project and a new office before you even know it.

Let us be honest here.

If it is an idea you came up with; unless you are a super-genius-freak; chances are that you are going to fail pathetically at finding out the crapiness of the idea. All your time and energy is probably going in defending the idea from others who feel it is crappy anyway.

You builders on the other hand; are a completely different story.

Watching how happy or frustrated they are as they work on your product is probably the best way to figure out the genuine usefulness or uselessness your product will have when the first release is out.

Builders As Power-Users.

By the time you reach Betas which are stable enough to test out with your first set of sample business users it is probably too late to end the project and surrender gracefully.

Let's face it.

By the time you get to a Beta ready stage you have probably spent too much time, money and ego to come out say - sorry guys; we f@#cked up; lets stop all the work on the project; quit it cold and move on to something more productive.

What most organizations do not realize however; is that they have another set of really powerful users capable of giving them this exact same feedback even before the first line of code if written.

Any guesses on who this set of power-users are?

Your development team.

Yes dear reader. If you have hired seriously; your development team probably has some of your alpha-geeks who have spent years submerging themselves in technology; using software and using websites online.

Letting your builders have an opinion about the product that they are working on; and giving due attention to that opinion is pretty much like having a Vic Braden from Blink on your side and knowing in advance every time your product is going to ship with a result that can be best described as a --- 'double-fault'.

The Power Of Disassociation

Disassociation is the biggest form of dislike and disagreement that you can express towards an idea. When one of your genuine builders walks up to you and says he wants to disassociate and remove himself from a product he is working on; it is time to:

Remove him from the project --- No questions asked. Move him to something that is genuinely exciting; fun and something he believes in.

Question the very premise on which the product is being built --- are there elements of wishful thinking which will make you realize the truth only after you have wasted years of development effort and dollars?

Stop and talk to your team of genuine builders and this time; for a change; listen.

I leave you dear reader; with a thought worth harping on: The team that builds a product is the very first set of users that uses each screen of the product; as it is being built. If they; themselves find your product boring; mediocre and safe; to an extent that they want to disassociate themselves from the product; do you really expect others to adapt and use the product; dear reader?

Go ahead. Try giving your team the power to disassociate themselves from their current project if they do not believe in it; no questions asked. Now; go see how many of your genuine builders stick around; because that; dear reader is a genuine litmus test of how interesting your product really is.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

In the same book Steve talks about the importance of having some serious story-telling revolve around your project or your product. He explains:

The shared vision can be of something important—such as putting a man on the moon by 1970—or it can be of something relatively trivial - getting the latest update of the billing system out 3 weeks faster than last time. The vision can be virtually arbitrary, but as long as the whole team shares it, it will serve the same purpose of helping to bring the team together.

To have a motivating effect, the vision also needs to be elevating. The team needs to be presented with a challenge, a mission. The Amish farmers responded to the seemingly impossible challenge of building an entire barn in one day. High-performance teams don't form around ho-hum goals.

"We'd like to create the third-best database product and deliver it in an average amount of time with below average quality."

Ho hum. Yawn.

No team is going to rally around that.

Of-course; no vice-president high up in the pecking order will spell out the fact that he wants the boring database product with below average quality; but builders tend to have seriously strong gut-feeling built around reading between the lines and sensing what their organization ultimately wants from them.

If you are a manager; you could be sending out the mediocrity message to your team all the time. Multiple subtle ways of sending this message out exist:

The list is really endless. Reflect; and you might realize that your organization is sending out the mediocrity messages to your right now as you read this. Messages that you are taking and passing on to your team; as you sit and wonder why they are not hugely productive.

Newsflash!

There is a reason why dead-lines; panic; threats and policing does not work in software development - if your team is a team of whiners; you are trying these techniques on them will cause them to break down and black out. If it is a team of genuine builders --- they just do not care about you scoring fouls. Chances are; that they will either not listen; or if they do; they will eventually hibernate.

Most genuine builders that I have seen do not work for a ten-percent salary increment at the end of the year. What moves and motivates genuine builders around the globe are opportunities to make dents in the universe and leave their mark upon those dents.

The drive most builders have for this desire is usually much more than a short term ten percent salary hike in a yearly review or a pat on their back from their managers. If these; and the items mentioned in the list above are the only tools that you can offer your builders; you are better off moving or outsourcing your development to a third-grade Indian body-shop.

If on the other hand you are lucky to have landed up with a team of genuine builders and you want them to take your products, business and organization to the next level; may I suggest that you:

One of my primary job roles at Multiplitaxion Inc; was to interview every single candidate that would get hired into the organization. This meant that if you were thinking of joining Multiplitaxion Inc and got through the technical rounds; I would eventually end up interviewing you.

Irrespective of whether you were a developer; senior developer; architect; manager; creative-user-interface-programmer; IT professional or a database administrator; chances were that you would go through at-least one round of my interview before you were hired at Multiplitaxion Inc.

Your first couple of rounds would be highly technical with the best people we had in the specific area for which you were interviewing. I was supposed to be more of a last minute check to see that you had the overall right attitude and culture to be joining the organization. Put simply; I was being used pretty much like a filter which was supposed to keep the junk from getting into the organization.

Now; if you were a candidate; you would probably be thinking that after having gone through two or three rounds of technical interviews your chances of getting rejected in my interview; at-least for technical reasons; were a bare minimum.

Newsflash!

During my stay at Multiplitaxion Inc; I think I may have rejected more than ninety-percent of the candidates that came to me after having cleared one or more technical rounds. My reason for rejecting them:

Lack of technical competence.

With no intentions of insulting; or undermining the intelligence of candidates who interviewed with us; here are examples of questions programmers interviwing with me have marvelously failed at answering:

Write a program that prints out numbers from hundred-to-one; leave out multiples of five while printing out the numbers.

Give me one example of a project where you had to write your own interface and why did you need an interface.

How do you assign 2nd of January 2009 to a Date-Time variable Y.

And (believe it or not) How do you assign five to an integer variable Y.

I have had DBA's who have failed at answering questions on the lines of:

I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in the year 2009.

I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees who joined in 2nd January 2009.

I have an employee table with a joining-date column which is of Date-Time type. Get me the names of the employees sorted alphabetically.

During my stay at Multiplitaxion Inc; I interviewed IT professionals who had no clue as to what a subnet mask is; and managers who looked at you with completely blank eyes when you uttered the word 'sprint'. I've seen candidates fail at every single litmus-test-question that is out there.

Most of these are individuals; were employed in really-big body shops. To be fair to them; quite a few of them also had years of experience and top-notch-educational qualifications behind them.

At some point the folks in the recruiting department and I myself had concerns around these shocking rates at which I was rejecting candidates.

Were our builders failing that desperately at taking their first couple of technical rounds?

Was I being overly critical of the candidates?

Where were we going wrong; was it at the first couple of technical rounds; or was it at my round; we sat there and wondered for days.

Three Things Your Filters Should Know.

The mystery literally cleared itself out when we decided that we were going to let me sit through the first couple of technical rounds and then if needed let those engineers conducting the first couple of rounds sit through my round as I interviewed the same candidate.

Jack; who was one of our best builders around; started his interview of a candidate; who for the purposes of this post; we shall refer to as Fred; with questions and discussions around difference between abstract classes and interfaces. The answer was flawlessly correct. Then as he meandered from one question to another; the answers came in all right.

Somewhere during the course of the interview a sinister thought crossed my mind. Like all my interviews; I handed Fred my laptop and asked him to show me a real life abstract class implementation or example. What I saw in return was two angry young eyes staring at me in utter disbelief. The guy literally took minutes to figure believe that he had been given a laptop and had been asked to write some code.

From that point on; things went down-hill.

The interview ended with Fred taking over thirty minutes to write a reverse loop that would print hundred to one; skipping all multiples of five in between.

We dear reader; had hit a home run; with a simple realization.

The fundamental issue with Jack's opening question - difference between an abstract class and an interface - and his overall interviewing style - was that it worked under the assumption that anyone who was capable of answering harder questions on object orientation knew what for-loops were; had worked with for-loops and had done some basic programming in his life.

We; the collective we that represents the software development world out there; have spent years raising army of whiners who know exactly what to read; how to clear interviews and how to say things that impress folks high up in the pecking order. Put them on the spot with an IDE and a laptop.

Watch them fumble with icons on the toolbar; clueless about short-cuts on the IDE. Watch them fail as they attempt to write the simplest of programs out there; and take hours doing that.

Just because someone has a great resume and an impressive background; does not mean that the person is not a complete whiner.

Make no assumptions about what the person knows. For all you know; he might know nothing.

If you want to hire a singer; get him on a stage and ask him to sing. If you want to hire a programmer get him a laptop and ask him to write some code.

Months later as I scribbled the fizz-buzz question in front of a senior programmer; and asked him to quickly solve it so that we can move on to the harder questions; he quite literally retaliated with the objection: 'If I can solve this will it tell you that I am capable of doing my job?' --- The answer to this question as it turns out was rather simple and spontaneous: 'No; but your not being able to solve it will tell me you are incapable of doing your job'.

The next time you conduct interview for your organization; unless your organization is looking for whiners; try to keep one dedicated person in your organization who acts as a filter. When picking a filter; go get someone who makes no assumption and is not afraid or does not get intimidated when looking into the eye of a senior technical architect with nine years of experience and asking him to crack a for-loop.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Every once in a while however; I will find a developer sitting on the other side of the table; who; when asked this question; knits his brows; look up at the ceiling; pretends that he is trying to think of a failure really hard and then comes up with a random project name.

Ask him what was wrong with the project and watch him give random excuses with full blown jargon meant to point a finger at someone other than him.

The most common one of them all: 'Requirements were not well defined by the customer'.

Requirements were not well defined by the customer along with lack-of-process continues to remain the biggest and the most convenient excuses for most failures or fu@#kups that we as programmers are involved in.

After all these years of software development; we continue to work with customers who just cannot seem to be able to 'define requirements' for a simple payroll processing system.

Doesn't something about the whole requirements-were-not-well-defined arrangement thing sound terribly strange or fishy every time you hear it?

They Didn't Tell Me What To Build.

If you are a non-programmer; who is not associated with the world of software development; you are probably knitting your brows right now as you read thing and wondering - 'But Pops; if your clients want you to help them with their problem; how can they not tell you what their problem is?'.

To be honest here; the problem usually isn't about the client not telling you what the problem is. The problem is that over years of BDUF development; we as developers seemed to have changed our definition of requirements from a 'definition of the problem that the client has' to 'instructions on the bare minimum that I need to do to make this project successful'.

More often than not; when a young and budding programmer; who has seen his whining seniors do this; tells you that his project failed because the requirements were not well defined; what he is basically telling you; is that his client did not give him a step by step list of the bare minimum task-items that he needs to do to get the project successfully completed.

This is a question that defines the person asking it. It is very different from, "here's what you might need..."

If you ask people for the next task on the list, if you allow them to define the thing they are buying from you, you have abdicated responsibility.

Your work product becomes dependent on the insight and guts of the person giving you an assignment. This is especially dangerous for consultants and freelancers, because the answer might be, "nothing." Or it might be a paying gig that's profitable in the short run but a career deadener over time.

Far better to reach a level of confidence and skill that you can describe solutions rather than ask for tasks.

As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C'est la vie.

Related to this, it's critical that you as a development company love your product. And you won't love your product if it's filled with a bunch of stuff you don't agree with.

That's yet another justification for vetoing customer requests that you don't believe are necessary.

I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.

People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.

Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.

The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.

That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."

If there is one thing that is common between advice coming from Seth Godin; 37Signals and Steve Yegge; it is; that you cannot be letting the customer define your requirements. The first step to building a successful product; is living the life of your costumers; feeling their pain and understanding their problems really well; before you even think of building a product for them.

Next time you think back on one of your failed projects; if you find yourself blaming the customer or your business-analyst for requirements that are not well defined; stop; and reflect on how you could have understood your customer's pain and given them a genuine solution for the problem.

Saying that the requirements-were-not-defined basically puts you in the same bucket as thousands of other outsourced bodies-with-their-brains-switched-off working out of Indian body shops; and that; dear reader; is something no genuine programmer worth his salt should strive to become.

Next time you are working on a product; either build something which solves a problem you yourself have; or live the life of your client; connect to them; take time to understand their problem; feel their pain and add a little bit of yourself to the solution you give them.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

In an insanely huge meeting room; at a client who for the purposes of this post I shall refer to as Multiplitaxion Inc; a 'Yearly Status' meeting begins. As an external consultant who has been around for more than six months and has given more than one successful implementations; I am also invited to the meeting.

I look from one end of the table to another; my brain doing some serious soul searching and asking some rather philosophical questions to myself:

Why am I here?

Why are we all here?

What are we trying to achieve?

A vice-president opens the meeting with pep-talk on how team-work is essential for overall synergy and growth of the organization. He then talks about how personal contributions are nothing compared to team contributions and how we are all a big happy family.

I cringe.

Three of us have been working for sixteen hours a day for the last one month.

We are; probably the selected few who have shipped anything; in the last six months.

Something tells me I should talk.

Challenge the concept of team contributions being something larger and divine than our very own personal contributions.

Then I realize; I am not even a permanent employee of this organization.

I'm going to spare you the pain of having to go through a thousand words and over a dozen examples pulled out of history; that prove one thing: Almost any innovation worth its salt has been an idea and implementation that emerged out of one single mind.

Remember the Google's proprietary ranking algorithm that set them apart from a dozen other search engines out there? We call it 'Page' rank. Not because it ranks the pages but because it was the brain child of Larry Page.

You name a successful website; service or application out there and chances are; that if you look deep down into it's history you will find the single mind that conceived and executed the idea till the point where other builders started joining in.

Anyone who tells you that he is sacrificing his own interests and is building stuff for the team or is doing so to make the world a better place is also a whiner of the first order who knows nothing about building stuff.

Any manager who tells you that teams comes before individuals and gives you a pep-talk on how the-we-comes-before-me is not a manager. Just a whiner who lugged on to the we-wagon and kept taking credit for stuff other builders around him were busy building. Someone who could neither master the art of build nor contribute through genuine story-telling about the product.

We may kid ourselves into thinking we're writing out of some sense of public good, or to create connections, or contribute some small bit of knowledge to the world. But let's face it. Most of us blog because we're raving egomaniacs. We not only love to hear ourselves talk, we're incredibly eager to hear other people talk about us, and the more the better. I think Dale Carnegie put it best.

Nothing is sweeter to someone's ears than their own name.

So it should come as no surprise that I have an automatic Google ego search set up for my name. Nothing special about that. It is considered neighborly to have your ear to the ground (within reason), and to politely comment on relevant articles mentioning you and your "stuff". All very standard, banal, ego-fluffing stuff.

Ask any genuine builder out there why he does what he does and you will get his reasons: 'because I love doing it'; 'because it is fun'; 'because it makes me happy'; the reasons will continue. Long story short; most genuine builders are aware that they build stuff for their very own selfish reasons.

Half way through other builders join in; create what marketing guys and traditional managers like to call synergy and you have a remarkable product that ultimately ends up making small or big dents in the universe.

But Then Why Would Other Builders Join In?

I can almost see a young and budding manager knitting his brows already. 'Great! Now you are suggesting that team work means nothing. That we all focus on individual contributions and forget the whole idea of contributing towards a team' - he says.

Yes; Mr. Manager. That is precisely what I am suggesting.

As someone who has himself makes contributions as patches to open source projects out there; I can tell you that I do not do it for the good of mankind or some other noble agenda of that sort.

I do it purely because I want the patch in the project SVN so that I do not have to worry about making the change every time I upgrade the version of the framework.

The folks who receive the patches are happy to apply them because it makes their product stable gets more people to use their product and gets them more popularity and in some cases an ego-boost.

None of us are working for the divine-goal-of-the-team.

None of us are giving or taking a truckload of crap about keeping 'the-we-before-the-me'.

We have common selfish interest which are aligned; which bring us together.

The teamwork; helping each other or even the so-called-management-buzz-word called synergy results out of these commonly aligned and totally selfish interests.

In fact; these are precisely the cases where the teamwork is the highest; where people from completely different countries, cultures, time-zones and people who do not even know each other; come together and make things work.

Now here is the funny part - you don't hear words like synergy and we-is-more-important-than-me in these environments.

When builders see amazing stuff being made; they will join in. They will join in because they want to be in the flow; they want to be a part of something huge that eventually leaves a mark on lives of people; they want to learn something new; they want to find and create meaning out of their very own lives; they enjoy being a part of it or for countless other reasons all of which are totally selfish.

Make no mistakes about it.

Lets Stop It. Now. Seriously.

Lets work on a project shall we?

Hypothetically; that is.

For reasons that are purely selfish; I will give in complete individual contribution to get my module up and running in time. I will bend over my back to help you integrate with it. As a matter of fact; I will even go out of my way to help you with your module; purely because; one: it makes me feel good about doing that; two: because it establishes me as a really smart person in the team and three: because I don't want a failure against my name.

I expect you do the same; for similarly selfish reasons.

If our interests are aligned; we win.

If they are not; we fail.

It is really that simple.

Can we please stop talking about team-work, synergy and exchanging truck load of crap regarding how the we-is-more-important-than-the-me or how the team-comes-before-individuals. It's boring; hugely artificial and not even funny.

If you run a team; may I suggest; dear reader; that instead of giving your team long winded lectures and speeches on how the-we-is-more-important-than-me; give them a platform where every person in your team can genuinely and truly contribute individually.

Build an environment where they get credit and recognition for their individual contributions.

Find folks who have interests that do not align with yours and get them on projects where their interests have a higher chance of aligning with yours.

Do that and all the pep-talk on teamwork and synergy that you always gave in your meetings; will not even be necessary.

Recognize the important of individual contribution and all of those organization-changing ideas that you had about team work and 'synergy' will start turning into reality; faster than you can think.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

When the yearly reviews happen; you would have jumped ahead of all your colleagues; your manager has developed a reputation of your being an alpha-geek who never fu@#ksup and you would have earned your promotion.

You; are a climber.

Choosing to be a climber is a perfectly legitimate career choice; except of-course that there is just one minor hiccup associated with it.

Yearning desire to indulge in the act of 'climbing' probably creates more asshole than any of the other reasons.

Brief Digression and a quick history lesson.

The battle of Gaugamela is taught in practically every history class that talks about Alexander. An example of amazing planning and war techniques; what only a few history books will tell you; is that this war was also a classic lesson in managing intelligent human beings; growing as a leader and winning wars.

After a fierce battle; execution of an amazing war plan; Alexander is practically minutes away from slaying his arch enemy; the Persian King Darius III; when Parmenion; a general in the army; sends out a distress signal.

Continue his advance; slay Darius; win the battle or Turn around; move to help Parmenion and let Darius escape.

Alexander chooses his men over victory.

He helps Parmenion; lets Darius escape and eventually wins the battle.

Historians around the world will tell you that what Alexander really won in Gaugamela; more than the battle; was respect and trust of his army; which eventually won him multiple other battles that followed.

The Builders Path.

If you are in any remote way associated with software development; like it or not; the sky will fall; and when it does; I don't care how amazing your work culture or your work environment is; someone high up in the pecking order is doing to ask the question that ultimately destroys projects around the globe:

"Who was responsible for the fu@#ckup?"

When the sky falls; you are left with pretty much two simple choices: you can take the climb path or you take the build path.

The build path happens to be slightly less glamorous.

You find yourself sitting in front of your colleagues monitor; helping them out with threading issues.

You find yourself trying to talk about the problem rather than answering irrelevant questions like who was responsible for it.

You find yourself giving cover fire to your team and every once in a while you find yourself in a heated argument with your manager; which to be honest; is not the best way to get a promotion.

I don't care how lucky you are. I don't care how amazing your work culture is. If you; dear reader; have not taken a few punches of office-politics; at-least once in your life; you haven't learnt enough.

You think that the bully who made you do all the work in the school project and took all the credit for it; when you were in school; was an asshole?

You have no idea what your first political experience at an organization is going to be like.

You; are still a political virgin.

Days move on and then one seemingly beautiful morning; you find yourself in a hostile political environment of a really-shitty-client-and-his-organization.

That's when it hits you; really hard.

Smack on your face.

It is at this point that you lose it --- your political virginity.

If you survive the blow and find yourself reading this; pat yourself on your back.

You are now a 'manager'; for better or for worse depends on the survival approach you picked.

Survival.

For me; my first exposure to the stupidest form office politics was at a client; where I was stationed for a period of three months. For the purposes of this post; dear reader; this small client of mine comprising of around a fifty odd people; shall be called Multiplitaxion Inc.

Multiplitaxion Inc, had a team of three genuine builders who were not just surviving but thriving and getting things done.

You do not win soccer matches by fighting over fouls. You win them by scoring goals.

A week before the project ended; we scored.

As a response to a month old email that complained about an internal status report not being spell-checked; one of the three responded with the latest status repot which showed that we were a week ahead of schedule and were done with the project. The report also mentioned that we had a formal sign-off on User Acceptance Testing from the QA department and the business users.

Then; he signed off the email with the words which were on the the lines of:

"This one is spell-checked. Special thanks to you for your continuous support and encouragement during the course of the project".

During the course of the project there were over scores of emails that none of us responded to.

When the project ended I was glad we did not.

This team; dear reader; did not need a manager to sedate the monkeys - we had survived the stupidity of office politics; and we; dear reader had picked the survival path of scoring instead of haggling over fouls and learning the art of whining.

Would I go back to work for this client again?

Absolutely not.

Something tells me none of us from that team would.

Having said that; what this client of mine, taught me was invaluable.

If you happen to be my manager in future; and if you send me an email; telling me how critical it is to use 'Verdana' font in the internal status report; that only you are going to read; please do not expect a response. You dear; manager; just scored a foul.

I am sorry for not responding but I will try my best to respond when I am done with scoring a goal.

Honest. I will.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Even if the so-called-senior programmers refused, cringed and pull back at the very thought of working under panic or doing something quick-and-dirty; I; dear reader was around to get-stuff-done; especially when the sky was falling.

Remember those visual-basic applications with a lot of hidden text boxes and a lot of public modules?

Heck; I built a lot of them.

But; at the end of the day; I got stuff done --- at the eleventh hour; when people were getting all worked up and wanted the work done.

Crisis As A Way Of Life.

While as developers; we all do crisis-based-reactive-programming or what I have called demo-driven-development; the problem with crisis is that if you allow it to happen; it will.

All the time.

Humor me; dear reader. Analyze your organization; take a sample size of a few managers in your organization. Chances are that you will at-least find a couple of them whose projects have a track record of people staying late; people working holidays; people making random mistake; people panicking --- people firefighting.

Now; go look at teams within your organization and I'm sure you will find teams that have a track record working in projects which require a lot of firefighting.

I; dear reader; am talking about a life-style; where the team spends every single day working on 'changes' suggested that day and fumbles to get them done by the end of the next day; and they do this; day after day; project after project.

Managers; who know how to create crisis out of every situation.

Teams; which will be the most reactive and productive when asked to firefight; everyday.

Programmers; who crave crisis; because it lets them flex their engineering mussels and flaunt their heroism.

Soak time; is the time when you brain is chirping away at more problems connected to the primary problem are trying to solve. Problems that are not documented as 'exception flows' in your use-case-document. Problems that are only found and fixed during the soak time.

Soak time; dear reader; is the time when your brain decides to take the reporting module of your application out of the core-application-code and package it as a separate component.

It is the time when you take the most critical decisions associated with your codebase; the problem that you are trying to solve or the overall product.

Observe any genuine builder out there; and you will learn that a decent part of the day for any builder; is his soak-time.

The biggest problem with crisis; dear reader; is that you have --- no soak time.

When you are in crisis mode you are doing only one of the three things:

'Monkey Attacked, Monkey Fights Back'.

'Monkey Attacked, Monkey Runs'.

'Monkey Attacked, Monkey Gives up. Monkey Gets Hurt'.

Ever seen developers in meetings trying to convince their managers why a particular feature cannot be done and then scrambling to do it when their manager refuses to listen or accept the fact that it cannot be done?

If you have, you probably know what I mean by the three monkey-statements I make above.

Irrespective how how amazing a manager you are; crisis situations happen once in a while.

Create crisis situation; project after project; and all you are doing is turning your team of genuine builders into monkeys without any soak-time.

Advice For Managers: Think.

The next time; you press the panic button as a manager; think.

Can you prevent it?

Can you focus on the core and have your team build more by building less?

Are you giving them room to maneuver and giving them the 'soak time' they need to take the right decisions for the project or are you just turning them into monkeys that 'react' to situations and your panic-buttons all the time.

Advice For Developers: Think.

The next time; you decide to indulge in the firefighting exercise as a developer; think.

Is it really as critical as your manager is making it sound?

Is there stuff in there that you can turn around and say 'no' to building?

Are you being asked to solve a problem and add meaning through your work or are you just being made to react to situations and write some random code?

Isolated incidents of firefighting are fine; but if you find yourself firefighting all the time; you might be getting your promotions; hikes and pats on your back; but chances are you are not developing any real roots or doing anything genuinely innovative.

I was a firefighter. I still am; but I don't really go around looking around for crisis situations so that I can flex my mussels and show my heroism or get a few pats on my back.

In fact; as a developer; I try my best to avoid the crisis situations all together if I can. As a manager; creating panic and crisis situations definitely shows up as one of the top items of my not-to-do-list.

Remember those visual basic applications with a lot of hidden text-boxes and lots of public modules?

I try my best not to make them now.

Maybe I have grown older; or maybe that is just a part of growing up; as a developer and as a manager.

The next time you find yourself firefighting take a pause; and reflect. Are you doing it all the time or is this just an isolated incident? If you find yourself firefighting all the time; dear reader; it is time to keep some soak-time aside; figure out what you are going to do about it and then go out and do it.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Early on in my programming career as a student; we worked on a system which was supposedly an intelligent system capable of striking a textual conversation with the end user. This was a small research project at the school level which won accolades at a few local news papers and received a little bit of attention.

The premise of this project was fairly simple. As far as human beings are concerned; most; at-least quite a bit of what we learn; is learnt by aping things. You know; the monkey-see-monkey-do way of learning and doing things.

Having said that; the basic premise on which the system was built does hold true even today. The human brain; at-least a huge part of our brain; evolves by observing the things that happen around us; deducing our own reality out of what we observe and then aping the changed versions of that reality back into our lives whenever we need to or want to.

How do you become a great author?

By reading lots of good literature.

How do you become a great poet?

By reading lots of good poems.

How do you become a good builder?

Now; if you are a normal human being with a functional brain you probably answered instantaneously; - 'you do it by observing a lot of builders @ work'.

That right there was a live example of learning by aping logic based on the first question and using it to answer the third one. As human beings; we do this all the time and after weeks of observing genuine builders at work; one of the things that I've learnt is that the sooner you start observing genuine builders around you and the sooner you at-least start understanding what they are doing; the better off you will be; as a builder.

The saying "practice makes perfect" is inaccurate, as any music teacher will happily tell you. Perfect practice makes perfect. I'd been practicing sloppily, and had become very good at being sloppy. For one thing, I was tensed up, trying to force my fingers to make the right moves. So I only knew how to play tensed up, which exhausts you quickly. I was actually doing all sorts of things wrong, more than I'd ever have guessed, but the details aren't important. What's important is that I was thinking about it all wrong.

I knew that everyone said you should take lessons, but I had convinced myself that I didn't need them. I was actually a bit afraid to take lessons, because instructors were telling me I'd have to "forget everything I knew and start from scratch." That was a stupid way to attract new students! Nobody's going to want to throw away years of work. It was also incorrect: lots of the stuff I knew carried forward. Learning the proper technique turned out to be more like learning a new song than learning a new instrument. But at the time, I thought: "Screw that. I know how to play guitar. I'm happy with my playing, and I'm not going to change the way I play."

I hope you don't think this discussion is too far afield, because my attitude towards guitar lessons was identical to the way most programmers feel about their technical skills. "I'm already great at Perl, so I don't want to go back to the beginning and learn C, or assembly-language. I like the way I program." Or: "I'm great at Java, and I don't see any reason I should have to learn how to write scripts. I can get by just fine without them."

The thing is: I wasn't a great guitarist, and Perl-only folks aren't great at Perl. But you can't see that until you've done the hard work of learning what your instructors are telling you to learn.

Practice Drill #2: Make a list of programmers who you admire. Try to include some you work with, since you'll be borrowing them for some drills. Make one or two notes about things they seem to do well — things you wish you were better at.

Simply thinking about good programmers you know, and what makes them good, is good practice in itself. But we'll also use the results of this drill in some later drills.

Finally, there's music practice. There are sooo many types of practice. The common characteristic among them is that practice has to be habitual. Professional musicians develop daily and weekly practice habits that they keep up for their entire careers. Practice requires a recurring time commitment.

One type of practice is simply to go listen to other musicians play, as often as you can. You'll learn a lot just by watching and listening. The analogs in the programming world are watching other people program, and reading their code.

This book; in general and this series of posts about observing-and-understanding-genuine-builders in particular has been all about watching builders @ work and learning from them. If you want to learn the art of genuine innovation; including the craft of building stuff that is genuinely remarkable; you don't start by getting in a meeting room and thinking of a grand idea.

You start by paying close attention to every builder that you can lay your eyes on; every piece of information about every remarkable organization that you can find out there.

Then you study that information.

You squeeze out every practice; every fact and every approach to problem solving out of that information. You dissect that information and you spend a conscious bit of time and effort doing it. You do it consistently; every single day of your life.

Whatever be the case; once you are done with this post and before you move on with your life; consider this --- if there is one thing that you take back from this book and this section in particular; it is that when you see a genuine builder around you who is getting things done; you need to stop whatever it is that you are doing as a 'manager' and you need to observe the guy.

See him work.

Watch.

And Learn.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog..

I was once told that the difficult part of story telling is when you stop writing and the story starts writing itself. That isn't really the difficult part of story telling. What I have learnt with this book is that the difficult part of story telling is not just letting the story write itself; but wrapping things up brining them to a graceful end when the story is really busy writing itself.

Yes; there is a lot more to be said about building remarkable work and play environments. We can sit here all day and talk about all the specifics of creating an amazing work and play environment and then you can go out there in the real world and realize that every single problem that you face at your work environment is not even close to the problems that you read in this book.

Or you could spend years of your life as a manager; sixteen hours a day; trying to build an environment that absolutely rocks and then one fine morning be told that even the best of your builders aren't even remotely happy in the environment you've built for them.

This is probably not because you went wrong with or were inattentive to every minute detail that this book talked about.

It is probably because of the simple cardinal fact of life --- where there are people; shit happens.

No; seriously. Before you snicker and smile at that statement harp on its reality a bit.

Human beings by their very nature are complicated creatures moved by different motivations.

The story of a seriously interesting builder who supposedly loved working at Multiplitaxion Inc, comes to mind. The guy was a decently good builder who was pretty good at the craft of getting things done. We had given him all the tools he needed to get things done; got out of his way; gotten him salary hikes; promotions and big fat bonuses.

When the guy left he was in serious need of more funds and a higher salary. Understandable. What was not understandable however; was that as soon as he found a better job offer; he admitted having written two really long and interesting anonymous emails. One consisted of blatant, non-constructive criticism about the organization and how it was a pathetic organization to work for. The other was a blatant criticism for 'the man' who worked for the organization.

We read the emails with a meticulous eye; looking for any piece of constructive criticism that we could pounce on and improve the overall work environment. I even went so far as assuming that he referred to me when he talked about 'the man' and tried to read the email with an objective eye looking for anything where the organization or I; as a manager; could go out there and improve myself.

As far as constructive criticism was concerned - there was none of it.

'Multiplitaxion Inc, was too materialistic to give out employee loans and advance salary to their older loyal employees' --- the email read.

As a matter of policy we did not give employee loans and salary advances back then. Everyone knew it. It was common knowledge.

'The man who works for the organization does not not even like listening to music' --- the email read.

Well as a matter of fact, there were quite a few of us who found the idea of listening to loud music while programming a little distracting. We preferred people used their headphones. We even went all the way; had the organization buy these headphones and gave them out to the music lovers absolutely free of charge.

After reading the emails over and over for a couple of times; feeling down for a few minutes; we decided to leave the emails behind and move on with our lives.

There were multiple reasons why we could do that without having to rage a major war with our guilt or consciousness:

As an organization we; at-least most of us; had been just, fair and open about our policies and everyone who stuck around were aware of these policies. Everyone who decided to stick around had made a conscious decision to stick around. None of it was confusion or deception.

As managers; we were all learning and we were working our asses at it; giving our level best to our job which included removing impediments from the way of builders. We were serious about creating environments which were great for serious work and play. Yes; we made our share of mistakes; but we learnt from them; and we survived by moving forward --- consistently.

When we made mistakes; we said sorry; and we fixed things. Obviously; when we got these anonymous emails with no constructive criticism what-so-ever; just whining; it seemed logical to ignore them and move on. There was nothing to say sorry about; nothing to fix. After all; we had an organization and projects to run and we could not afford to let the bozos get us down.

It is probably floating around in emails trails somewhere. This is a fable of a man who about to embark on a journey decides that he wants to carry his old donkey on his back.

Somewhere along the trip the donkey slips into a big mud-hole.

The man spends hours thinking of a way to get the donkey out but finding no rope or help near-by decides to put an end to the old-hurt-donkey's misery by covering the hole with mud and cremating the donkey alive before he moves on.

He takes a bucket full of mud and throws it on the donkey's body.

The donkey shakes it off; and steps on top of the mud.

Bucket after bucket; the man keeps throws the mud on the donkey's body to cremate the donkey live.

Bucket after bucket; the donkey keeps shaking the mud off his body and stepping up on it.

Soon; the hole is covered and the donkey walks out alive.

As funny as narrating this story in a book connected with software development seems; it should actually be taught at management and software development schools across the globe.

Why?

Because if you are trying to build truly remarkable work and play environments or trying to bring about any change in your organizational environment, you have to develop an overall attitude that has uncanny resemblance to the donkey's attitude in the story.

It is going to hurt even more when the people who you were hoping to become your change agents have serious issues with what you are trying to do.

If you want to have any chance of survival in the long run; remember the three very basic; simple rules:

Do 'not' forget the magic word - 'Empathy' - if you lose it you lose everything.

If you genuinely believe in what you are doing; keep doing it consistently; and hope that people will 'see it' and 'get it' sooner or later.

When the criticism comes in; analyze it objectively; see if there is anything you can do to improve yourself and if the criticism was just directed to let you down --- shake it off; get over it and move on; just like the donkey you read about in the story.

Remember; you get just a couple of human beings in a room and shit happens. In a typical organization; you're dealing with quite a few human beings. Having said that; If you remember these three simple rules; improvise and adapt as per these rules; you should go a long way at creating amazing work and play environments.

Of course things will feel shitty at times.

Of course things will feel like nothing is even worth-doing at times.

But stick around and you should be able to build an environment that is different, fun and stands out; despite of all the shit around that happens around you; and then if you are lucky; the shit that happens around you will slowly keep on reducing over time.

Having said that; don't expect all of it to go away completely. It wont. But if you keep showing up; keep doing what you think is the right thing to do; sticking to the three simple rules; you might actually start loving what you do and you might witness change happening. Slowly. Over time.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog..

Memes And Causes - People in a circle are getting together and talking about their project. With their current project or what-ever-it-is-that-they-are-working-on is going to change the world; make a dent in the universe and show the organization that they have been right all along.

An Asshole - Yes; if you are talking about the world of software development; assholes bring more people together than you can think of. You hate Fred; I hate Fred; so lets hate Fred together. Its so much more fun that way. Of-course Fred; could be a manager or an entire organization. As long as we can get together and collectively hate something together we should be good building a circle around that hatred.

At Multiplitaxion Inc; I had the opportunity of working with a senior manager who actually took pride at being the asshole who connected everyone within the organization. In a direct; open; candid; one on one conversation this gentleman told me he knew how everyone in the organization hated him. He said it in a tone which translated almost like saying he knew how he was actually brining everyone together through a common reason; which was the act of hating him.

Foundation For Long Term Work Relationships.

While only one of the managers I have worked will till date; was candid or mature enough to admit this; I have worked with a countless number of managers who at some level or the other; knew they were hated by people around them and actually took pride in the fact; or at-least got a very perverted kick out of it.

Talk to most vice-presidents and CEO's around the world and quite a few of them let whiners and assholes stick around in the organization; because at some level of consciousness or other they are noticing first hand how having these whiners and assholes are bringing teams together. Besides; everyone loves a few whiners in the organization.

If you are trying to create an environment which is fun to work in; and produces genuine innovation for years; here is the bad news however --- the whole idea of hatred for assholes acting as the unifying glue that holds your entire organization does not work in the long run.

Why?

Because problems do not tend to exist forever and when your relationships are based on specific problems; with the problems out of your way; you are pretty much stuck in a rather awkward situation.

Another manager; who for the purposes of this post; we shall refer to as Fred; for example; was a universally hated manager at Multiplitaxion Inc. Fred; single handedly formed the central focus point of many circles and the sheer make-fun-of-Fred-task was a project in itself. It was in fact a way of life which brought groups within the organization together @ the Multiplitaxion Inc, cafeteria.

Then one fine morning; when the sky was blue and the birds were chirping; Fred found a better opportunity and left Multiplitaxion Inc.

Just like that; he wrote a formal it-was-nice-working-with-you-guys email; and disappeared the next week.

You could literally hear the sound of crickets chirping in the cafeteria.

A few younger ones tried continuing the when-Fred-was-here stories even after he was gone.

It seemed to work for a couple of days.

Then that didn't work either.

This is when; over a period of time; I personally witnessed the ends of multiple 'circles' within the organization. People who were intelligent people; spending hours together; were nowhere to be seen together now.

Walk into its cafeteria and Multiplitaxion Inc no longer seemed like the fun and happening place roaring with laughter it had once been.

Builders who had joined forces to sedate this monkey; found nothing to talk about and went their own way.

All you could hear on any given day in the corridors of Multiplitaxion Inc; was the sound of crickets chirping.

If there was one thing this incident taught me; it was that 'circles' that are brought together by true and genuine fun-loving connectors tend to survive for a relatively longer span of time. Circles that are brought together based on the mutual hatred of a particular asshole or a particular organization; do not tend to survive in the long run at all.

The only circles; however; that stand the test of time are circles which are formed out of mutual desire to create meaning. Circles where the objective is to get together and 'build stuff'.

Next time you notice a circle forming around an asshole; try to penetrate it; and give them a cause; a meaning or a bigger arch enemy. That dear reader; is your only chance at forming long lasting 'circles' of genuine builders and not collective-whining-groups.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Virtually every veteran builder that you talk to; tells you the same things about building remarkable stuff. Building stuff is hard; building stuff takes time; building anything means you face a lot of criticism and building stuff requires something that is much more important than just raw talent --- it requires patience and consistency.

The more builders around the world; I observe; the more I am leaning to believe that passion for what you do and flow are two most important reasons which makes builders put in the tremendous amount of patience, slogging and consistency it takes to make the dents in the universe; that they are trying to make in the first place.

The mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Csíkszentmihályi identifies the following nine factors as accompanying an experience of flow:

Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities). Moreover, the challenge level and skill level should both be high.

Concentrating and focusing, a high degree of concentration on a limited field of attention (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).

A loss of the feeling of self-consciousness, the merging of action and awareness.

Distorted sense of time, one's subjective experience of time is altered.

Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).

The activity is intrinsically rewarding, so there is an effortlessness of action.

People become absorbed in their activity, and focus of awareness is narrowed down to the activity itself, action awareness merging.

Not all are needed for flow to be experienced.

The software development world as I know it; dear reader; is composed to only two kinds of human beings --- first kind includes one who have experienced the feeling of being in the flow; other includes those who have not.

During those days; picking up a random problem like creating a shooting game with quick-basic and spending hours at it; day after day; without having the need to concern myself with mundane details regarding like if I was going to paid for what was being built; was a relatively easy way to truly enjoy the journey of building stuff and experiencing flow --- without even knowing what flow was.

It took more than ten years of programming to get a little bit of that same childishness back into my life and to brush against experiencing flow once again.

Today; as someone who toils and labors with his insanely mulish attempts at writing code; posts or anything that is supposed to make really small dents in my very own little universe; dear reader; even I; dear reader; have brushed against the feeling of being in the flow more than once.

If you have; too; dear reader; you know exactly why it makes builders around the world keep craving for more.

If you have not; chances are; that; if keep doing what you absolutely love doing; you will and when you do; you will know exactly what it is all about.

After you have experienced what it feels like to be in the flow for a few times; there is very little you can do; other than fall in love with what you do and continue doing it; day after day.

What are you experiences with getting in the flow?

Does being in the flow frequently make your overall life much more productive and happier?

Do you actually crave the experience every time sit in front of a monitor; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Back in my school-days our school had figured out a brilliant plan to keep every student motivated and build an environment where none of us would create a ruckus. The secret to doing this; as it turns out; was --- badges.

The idea was a simple three step approach:

Break the class into groups of 10 to 12 students.

Call these groups 'houses'.

Make two 'captains' and two vice captains for each house.

If you were talking about a class of thirty students; you were talking of two class captains; two class vice captains; and then there were twelve captains and vice-captains at the house level. Put simply; if you were discussing a class of thirty students you were talking around about sixteen guys who were 'in-charge' of maintaining the discipline. If you did not happen to be in this sixteen; chances were; that you were way too dumb to create a ruckus or make trouble anyways.

As funny as this might sound to you; there were win-win elements attached to this arrangement:

The school loved this arrangement because the smartest, craziest, wildest, funniest, loudest trouble-makers; who make dents in the universe and challenge the status quo; after they leave school; would tow the line and would be spending most of their time getting others in the line till they were in school.

The trouble makers loved it because it gave them a head start at introduction with girls at interschool functions.

Look Around.

Before you snicker at the stupidity of the whole arrangement above or wonder how it would ever work; look around your organization and you will figure out exactly how such a funny sounding stupid arrangement works; not just with young immature teenagers; but even with grown up programmers.

How many "Team leaders" does your organization have?

How many "Module Leaders"?

Vice Presidents?

Directors?

David at 37Signals describes this much more articulately that I will ever be able to describe it. He explains:

The title of vice president must be the most promiscuous of all in corporate America. Everyone seems to be a vice president these days. Some companies having hundreds of them. Are all of these people truly capable of standing in for the president or CEO of the company should it come to that? Are they really just one step below that person?

Of course they’re not. Vice president is mostly an “all title, no lands” concept that serves as a cheap way to make someone feel important without the authority to actually be important. It’s classic over-promise, under-deliver. “You’re oh-so-important, but please fill out this expense authorization report for your laptop”.

Titles are mostly bullshit at the best of times, but “vice president” seems to be bullshit all the time.

Now; go look around how and count how many simple 'engineers' you have in your organization.

Compare that number with all the number of people holding other fancy designations your organization might have.

You might be able to figure out how my school pulled off their funny little gimmick of getting the trouble makers to tow the line.

And Why Do Most Builders Take The Bait And Get Excited?

In my career --- I have been fortunate enough to be able to give promotion letters to quite a few genuine builders. I've seen engineers get promoted from engineers to technical architects; and every time I hand over the promotion letters I see a genuine smile on people's face.

This; dear reader; confused me for months.

For months; I would look at every builder smile when he was promoted; and I would look at them with a blank; confused look.

For months I wondered if every single builder; getting happy at being made fiftieth 'senior' executive in the organization of hundred employees; was an idiot to have taken the fish bait and get all excited?

The answer; dear reader; as it turns out --- is obviously not.

Remember the head-start-with-the-girls-at-interschool-functions part?

That (or something on the same lines) is exactly what is at play here.

Handling Designations

Flashy new designation does not 'exactly' give software developers a head start at conversations with girls at a pub; but it gets them more 'perceived-respect' and a chance at being heard within the organization.

If you have been with me so far; chances are; that I've sold; two simple facts to you:

First; There are tons of useless designations out there; even in your very own organization.

Second; Irrespective of whether you are a builder or a whiner; chances are that you are going to feel a funny pinch of happiness when you are given one of these funny sounding designation.

What you do with this shinning flashy designation of yours; after that funny pinch of happiness wears out; eventually ends up deciding whether you continue to be the competent builder you currently are or you get yourself promoted to your level of incompetence.

And most importantly; do you realize that you are just one of the sixteen captains in a classroom of thirty students?

If you responded with a very confident 'yes' to all of the above questions; you should be just fine with your next flashy promotion.

Go ahead; accept it.

Then; go be the student who is ok accepting with the batch of a vice-captain; and then decides that he wants to continue being the smart, crazy, wild, funny, loud trouble-maker who makes a ruckus anyways.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

At any point of time; in Multiplitaxion Inc; we had multiple teams working on a host of ideas that the business had. Ideas ranging from Accounting for oil-and-gas companies to complex 3D modeling.

Like any other company with a good engineering culture the builders played with tools and technologies. Every now and then they would throw out a sprint based on the a business idea; would pat themselves on their back at a job well done and would go have a blast at a party.

We were one happy team of geeks and builders; getting things done and partying after every deliverable went out the door.

You can look at any phenomenally successful company, and it's pretty obvious that their success was founded on building on something they personally wanted. The extent that any company begins to deviate from this course is the extent to which their ship starts taking on water.

And the key leading indicator that they're getting ready to head off course? You guessed it: it's when they start talking about gathering business requirements.

Because, dude, face it: if it's something you want, then you already know what the requirements are. You don't need to "gather" them. You think about it all the time. You can list the requirements from memory. And usually it's pretty simple.

Problems that the builders passionately connect to; problems that builders understand; problems that are problems in the life of the builders who are working on solving them. Problems that the team passionately wants to eradicate from the surface of planet earth.

If you are a consulting firm; chances are you are knitting your brow and going --- 'But Pops. We have to work on projects from multiple verticals. It's our bread and butter' --- and my answer is simple --- 'by all means; please do; but at the same time see to it that you are giving your builders enough free time to solve problems that they genuinely want to solve'.

If it is a problem worth solving; let your builders take a shot at it.

Chances are; that they might waste a few days at it and nothing might come out of it; or chances are you might have a life changing product in the making right there; but if you never take the chance and never trust your builders; you will never figure out.

There is only one way to find out --- let your builders take a stab at it --- I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Genuine Builders embrace change. They are just as afraid of change as anyone else; but then they indulge in the act of building stuff that makes small and big dents in the universe. They indulge in the act of building stuff that changes things. Hire a couple of genuine builders; let them be your seed engineers and chances are; they will attempt to change just about anything that seems 'safe' in your organization.

Organizations; as it turns out; are often not very comfortable with these sort of huge changes or ideas that bring about these sort of changes.

The arrows are the paths of different ideas. The box in the middle is the organization.

Whenever leaders want more innovation, they typically start by adding more inputs into the process. They seek out more ideas. Hey, lets brainstorm! Or maybe we should crowdsource! Or how about getting everyone to mindmap!

Executives often do this flinchy sort of thing and it’s big news at many corporations to start “idea programs” to encourage people to submit ideas.

These programs are launched, ideas are submitted, and there is much rejoicing.

But little change.

The reason there is little change is that idea inputs were never the problem. The bottleneck was further upstream. Crowdsourcing, brainstorming, mindmapping, and the dozens of other techniques people obsess about help create early idea volume, but do little to help the curators, the people who winnow down the hundreds of ideas down to dozens, and dozens down to a handful.

It’s much more useful to study where the bottlenecks are, when and why new ideas are killed, and who the people are that are killing them.

As a builder; when you introduce an idea or build stuff that is supposed to make a small or big dent in the universe; you dear reader; are trying to bring about change; which; as it turns out; is not something that is easy to bring about; at-least not in most organizations.

DeMarco and Lester describe this in their book Peopleware while explaining the 'Resistance To Change Continuum' and how it works. According to 'Resistance To Change Continuum' your organization can be composed of the following types of individuals.

Does your organization have skeptics who challenge your ideas in a healthy way or do you often find yourself presenting your ideas to people of every other kind in the 'Resistance To Change Continuum'?

'Not now. By the way; we have an interesting office too; you want to work with us?'

It has been five years since we worked together on a project. Three years since we talked and yet; we talk like we had a fight over a design approach; followed by a long discussion about life in the software development world; yesterday.

The only thing both of us can think of when we meet is trying to get the each other on our team. We are actively attracting each other into our own workplace.

The more I observe builders and story tellers across organizations interacting with each other in conferences; code camps; and even seminars; the more I tend to develop a deeper understand of the reasons why builders who have worked together in the past have a tendency to attract each other.

The Reasons

It is clearly not a conscious stream of thought that a builder is particularly aware of; but when a builder makes an attempt to pull another builder into his team; his mind in indulging in fairly complex reasoning. If you have worked with a genuine builder in one of your past projects; you meet him at the grocery and you feel the need to give him a job offer at your current team or your current organization it might be because of one or more of the following reasons:

Put two builders in a team and you will see difference of opinions; arguments and sometimes even fights. When a genuine builder looks you in the eye and tells you how much your code sucks; you know that in a world where no-one cares about you; he cared enough to look at what you were doing wrong.

It is the looking-after-each-other that often results in looking at each-other.

Look around you; try to think of all the people you have worked with in the past.

How many of them were genuine builders?

How many of them met the three scenarios above when it comes to your professional life?

Chances are; you will be able to think of a selected few individuals; these are your partners in crime.

If they are not working with you; hunt them down and then offer them a job in your team or your organization.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

My first few months at Multiplitaxion Inc were depressing. I was being assigned to every random assignment; ranging from document formatting to reverse engineering. I was working for peanuts; on assignments that no-one else would work on and I was literally slogging.

Floating in the email trails of the organizational mailing list were emails from a genuine builder which would cheer me up. Every once in a while with no reference to the context a message would land up in my mailbox that would have an inspirational proverb:

When the work you do is low and the rewards are few. Remember that the mighty Oak was once a nut like you.

At other times when you received no promotion after a year full of slogging and three successful projects; things would get a little frustrating.

There were moments when I would genuinely wonder if I was wasting my time with an organization that would never be able to understand and utilize my core competencies.

What the 'nerd' in me was doing in difficult times like this can be best described an interesting anecdote one of managers back then told me:

The Olive tree is fairly interesting. For months after planting it you hardly see anything growing. You feel like its growth is slower than practically any other tree out there.

Then something happens --- The tree shoots and grows faster than any other tree.

What the Olive tree is doing during the period of its seemingly slow growth is simple --- it is developing deeper roots that will help it grow really fast when it starts to shoot up.

Besides moving from one task to another without complaining out loud --- An act that was slowly starting to turn me into a one-man-army --- what was also happening in my life during those difficult times was that I was developing deeper organizational roots.

Today; as I observe young but genuine builders-in-the-making function within multiple organizations and grow; the whole idea of continuing to 'show up' consistently and developing deeper roots seems like well formed approach most builders take during their incubation period.

While whiners around the world continue to loop in the infinite loop of failure genuine builders make dents in the universe by settling down; developing deeper roots within the culture chart of the organization and then brining about change.

If you have been reading my advice on building remarkable work and play environments you may have noticed that I have gone all out and have strongly pushed on a lot of different ideas; ranging from hiring all the way to the importance giving out logo-wear.

As I wrote these articles; one question kept coming back --- If there was just one thing that you could do towards building a remarkable work and play environment; when you were starting your organization; what would that one thing be.

The answer; after a lot of soul-searching; observation and research; as it turns out is --- seeds.

Your environment; work-culture; your organizational growth and even the very existence of your team or organization is going to depend on how well are you able to seed it.

What I am talking about here; dear reader; is the selected few you hire to act as 'seed engineers' for your organization.

While I have already talked about the importance of hiring when it comes to building amazing work and play environments; nothing beats the importance of hiring your seed engineers.

Who your seed engineers are will eventually make or break your organization.

Seed Engineers

Your seed engineers are the people who you look at as the 'core' team within your organization. People who don't just build stuff --- but to a large aspect determine both; the engineering culture and culture chart of your team or your organization.

You quite literally think of them as the seed that is going to define both the 'growth' and the 'character' of your organization.

Seed your organization with a bunch of whiners and chances are high that before you know if your organization would be swamped with whiners and moaners. Seed it with some seriously kick-ass engineers and chances are that you will have an environment full of amazing builders. An environment which actually makes the whiners very nervous and keeps them out.

The real question; dear reader; is how do you hire seriously kick-ass seed engineers.

The answer; when is comes to hiring; is that you begin by being --- ruthless.

Let me ask you a brutally honest question: since you began interviewing, how many of the engineers you've voted thumbs-up on (i.e. "hire!"), are engineers you'd personally hire to work with you in your first startup company? Let's say this is a hypothetical company you're going to found someday when you have just a little more financial freedom and a great idea.

I posit that most of you, willing to admit it or not, have a lower bar for your current company than you would for your own personal startup company.

The people you'd want to be in your startup are not of the Smart and Gets Things Done variety.

For your startup (or, applying the recursion, for your new project at your current company), you don't want someone who's "smart". You're not looking for "eager to learn", "picks things up quickly", "proven track record of ramping up fast".

No! Screw that. You want someone who's superhumanly godlike. Someone who can teach you a bunch of stuff. Someone you admire and wish you could emulate, not someone who you think will admire and emulate you.

You want someone who, when you give them a project to research, will come in on Monday and say: "I'm Done, and by the way I improved the existing infrastructure while I was at it."

I am sure a young and budding entrepreneur or manager out there is knitting your brows at Steve's advice and getting all sentimental about the importance of 'niceness' and 'willingness to learn' as he reads this.

Am I; dear reader; suggesting that you take every smart; young and raw talent that walks into your interview room and boot him out of there?

Of-course not.

Go ahead and recruit young raw talent who can act as your seed engineers tomorrow but at the same time; realize the importance of hiring your seed engineers for today.

Put simply; if there is one thing you are going to do to try and build genuinely interesting work and play environments; go out there and hire 'seed engineers' who are smarter; faster and much more talented than you --- people you genuinely admire --- and once you have done that; let these set of genuine builders and story-tellers seed your environment to make it truly remarkable.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

During my early days as a young and budding developer; I was an introvert.

As I grew up and started observing others developers around me; I started seeing more and more developers; some of them who were even veteran heavy-weigh programming champions; being labeled as introverts who basically keep to themselves.

As developers quite a few of us have been or are labeled as 'shy' --- 'introvert' --- and 'quite'. In general; we seem to have an image of pesky programmers who are not very good with people.

I dear reader; am here to tell you that; the whole notion of builders not being very good at communication is one of the biggest myths in the world of software development.

So; during my young and budding days as a developer; I was an introvert.Then somewhere along the line; I developed a keen interest in understanding how the human brain and humans beings in general; work. I got interested in management and entrepreneurship. Because of my interest in these topics the scope of conversations I liked involving myself in; increased and I could suddenly strike comfortable conversations with clients and managers.

It was at this point that I realized that I was never an introvert.

The problem with me was never not-being-good-at-communication or not-being-very-outgoing. The problem with me; like most software developers was that I; like most nerds was just not into small talk.

Your nerd might come off as not liking people. Small talk. Those first awkward five minutes when two people are forced to interact. Small talk is the bane of the nerd’s existence because small talk is a combination of aspects of the world that your nerd hates.

When your nerd is staring at a stranger, all he’s thinking is, “I have no system for understanding this messy person in front of me”. This is where the shy comes from. This is why nerds hate presenting to crowds. The skills to interact with other people are there. They just lack a well-defined system.

In the same article; Michael describes why Nerds are not truly the introverts they are presented to be. He explains:

People are the most interesting content out there. If you’ve got a seriously shy nerd on your hands, try this: ask him how many folks are in his buddy list? How many friends does he have in Facebook? How many folks are following him on Twitter? LiveJournal? My guess is that, collectively, your nerd interacts with ten times more people than you think he does. He can do this because the interaction is via a system he understands — the computer.

Your nerd knows that people are interesting. Just because he can’t look your best friend straight in the eye doesn’t mean he doesn’t want to know what makes her tick, but you need to be the social buffer — the translation layer. You need to find one common thread of interest between your nerd and your friend and then he’ll engage because he will have found relevance.

To be honest; it is not so much about the medium of communication being a well defined system as it is about the very basis of the conversation and small-talk. If you want to understand what I mean; go walk up to a genuine builder deeply submerged in his code and ask him how he was doing or what he thinks about the weather. Chances are the conversation will end even before it begins.

Now wait for a couple of days; and then walk up to the same builder seeking help with refactoring a function you are writing. Chances are; that not only will he fix your function; he will actually spend hours explaining to you why he made the changes he made. Drift the conversation towards whether now; and suddenly you will see this builder that you are talking to also has a strong opinion about whether.

The whole notion that builders are not good at communicating stuff back to the business or their managers is a notion full of a truck load of crap. When you are working with genuine builders what is really most important is the initial connection. Base it on a platform the builder feels at home with and you are in for a deep dive into the builder mind; and there is a lot going on in these minds.

Even if I were to assume that you have what it takes to by-pass committees or the ability to make the difference and that you are willing to rot in meeting rooms so that you can bring about change; if you are working in a cubical-farm; chances are; that radical changes; like your request for a private quite office for every single developer in your organization; are going to come out sounding like a rather funny joke to your management.

Your only ray of hope; at building a genuinely remarkable work and play environment is to begin by demanding; requesting or begging for three basic rooms to be setup within your organization.

War Room

The first time I saw a war room was at a marketing agency for which I was doing a project. The room literally had all four walls made up of whiteboards; which ran from floor to ceiling and had a bean bags.

War-rooms I was told; were common in marketing organizations and yet; I rarely see them in software development firms around the world. In a world; where marketing needs to be baked into what your builders build; and not clumsily glued on as a separate process; even a three year old should understand the importance of having war-rooms in the organizations.

Most vice-presidents; and administration departments; don't understand the importance of war-rooms though. At-least they do not understand it enough to push the idea and get it implemented in their organizations.

If you do not have a formal 'war-room' you are missing out on the opportunity to let people 'fight' over their ideas and let their ideas battle their way into existence. The very fact that you cannot invest enough into a room of this sort; speaks volumes about your lack of commitment to innovation or it just says --- I-do-not-care out loud.

Fun Room

At Multiplitaxion Inc, it took us months to move to a small game room. All we spent on the 'games' was on cheap dart games and a couple of other indoor games which ended up costing us --- peanuts.

People from multiple teams that would hardly have any business to do with each other started flocking together.

Within the first few weeks of the little experiment; Multiplitaxion Inc; saw a major positive outcomes as far as the overall work environment was concerned.

I personally; was fully convinced that an organization which cannot invest a little-bit in 'fun' cannot innovate.

Even till date; I continue to convinced about the importance of having a dedicated 'fun-room' in the organization.

Silence Room

If you cannot have offices for every developer and noisy work environments are what you are stuck with; the least you can do for the sake of some basic innovation; is provide you builders with a silence room within the organization where people who want to 'work together' or involve themselves in 'chit-chat' are strictly not welcome.

Start with a conference room that you might have.

Anyone who wants to focus on something and is sick of the chit-chat can move to this room for a few hours a day.

Use this room as a place where your builders can come when they want to get in the flow without getting disturbed.

If you are doing this right; chances are; that when you do not find your builders in their noisy cubicles; you will know exactly where to find them. They will be in one of these rooms; doing what they do best --- which is to exchange ideas; think; innovate; build stuff and above all; have fun doing all of that.

I do not care what you call these rooms; but if your organization does not even have motivation or dedication to start with three of these rooms to improve the overall work environment; to begin with; chances are that your organization is an army of traditional development sheep; being herd on its way to risky mediocrity; and you are left with only two options --- You can Change Your Organization or Change Your Organization.

Does your organization have one or more of these rooms or at-least an environment that gets you what these three rooms are supposed to get you?

Have these rooms come about from the conscious effort of your organization or have your builders created their own unspoken hideouts to get their work done?

Does your organization play a role is providing all the support at create genuinely remarkable work and play environments or does it just make things worse for its builders by not caring; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

At one of the sales meeting during my work at Multiplitaxion Inc; I am seated across a gentleman; who shall be remained unnamed; but who; for the purposes of this post; we shall refer to as Jack. It turns out; Jack has made millions with this marketing and story-telling skills. Jack; besides talking about his project needs; is also passing on words of wisdom like a wise marketing jedi teaching his young Padawan.

He begins the meeting with an answer to the question which is --- why does he want to invest hundreds of thousands of dollars in a project which is basically what he calls a 'fun-project'.

Even though I do not remember the exact words; he answers the question with a rather interesting answer which leaves a deep impact on me. It is exactly the kind of answer I would expect from someone I was working with.

When asked the question; he answers after a thoughtful pause:

I don't want to spend so much money on this project in anticipation of a huge return. I want spend money on this project because it seems like an interesting problem to solve. I want to work with the right people and I want to have fun doing that.

You know --- I don't know why they do; and I do not even know if I am the right person to be answering this question; but every now and then a few college students ask me how I got so successful in my life and I tell them the only way to get successful is to find something that you are really obsessed with doing. Something that you would absolutely love doing and then doing that for the rest of you life.

There are two benefits to doing this. First is that you absolutely love doing it so you will not get sick or tired of doing it for years (which is what it takes for anything to be successful); second is that because you love doing it, you will probably put in a little bit of an extra effort than everyone around you. That 'extra' is what will set you apart and make you noticeable amongst a crowd.

I can't say I agreed to everything the guy said in that meeting; but as far as these words of wisdom were concerned; they were simple; accurate and right on target. Observe any genuine builder out there and two traits will become rather evident.

Most genuine builders out there have relentless passion and love for what they do. It is this obsession that makes consistency; which is otherwise a very hard quality; relatively and possibly easy to achieve.

It is the same relentless passion and obsession for what they do that keeps gently nudging genuine builders to strive for more and put in a 'little bit of extra' in everything they build.

A Little Extra

When it comes to software development we all know how easy it is to be ninety percent done. It is completing the other ten percent with class that separates veteran builders from wannabes. It is all about putting in that little-bit-of-an-extra-effort and giving that little-bit-of-an-extra-touch.

At Multiplitaxion Inc; we had a truck-load of serious issues. Starting from the BDUF model for software development to a complicated hierarchal organizational chart where your manager could probably screw you really badly for no particular rhyme or reason; if he felt like doing so. Everywhere you looked; there were issues and problems.

Quite a bit of builders I knew personally had complained initially and had then moved into hibernation.

Even some of the super-heroes were down; lost and tired of trying.

Then something happened.

Random people --- including the whiners --- started quitting.

Loads of them.

New people started joining in.

A couple of us started working without a truck-load of documentation and started using light-weight processes scrum to produce results which; compared to the results that were being produced by a couple of other teams; were --- lets just say --- noticeable.

People higher up in the organization took notice; listened and helped us spread the culture across the organization.

We moved from half-baked-multi-layered-official-email-based-announcements to transparency within the corridors of the organization.

When we were on the path where we always wanted to be --- we patted ourselves on the back. The world was going to be a great place to live in; the sky was going to be blue and the birds were going to hum sweet songs now.

We Just Rubbed Someone The Wrong Way.

We had just about started patting ourselves on our backs. It was then that; running in the corridors of Multiplitaxion Inc I heard a builder; who for the purposes of this post we shall refer to as Jack; whining about the fact that we had gone way too transparent and he did not like the transparency. Jack felt we had lost the 'sophistication' that we once had.

Of all the things here a few things about this feedback that would make you feel completely and totally --- weird:

The feedback was not a direct candid feedback. For days it floated around the corridors of Multiplitaxion Inc much the moans of whiners float around for days; spreading dissatisfaction and lowering the general happiness.

The feedback was not objective about things that could be changed. It involved random criticism about the organization; the management; the marketing and every other department this person could lay his hands on.

The person made a full-time job out of spreading his very own personal dissatisfaction within the corridors of the organization.

What was even more disappointing about the whole episode was the feedback was coming from a genuine builder who was decently good at what he did.

To top off all of this what made the whole episode even more worse; as I observed it unfold; was the fact that the same individual had actually complained and whined about the excessive use of BDUF processes and lack of transparency a couple of years ago.

Love It Or Leave It.

If you are running an organization; and if there is one thing you need to be very careful about; this poster describes it rather articulately.

Genuine builders; will have gripes about things that they do not like in the overall environment. Genuine builders will also be usually fairly vocal in expressing their concerns; but genuine builders do not make it their full time job to whine; bitch and passionately hate their organizations. They begin by expressing their concerns; becoming vocal; hibernating; getting disconnect and then if things still do not change --- they leave.

When you have an isolated team member; whining and making a full time job out of spreading his unhappiness it is time to cut straight through the bone; look at the gentleman in the eye; confront the issue instead of ignoring it and present him with a love-it-or-leave-it option.

Remember; you cannot please everyone and every now and then you are bound to come across some whiners you can never please irrespective of what you or your organization does. The sooner your organization presents the love-us-or-leave-us option to these whiners the better off you work environment will be.

How many whiners who passionately hate their organizations have you met or worked with?

How many of them; instead of having a spine to bring up the problem; hibernating or leaving; continued to bitch; whine and moan in hush-hush mode within the corridors of the organization?

Have you ever presented a whiner with love-it-or-leave-it option in clear terms; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

During its glorious days; Multiplitaxion Inc; was giving out amazing logo-wear --- T-shirts; pens; mugs; watches; clocks and toys. As an organization it was interestingly popular when it came to free logo-wear given out to employees.

Irrespective of who you were; if you worked at Multiplitaxion Inc; there was always enough logo-wear going around and you could grab some too.

Then as we 'grew' in terms of team-sizes and number of employees; something funny happened.

The concept of giving out logo-wear stopped all-together. All of a sudden you could not get any logo-wear --- even if you wanted to buy it.

All logo-wear just disappeared out of the organization.

Not many missed the logo-wear though. Interestingly; however; the few who missed these logo-wear items had one thing in common. They were genuine builders deeply connected to the organization and their projects.

Every single one of them.

The incident was an interesting insight into what alpha-geeks and genuine builders expect out of their organization when it comes to logo-wear and toys.

There Is Something About Logo-Wear.

The whole-logo-wear-not-being-available-within-the-organization-incident happened slowly; but even months after the culture of giving logo-wear had completely stopped; every now and then some of us would talk about the good old days when there was always some logo-wear with cool slogans and wordings on it.

The cost of these swags in terms of monetary value --- peanuts.

Yet there was something about cool company T-Shirts and logo-wear that was causing the genuine builders to go bonkers and drool over cool logo-wear.

Why?

Because having amazing logo-wear which you can, carry, wear or use says a lot of about the organization that gives it out.

Amazing; wild; funny; crazy or down-right-hilarious; the logo-wear your organization gives out; to a large extent; is a reflection of your organizations attitude and personality.

If you organization has no logo-wear; it has no personality.

Logo-Wear Allows Builders To Be Loud.

As developers we are much more comfortable talking to the compiler than we are comfortable talking to human beings. We are usually not very loud when it comes to marketing ourselves or our organizations.

Go compare the number of posts on Power-shell that are out there and with the number of posts where developers are talking about how much they love their current organization. If you have done your Google searches correctly chances are --- you will find that not a whole lot of developers are talking about how much they like their current organization.

There are three reasons why the post count of how much developers like their current organization is so low:

The ones who genuinely love their organization would rather talk about the work that they are doing in their organization.

As programmers we are usually not very loud of vocal when it comes to complaining or talking highly about the organizations we work for.

While you cannot address the first point by giving out logo-wear; it does help programmers and builders who are quite for the second or third reason to go out there and spread the word about their organization.

A Natural Extension Of Being In A Vibrant Tribe And Flaunting It.

More often than not; Tribes work by exclusion. If everyone can be a part of it; your tribe probably isn't interesting enough to join in the first place. You have built a remarkable work and play environment --- now it is time to give your builders a chance to flaunt the fact that they belong to rare tribe through remarkable logo-wear that grabs attention and makes non tribe members go wow.

If you genuinely believe your organization picks the best of the best; allow the best you have picked to flaunt the fact that they belong to a rather rare tribe.

Logo-wear is a natural extension of being in a vibrant tribe; being able to flaunt the fact that you belong to such a tribe; and use 'exclusion' to spread the word about your tribe or organization's personality so that you can nudge other smart builders to join the tribe too.

Logo-Wear Is Fun.

If all the above reasons do not make sense to you --- this one should.

Everything about Logo-wear is fun.

Designing it; getting it; wearing or using it; giving it out to your team members; all of it is fun. If you organization does not have logo-wear you might be missing out on a whole lot of this fun.

Most genuine software developers out there; are in it; for fun. Most genuine builders notice little things and small things like your business card or logo-wear can have long lasting impacts on your overall organizational environment.

If You Cannot Give It Out The Least You Can Do Is Sell It.

Early on in my career I spent some time in the Microsoft campus. One of the things that I liked about my stay there was that there was quite a bit of free-logo-wear and toys that we received. Apart from that the premise had a special store which sold logo-wear at discounted rate if you wanted to buy more logo-wear than what you were given for free.

At the end of the day; your employees are doing you a favor by wearing your logo-wear and spreading the word about your organization around. If they are genuinely connected to your organization they might even go out there and buy the logo-wear; the least you can do --- is make it available to them when they want to buy it.

The more I look at organizations out there; the more I continue to be amazed by the number of organization that do not even have a decent logo-wear based T-shirt. Quite a few organizations actually have pretty amazing logo-wear but you get some once a year and there is no way for you to get or buy more.

Not having logo-wear or not making is readily accessible to your employees shouts out loud that your organization lacks the passion; the commitment and the zeal to form tribes of truly connected employees.

Remember; logo-wear will not take a screwed up environment and fix it.

They are much like an icing on the cake that is already well baked and delicious. Having said that; I am yet to meet one builder who does not like this icing on the cake of his professional life.

Now go print some T-shirts.

Go figure out how you will make them accessible to your employees or team.

Does Your Organization have Logo-wear you feel good about using?

Does Your Organization give or sell the logo-wear and make the logo-ware readily accessible to you when you need it?

How strongly do you feel about logo-wear and it's impact on how the employees feel about the organization in general; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

As I hopped from meeting room to meeting room there were three things that I learnt about meeting rooms:

Located next to every meeting room are other meeting rooms.

Other than meetings; these rooms are often occupied by teams of software developments indulging themselves in an insanely stupid act; which they refer to as --- 'working together'.

Human being are social animals and when they 'work together' they tend to talk about their wife and their life much more than they talk about their code.

Every now and then I would have a bunch of developers 'working together' in the meeting room next to the one where I was hiding to get my work done.

By 'working together' in a meeting room; I do not mean the regular five minute standup. I also do not mean the famously stupid three hour meeting. These guys were in an insanely fu@#ked up self-organized meeting; eight hours a day; five days a week conducted under the name of 'working together'.

In this eight hour meeting; multiple things ranging from favorite movies of individuals; to what a variable should be called; could be brought up and discussed at length. Somewhere in the middle when when people were tired of discussions and wanted to take a break; the talking stopped. That is when people tried to write some code.

Of-course this was not a real meeting.

These were a bunch of developers taking the initiative of 'working together' --- so everyone actually liked it and encouraged it.

Of all the discussions that happened; one of the discussion that was brought up every now and then was why their project was slow and how it could be speeded up.

Shut the F@#k up and do some work.

To be honest; and candid; any computer science graduate; fresh out of college would have told him why their project was slow and what they could do to speed it up.

What they had to do to speed it up was something rather simple.

They had to --- shut the f@#ck up and work.

Coming from someone like me; who encourages flocking and a strong bonding in a team; asking developers; who sit in the same room and work; to shut up; go to their cubicles and work in their own cubical might sound like contradictory statement; but it is not.

As developers every single one of us needs two fundamental things from our work environments. On one hand we have a strong urge to 'belong'. Put simply this is what Seth Godin describes as building tribes. On the other hand however; what we also need as developers is quite time where we think; reflect; exercise our brains and try to solve really complicated problems by simplifying them.

If you are building a genuinely remarkable work play environment; it is your responsibility to provide your team both of these. Taking your team out to lunch; project dinners; and having x-boxes in offices is important. I have even gone ahead and suggested the nine-ten rule.

Having said that what is also important is that your team members get quite working environments and are mature enough to realize that while parties; games; chats in cafeteria; brainstorming sessions and whiteboard sessions are important; at times it is also important to shut the f@#k up and do some work alone.

Now; stop the chit-chat; go to your cabin; try to focus in a quite environment and do some real work.

Seriously.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The Lame Whiner; who for the purposes of this post we shall refer to as Fred; is at my desk wondering if Multiplitaxion Inc, has signed up any new short term consultancy projects or will be signing up any new ones in the recent future.

I cringe.

Watching Fred at my desk means that he is going to spend a good half hour talking about why Multiplitaxion Inc, should sign up new short-term consultancy projects. Then he is going to cry like a baby.

He is going to cry like his career; his life and his universe depends on Multiplitaxion Inc, signing up new projects.

He equates new and more short-term-consulting projects to 'growth' and wants to work on something 'billable'.

Long story short; he is not happy --- and he is out to spread the viral-dissatisfaction to anyone who has time to listen to him whining.

The lame whiner looks up to his organization, his client, his colleges and everyone else to make dents in his very own personal little programming universe.

He lacks participation; but seeks opportunity on a golden platter; nicely laid out --- just for him.

The Problem With Whining About Your 'Circumstances'

Hidden deep down in the archives of Joel Spolsky is a discussion where Joel nails the essence of whining about every little 'excuse' for not making a dent in the universe. Joel talks about the problem with whining; finding lame excuses for your being a mediocre-replaceable-developer and then quitting. While answering one such question about quitting he explains:

Although the tech industry is not immune, programming jobs are not really being impacted. Yes, there are fewer openings, but there are still openings (see my job board for evidence). I still haven't met a great programmer who doesn't have a job. I still can't fill all the openings at my company.

Our pay is great. There's no other career except Wall Street that regularly pays kids $75,000 right out of school, and where so many people make six figures salaries for long careers with just a bachelors degree. There's no other career where you come to work every day and get to invent, design, and engineer the way the future will work.

Despite the occasional idiot bosses and workplaces that forbid you from putting up dilbert cartoons on your cubicle walls, there's no other industry where workers are treated so well. Jesus you're spoiled, people. Do you know how many people in America go to jobs where you need permission to go to the bathroom?

Stop the whining, already. Programming is a fantastic career. Most programmers would love to do it even if they didn't get paid. How many people get to do what they love and get paid for it? 2%? 5%?

If you read between the lines; it is not difficult to understand that what Joel is doing here is giving tough-love to his fellow programmers; and nudging them on the side of righteousness.

It is easy to whine about your organization; your manager; outsourcing; recession; or stupidity that surrounds our industry in general and blame one or more of these external factors for your inability to build anything interesting.

It is easy. It is convenient; and if you get your whining-act right; you can even get away with it.

However; there is just one little problem --- it is your first step at becoming what we officially call a --- whiner.

Time To Look At The Mirror

The next time you whine about not being on a billable project or not having enough work to do; get up and go for a walk to a rest-room or any place that has a mirror; once there; look at the mirror really hard.

Staring right at you will be the person responsible for your inability to build or get involved with something genuinely interesting.

If you are genuinely dependent on your organization for giving you quality work --- and are lost when it does not; you are just one of the flock of sheep waiting to be herd.

Have you seen whiners getting lost, confused, scared and not know what to work on when they are on the bench for just a couple of weeks?

Have you witnessed whiners seeking 'opportunities' out of their projects, organization or managers and when then citing that as an excuse for not building anything; when they do not get their dream jobs, dream projects and dream managers?

Have you ever arrived at office; morning after morning; only to see Fred whining at your desk; telling you long winded stories about how his organization is hindering his progress?

Early on in my days as a young and budding developer at Multiplitaxion Inc; I heard a very mature individual talk about the philosophy of basketball and how that wisdom maps to software development teams.

His observation about the game was rather interesting:

When you are playing with a team size of five you need every player to score.

I've always advised young and budding managers roll their sleeves and continue writing some code. Scoring constant goals yourself is your only chance at keeping a team of genuine builders motivated and gently nudging everyone in your team to score too.

I've observed countless builders and story-tellers around the world and in all these years of observing them I am yet to find one genuine builder or story-teller who doesn't roll his sleeve and gets down to some real work himself.

Having said that; I continue to be amazed and surprised at how difficult most organizations make it for a builder; with just a few years experience; to continue remaining a genuine builder. James McGovern in his post on this topic; explains the issue rather articulately:

Being an architect in a large enterprise, the biggest challenge for most architects is in staying technical and grounded in reality. It is way too easy to become a buzzword parrot where one spends more time thinking of cool phrases that otherwise have empty meaning over focusing on producing credible architectures with integrity. I find it fascinating that we talk about business/IT alignment, cost reduction and other reasonable practices yet no one is asking the more difficult questions.

How can a business be successful in the use of technology if the vast majority of team members especially within IT don't understand it? I bet you work with teams that have one technical person, in the midst of various managers and other “developers” (usually off-shore) and find that one technical person does a majority of the work, takes the blame for the failures (of himself and/or others), yet is rarely credited for success. How come competent developers put up with nonsense and continue to take the rapings?

Should developers challenge their managers to look at their shiny, gold plated project plans that adhere to CMMI level 13, ITIL, Agile, garbage 2.0 and other worst practices and find a single item that someone else could take more than 10% credit for? At the end of the day, the vast majority of projects either still succeed or fail based on heroics. Sadly, we have realized that heroics are not the way an organization should be run, so instead of working on repeatable, sustainable practices for software development, we have morphed into repeatable, sustainable ways of doing perception management and throwing developers under the bus.

I am proud to say that none of my reviews in the last ten years have ever had a single negative comment regarding my ability to deliver high quality work, in a timely manner and within budget. Much of the feedback is based on perception management.

The thing I think about almost daily is how I can live up to a high standard not because of just personal motivation but because others are watching. This is the essence of leadership.

I don't want to be a manager nor should others be forced to report to one.

Early on in my career at Multiplitaxion Inc we ended up with a situation that was not planned. It was completely co-incidental; but then; having said that; the happening of the situation resulted in an observation that taught me the deep dark secret of management.

Smack in the middle of multiple projects; Multiplitaxion Inc; realized that a few of its managers were not working out well and got rid of them. Panic stuck and other managers; left on their own. In about three months since the firings happened; Multiplitaxion Inc; was a 'zero manager' company.

When I say 'zero-manager' I mean literally a zero-manager company. There was no-one in office who had a business card with the word 'manager' on it --- except one Quality Assurance Manager who was an amazing guy doing some serious hands-on testing himself. Given his way of leading a team; he had recently been promoted to the designation of a manager. People; including his own team; hardly knew the fact that his business card included the word 'manager'.

Other than this Quality-Assurance-Manager of ours; who continued to be a very technical-hands-on manager; developers at Multiplitaxion Inc, woke up one fine morning and literally discovered that all their 'managers' were gone. Just like that.

Any guesses on what happened when they realized that they suddenly had no managers?

The answer is what each one of us; as programmers; developers; builders or story tellers know deep down inside; but are too afraid to discuss or even say it out loud --- what happened is that the developers became much more effective and productive at what they were doing.

Things; dear reader; started getting done.

Am I saying that you go on a firing spree and fire all managers in your organization?

Of-course not.

Having said that; if you; dear reader; are a manager; try to see to it that when folks walk into your office wanting to discuss a problem; your monitor has a code-window open and not a Microsoft Project Plan.

You can only motivate a team of genuine builders by building stuff and scoring goals --- consistently.

Remember; Builders lead by inspiring others to build stuff; not by managing them; and the easiest way to inspire others to build stuff is to build remarkable stuff yourself.

Now; dear manager; close that project plan of yours; open the integrated-development-environment and start talking the language the rest of the builders and story-tellers in your organization are talking.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Throughout the interview Fred takes great pride and speaks at length when asked to discuss his success stories but but behaves like he has been put on spot and asked things he cannot answer when asked about his failures.

After taking over a few hundred interviews and observing countless genuine builders at work if there one thing I have learnt about genuine builders who make small or big dents in our universe; it is that they --- fail.

They fail all the time.

Genuine builders do not think of themselves as seriously kick-ass-rock-stars who can churn out zero defect code every time they are asked to. Most genuine builders indulge in decent amount of soul-searching; and have some a decent level of self loathing for themselves.

Most genuine builders aren't ashamed to openly discuss; analyze and learn from their failures.

"I've missed more than 9,000 shots in my career. I've lost almost 300 games. 26 times I've been trusted to take the game winning shot and missed. I've failed over and over and over again in my life. And that is why I succeed." - Michael Jordan

If you're lucky, however, your family encourages you to fail early and often. If you're really lucky your teachers do as well. It takes a lot of courage to fight against this, but the rewards are great. Learning doesn't happen from failure itself but rather from analyzing the failure, making a change, and then trying again.

Over time this gives you a deep understanding of the problem domain (be that programming or combining colors or whatever) - you are learning.

Exercising your brain is good in its own right ("That which is not exercised atrophies", my trainer likes to say), plus this knowledge improves your chances at functioning successfully in new situations.

Has it been a very long time since you last failed?

If you answered that question with a 'yes' --- you need to find a problem bigger than what you are currently working on.

During our early days at Multiplitaxion Inc some of us got a little excited about our work-culture and thought of taking it to the next level by introducing a little bit of a 'Google effect' to our very own work environment.

We tried to strive for an independent 'budget' that could be allocated to each project manger to use as he sees fit. Like all beautiful ideas, the concept was simple, pure and clean at it's very core. Every month, team leaders would get a certain budget which they could use to boost the morale of their team in whatever way they see fit.

Ways in which you could use it could include:

Buying gifts for top performers and genuine rock-star builders.

Organizing project parties.

Buying a X-Box for the team so that they could kick some alien-ass if they were tired of coding.

I could probably go on with that list forever but I am hoping; dear reader; that you get the general idea.

The idea would also allow us to see how teams of genuine builders like to have fun; instead of taking them to a party and then 'hoping' that they enjoyed themselves when the dinner was over.

Lets Shit-Can The Shitty Empowerment Idea.

So a bunch of young and budding managers; me included; conceived the whole idea of this independent; 'fun-budget'. Three weeks later; we were sorry we had anything to do with the idea.

We were rotting in meeting hell and attending one meeting after another where we were answering what the basic idea of this 'fun-budget' was; what the scope of the budget was; what were the kind of expenses it was supposed to cover and what were the kind of expenses it was not supposed to cover.

After three months of conversations; the idea was finally approved.

Here are the specifics of the approval --- As managers each one of us were now allocated with three-dollars-per-team-member-per-month with which we were free to increase the team morale and make the environment (and the world) a better place to live in.

If you still did not get the ironic-humor in this; dear reader; allow me to explain. What this effectively meant was that if you had a team of five developers you had a full fifteen dollars a month to treat them, give them iPods, T-Shirts, organize project parities for them or even get your team a common X-Box.

None of us talked about the 'budget' after that day.

The budget that was allocated to us was never used and we decided to shit-can the idea.

Fun Is Serious Stuff --- And It Is Not Cheap Either.

The awesome part about being in a kickass team is that you do not need a lot of organizational funding to build great relationships with team members. Leave a kickass team of genuine builders and story tellers alone and they will attract other builders and story tellers.

Get enough insane trouble makers or rule breakers in your team and they will find out ways to have fun --- with or without the organization's involvement.

The interesting thing about hiring intelligent people is that even if they are not very articulate and expressive about what they see, observe and realize most of them understand the organization at a level that is much deeper than their managers even think they understand. So when the once hyped up morale budget was shit-canned by us; no-one in the team talked about it.

Everyone understood.

We just decided to forget it almost like failed childhood ambition.

Even though we lacked words to explain what had gone wrong with the overall idea; everyone in the team; including the junior most engineer who knew about the idea; understood exactly what had gone wrong with the idea.

What this incident really did was teach me the level of importance most organizations out there give to the idea of 'fun' in the work environment. Some of the best organizations out there might spend hours talking about the idea of creating 'fun-filled' environments but talk about expenses associated with 'fun' and chances are that you might hear the sound of crickets chirping.

Fun Is Not Very Expensive Either - The Nine Ten Rule.

"So Pops; are you by any chance suggesting that we spend millions creating a fun work environment" - you frown.

What I really learnt from the whole 'fun-budget-episode' at Multiplitaxion Inc, was that there is a price associated with creating remarkable fun filled environments. It does not come cheap.

Having said that is it not the Hollywood-Dream that most organizations discard as unachievable.

Happy builders; build more and if you have spent enough time and energy at hiring the right people for the right job; chances are that with the fun element thrown in; your team of nine; will be much more productive than a team of ten mediocre programmers.

I don't know about you; dear reader; but I would rather have nine really happy tribe members over ten unsatisfied grumbling disconnected average employees.

At Multiplitaxion Inc; we were a closely knit team; having fun; meeting on weekends; going out together; but the passionate idea of adding fun to the overall 'organizational' environment was just not there.

With three-dollars-per-employee-per-month; we had seen; first hand; how seriously Multiplitaxion Inc; took the idea of 'fun' --- and having seen that first hand --- when it came to having fun at an 'organizational' level --- we hibernated.

What Fred is indulging in right now; can be otherwise referred to as a 'skip'. Put very simply; skip --- is a time when you decide to stop reporting to your boss and 'skip up' to your boss's boss.

Whether you are a manager or a young and budding engineer; chances are that you have either used 'skips' or have witnessed a couple of skips being used in your professional life.

Who has the ability to exercise 'skips' in your organization; to a large extent; will eventually define the whiner to builder ratio that ultimately prevails in your organization.

Positive Skips

During my young and budding days as an engineer at Multiplitaxion Inc; we worked on countless weekends and late nights for more than a year; only to discover when the year ended that no-one other than our reporting manager knew what we were working on. Turns out; this young and budding manager of ours had a history for quietly absorbing every single drop of credit without passing a single iota of it over to anyone in the team.

Months later; me along with a couple of engineers decided to exercise the 'skip' when our manager was out on vacation.

We slogged countless hours to finish a project three weeks before it's finish date; purely because we wanted to send the completion email before our manager returned from his vacation. Doing that allowed us to strike a conversation with a technical director of the organization and open up a new communication channel that did not exist before.

Put simply; it allowed us to ship; and show rather evidently; that we actually functioned better as a team without this manager of ours.

It worked.

Within weeks we had a lot more flexibility of taking decisions; dropping features and doing what worked best for the product.

If I can think of the number of times I've exercised a skip in my; I would consider skips as 'isolated' and a rather rare events in my life. If I'm reporting to you; the only quality I expect out of you; for me not to even think about exercising a skip is --- empathy.

Unless you are a downright asshole; skips are off-limits in my professional life.

However; If you are an asshole and if you give me an opportunity to exercise a skip --- I will.

Negative Skips

Today; every once in a while I see a young and budding engineer like Fred; trying to exercise a 'skip' on his manager. Skips; which were a rare incident; and a rather powerful tool in the hands of builders when we were growing up as young and budding engineers seems to have transformed into a tool to jump up to the next level for ambitious but incapable programmers in the software development world of today.

I've seen:

A young and budding engineer take a shot at estimation where he was merely a part of an email alias that was CC'ed when a vice-president asked a technical architect to do the estimation. Turns out; the architect was off for a day and this young and budding engineer couldn't resist sending a 3x higher man-hour estimate only to make a fool of himself.

A young and budding developer gate crash into a Vice President's room to introduce himself and talk about what he was working on; only to find out that his manager had already kept the vice-president well informed about the great job this developer was doing.

A young and budding developer seeking help and advice from a technical director ever time he had any difficulties with an implementation; only to be gently requested by the technical director that it would be good if he asked his team lead before he approached someone else.

Handling Skips

If you manage managers; or team leads; chances are that every once in a while you will see someone attempting a 'skip'. Which skips you entertain and which ones you do not; will eventually decide who thrives in your organization --- builders or whiners.

Not entertaining a positive skip of a genuine builder is seeking due credit and recognition for his work can have long term catastrophic effects on your organization or your team.

I cannot give you rules to help you decide which skips you should entertain and which you do not; but every time I see a manager exploiting his team; I feel like gently nudging a member or two to exercise a 'skip'.

Every time I see a Fred; who isn't seriously a kickass builder himself; trying to exercise a 'skip' on his capable manager; by giving me details of every single line of code he wrote --- I cringe.

Skips are powerful tools; use them wisely and teach your team to use them wisely.

How many examples of skips have you seen in your professional life?

How many of them have been positive and how many of them have been negative?

Have you ever felt the need to exercise a skip yourself; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

You've hired a young and budding engineer and made him a part of team of genuine builders.

This young and budding engineer; who for the purposes of this post we shall refer to as Jack; is serious raw talent --- gold waiting to be polished. He is working hard; putting his sweat and mind to what he does.

You are starting to feel a little proud of your pick; the rate at which he is growing within your own team and your organization.

Then; something creepy happens.

Things change as far as Jack is concerned.

Not the quality of his work.

The quality of his work is just fine.

He is still amazing as far as his work is concerned; but hidden admist the layers of complicated human behavior; you find that Jack has suddenly lost the innocence and the X-Factor that made him a rock star in the first place.

Slow subtle chances are becoming noticeable.

You are starting to see Jack have minor issues with people in his team.

Ego-tussles; really small ones --- sometimes with other developers; sometimes with with the office administration and HR guys.

An email or two where he criticizes and demolishes someone in his project team for their mistakes in front of everyone else.

The reasons could be numerous; but Jack; dear reader; is taking his first steps baby-steps to becoming a fully-qualified-asshole.

Professional Puberty.

Personally; I like prefer calling this process -- Jacks-Professional-Puberty.

Much like puberty --- professional puberty is process when a lot of confusing changes happen to people.

Take Jack's case; for example. During his professional-puberty Jack is delivering; he is becoming successful and to add to it; he is starting to get a sense that he is 'important' without having any true idea of the level of his importance in the larger scheme of things.

Professional puberty is a hard time; that most engineers or veteran engineers go through in their lives. Most people act really stupidly in this phase of their time. Even I did.

Here is the sorry part however --- a very few of us who go through the phases of professional puberty emerge as better human beings. Most others; turn into regular assholes and pricks that flock our world under fancy titles and designations.

Asshole Not Allowed.

How your environment deals with someone who is going through their professional puberty will to a large extent define the kind of culture that eventually prevails at your workplace.

When a young and budding engineer takes his first step on the path of prickdom do you have veteran builders who can confront the issue head-on or does your organization avoid the issue; hoping that the issue will fix itself?

Does your environment have experienced veteran builders who can help Jack grow out of his professional-puberty into a better human being?

Does your environment have builders who are experienced and strong enough when it comes to getting straight to the bone and explaining the No-Asshole-Rule to Jack in terms which are simple and clear.

If change in attitude not happening after continuous efforts; is your organization; strong enough to pay the price and gently nudge Jack out of the organization; or does your organization take the safe-mediocre path of tolerating assholes just because they are rock-stars at what they do; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Idea man is bubbling with ideas that he 'thinks' your clients 'must have'.

Idea man understands the culture chart and knows the people high up in the pecking order well enough to pull a few strings and get his ideas of '(not so) nice to have' features or suggestions magically transformed into 'must have' requirements overnight.

Now; the idea man might work with multiple motives; some of which include:

My first assignment at my first job was working at Microsoft, where I was told to come up with a new macro language strategy for Excel. Pretty soon, I had the first draft of the "Excel Basic" spec (which later evolved into Visual Basic for Applications, but that's another story). Somehow, this mysterious group of people at Microsoft called the "Application Architecture" group got wind of my spec, which must have concerned them, because for some reason they thought that they were in charge of things like macro language strategies, and they asked to see my spec.

I asked around. Who's the Application Architecture group? Nobody seemed to think they were very serious. It turns out that they were a group of just four people, recent hires with PhDs (very unusual for Microsoft). I sent them a copy of my spec and went to meet them, in case they had something interesting to say.

"Blah blah!" said one of them. "Blah blah blah, blah blah blah!" said another. I don't think they quite had anything interesting to say. They were very enamored of the idea of sub-classing and sort of thought that people making macros in Excel wanted to subclass a lot of things. In any case, one of the fellows said, "Well, this is all very interesting. What's next? Who has to approve your spec?"

I laughed. Even though I had only been at Microsoft for a few months, I knew that there was no such thing as somebody approving my spec.

This seemed to piss off a guy named Greg Whitten who headed up the App Architecture group. Now, Greg was something like Microsoft employee number 6. He had been around forever; nobody could quite point to anything he had done but apparently he had lunch with Bill Gates a lot and GW-BASIC was named after him.

Greg called a BIG MEETING and proceeded to complain about how the Excel team (meaning me) was screwing up the macro strategy. We pressured him to come up with some specific reasons but his arguments just weren't convincing. I thought it was nice that here I was, a new hire pipsqueak right out of college, arguing with employee number 6 and apparently winning the argument. (Can you imagine that happening at a Grey Flannel Suit company?)

My programming team, headed by Ben Waldman (now a VP at Microsoft) backed me up completely, which was all that really mattered, because the programming team wrote the code and thus had the final say on how things got done.

Joel effectively goes on to describe what made Microsoft a special environment to work at in the very same story:

I was sitting at lunch with some coworkers, in the Redmond sun, when Pete Higgins came up to me. At that time Pete was the general manager for Office -- I knew who he was, of course, but didn't expect that he knew me very well.

"How's it going, Joel?" he asked. "I hear you've been having some issues with the App Architecture group."

"Oh no!" I said. "Nothing I can't handle."

"Say no more," he said, "I understand." He left. By the next day the rumor had gotten back to me: the App Architecture group was disbanded. Not only that, but each member of the group was sent to a different department at Microsoft, as far apart as possible. I never heard from them again.

If you've been in the business of building software for any period of time; you've probably found yourself demoing your product to the-idea-man.

The idea-man is usually not an involved client; he is not a regular user; he is not even an active team member --- because all three of these require time and commitment and a typical idea-man has neither time nor commitment.

Chances are; that the idea-man will not even log-in in to your application after you are done with demoing your application to him --- but based on his infinite wisdom and experience --- he is going to leave you with a few ideas that your 'absolutely must' implement.

Once you spot an idea-man; be informed; that he will pull any strings he can to get his ideas implemented.

When that happens:

Does your work environment leave you with no other option besides; dealing with the idea-man diplomatically?

On one hand; I detest nine-to-five organizations with rules or policies for everything.

On the other hand however; when it comes to my own project; I spend countless hours tweaking my code; fixing the casing of my variable names; measuring lines-of-code-per-function; constantly looking the cyclomatic complexity of the functions; desperately trying to bring the complexity down and indulging in dozens of other painstaking exercises which might sound un-necessary to a young and budding developer.

I love driving my car. It’s a male thing, I suppose. It’s somewhere in my Y-chromosome. I embrace every opportunity I can find to hop in my car and start driving.

And (like every other male on the planet) I think I’m a good driver.

You see, I always watch the other cars around me on the road. When changing lanes I check all sides and mirrors. My distance to the cars in front of me is enough to allow for occasional extreme speed reduction.

I match my speed with the weather conditions. I play music in my car (loudly) but I don’t wear headphones. I don’t use my mobile phone while driving. And, as far as I can tell, I am the only person in the world who is able not to cross the lines that mark my lane while taking a curve to the left or the right.

I have adopted this behavior myself.

I might have copied some stuff from other people, but it was my choice to learn these rules and use them, always.

Jurgen illustrates the difference between following-the-rules and acting-responsibly. He explains:

Only thinking and talking about something doesn’t make it so. Just like making up official rules won’t turn your business into a success, traffic signs won’t make you a good driver.

In fact, I often don’t notice many of the signs.

It is my attitude and actual behavior on the road that makes all the difference.

Craftsmanship is something agile doesn’t introduce by itself. And just thinking and talking about it doesn’t give you successful projects.

Managers who want better results must acknowledge that they have to actively change the attitudes and behavior of their people. They must stimulate craftsmanship and discipline. Or else...

Or else accidents will happen.

They say changing people's behavior starts by giving them a good example. So let the world know that yesterday night, while many people were watching the Champions League Final, I myself was learning how to do test-driven development with Python.

I hope to have inspired you.

If you live in the same planet as I do; you will be given rules at every step and corner of your personal and professional life. Every time you are given a rule; you can do multiple things with it. You can follow it; question why; bend it; tweak it; work around it or sometimes even break it outright blatantly and shamelessly.

Remember; what you do with your rules will *not* decide anything --- your attitude; passion for what you do; wisdom; competence; ability-to-make-good-judgment-calls and responsible behavior will.

Go break the rules that don't make sense to you and make new ones that do.

Here's how it worked while it was in business. You paid $200 for a one-year membership. You underwent a big, complicated background check to prove that you were extra-super-trustworthy.

In exchange, in a few big airports, you got to skip to the front of the TSA line for screening.

Now, you didn't skip the screening itself. You still went through the X-ray machine and had to remove your shoes, belt, pocket contents, laptops, and plastic quart zip-lock bag of toiletries.

You just got to cut to the front of the line.

A few people signed up. In certain airports, it was, indeed, worth actual money to cut to the front of the line.

This wasn't Clear's actual business plan. The actual business plan was that Clear would do detailed background checks on travelers, who would then be trusted to bypass security completely because they were extra-super-trustworthy

When TSA rejected the whole idea of skipping the security check and only allowed fly-clear users to just move to the front of the security check line; still leaving the requirement of a security check mandatory; Clear continued with their initial plan --- which was to charge money for their service and continue to do detailed background checks on all their users before they registered them.

At this point, and here's the interesting part, at this point, a rational businessperson would say, "Well, does the Clear idea still make sense if we can’t actually let you skip the screening?"

OK, maybe it still makes sense to charge to skip to the front of the line. Maybe there's a business model in that.

In that case, though, why did they still do background checks? It doesn't make any sense.

The environment changed. It turns out that Clear's business model of prescreening wasn't going to be possible. But they kept doing it anyway. What kind of organizational dysfunction does it take to completely ignore the changed circumstances and keep at a money-losing business?

What's even funnier is that Clear could probably have been profitable if they had just skipped the one unnecessarily stupid part of their business model: the detailed background checks on all their customers.

Nobody at Clear did any thinking.

They had a business model, the business model wasn't actually possible, everybody knew it, and they still plugged away at it. Thoughtless optimism. I don't know whether to salute them or laugh.

I find these stories really fascinating because based on the little facts that we as outsiders are privy to; these stories allow us to do black-box-investigations into huge colossal fu@#kups-ups orchestrated by smart people who had the means and the measures to organize fu@#kups of this magnitude.

Joel does his fascinating and thought provoking analysis of the story and comes to a simple logical conclusion --- Nobody at clear did any thinking.

Take that analysis one step forward and you realize that thoughtless optimism in real life; isn't as simple as a team of lousy-thoughtless-bozos coming together; moving into a dark cave and writing random software after they have lost all touch with reality.

Put simply; thought-less optimism is a slow process that happens over time; and by the time it takes it's toll on your organization; your organization; in all probabilities; has already lost the sight of the stupidity that surrounds it.

While it is easy to conclude that everyone working at Fly-Clear was a bozo indulging in thoughtless optimism; my guess; is that like any other typical startup out there Fly-Clear had its bunch of builders, story-tellers and whiners.

Now; if you assume that Fly-Clear was a decent startup like any others with an idea and an implementation --- it makes you wonder what got them from the great-fun-filled-start-up days to a miserable shutdown.

Maybe the young and smart employees in the corridors of Fly-Clear spoke their mind but then decided to hibernate while the folks higher up in the pecking order could not care less.

Maybe just one senior vice-president high up in the pecking order at Fly-Clear believed that he could still get TSA to agree at skipping the security checks and then all those background checks they did would suddenly become appropriate.

Maybe it was just mitigated speech and complete in-ability to accept; that the whole idea of continuing background checks; even after TSA refusing to skip the security check; was; as a matter of fact; fu@#ked up that brought them where they are today.

Maybe; and here is the creepy part; maybe it was all of the above in small dozes which were barely noticeable.

While it is easy to read stories of failure and discard them as --- Oh-they-were-stupid-we-are-not --- why these stories of failure with very little forensic evidence to base your analysis on; are still useful --- is because they show the level of fu@#kup-ups some decently intelligent teams; sometimes even having a few really smart people; are capable of orchestrating.

Every time you read a story of failure; take a deep hard look at your organization; your team and your project.

Random acts of stupidity might be happening; really slowly; around you; right now as you read this.

Being consciously aware of the fact and knowing that a fu@#kup as big as some of these glamorous fu@#kups could be cooking right in the corridors of your organization is your only chance at avoiding these fu@#kups.

When you are on the look-out for stupidity in your very own project, team or organization; keep your eyes open dear reader; because total random stupidity is not usually very loud and clear.

It all begins with one isolated act; and then it grows from there --- usually in small doses and unannounced till it becomes big enough to cause your entire organization to go-down; without any prior warning.

Next time you look around you and see what is going on in your project, team or organization; keep your eyes open; really wide.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

As I continue to struggle mulishly towards writing the book I started to set out months ago I am starting to realize that there is a lot more to be read; researched and said on the topic of how genuine builders and storytellers function. The 'Random Thoughts On Builders At Work' series of posts is supposed to help me organize of some my random thoughts for inclusion in the book without feeling the urgent need to organize them sequentially.

All of these posts; will be eventually added to the book; but for now; dear reader; you can read them as isolated blog posts without any direct sequential connection with the post that came before it or the one that will follow.

The number of abandoned blogs on word-press or blog-spot that never crossed the post count of ten.

The number of abandoned open source projects on source-forge.

The number of software programmers who upload and update their resume on a job portal every year.

Number of startups that come to an end each year.

Number of ideas on which work is started and then abandoned each year.

Somewhere deep down inside; the question that really kept bothering me was this --- Does this mean that we are all quitters and whiners who start things which we neither want to finish nor support; in the long run.

After a decent bit of soul searching; reading; and one flash of lightning later; I figured out that the answer to these questions; dear reader; really lies in 'why we indulge in the act of building stuff'.

As it turns out; most people; indulge in the all of the acts mentioned above; starting from launching their blog to signing up for an open source project; for the same reasons that crack dealers indulge in the risky business of selling crack.

A 1-in-4 chance of being killed! Compare these odds to being a timber cutter, which the Bureau of Labor Statistics calls the most dangerous job in the United States. Over four years’ time, a timber cutter would stand only a 1-in-200 chance of being killed.

Or compare the crack dealer’s odds to those of a death row inmate in Texas, which executes more prisoners than any other state. In 2003, Texas put to death twenty-four inmates—or just 5 percent of the nearly 500 inmates on its death row during that time.

Which means that you stand a greater chance of dying while dealing crack in a Chicago housing project than you do while sitting on death row in Texas.

So if crack dealing is the most dangerous job in America, and if the salary is only $3.30 an hour, why on earth would anyone take such a job?

Well, for the same reason that a pretty Wisconsin farm girl moves to Hollywood; for the same reason that a high-school quarterback wakes up at 5 a.m. to lift weights. They all want to succeed in an extremely competitive field in which, if you reach the top, you are paid a fortune; to say nothing of the attendant glory and power.

Analyze the life cycle of a typical young and budding blogger bubbling with enthusiasm about to sign up for a free word-press or blog-spot account and you will realize the similarities. You will also realize this is why a huge number of bloggers never cross the three post count. Here is pretty much how the life of a typical blog works:

Bubbling with enthusiasm and encouragement Fred starts a blog; which he believes will make him rich, famous and so-very-sensational.

Fred does three posts in a month; only to discover that no-one cares about him, his blog or his product.

Fred silently and subconsciously decides that the world doesn't deserve his blog and quits; till he finds something else which seems amusing and exciting.

If this describes your mental process as you sign up for a blog; do your first open source check-in or share your idea with your friend; it just means that you may have striking similarities with the Wisconsin farm girl who moves to Hollywood or the drug paddler who risks his life at only $3.30 an hour.

The problem with that sort of motivation; is that; it doesn't last very long. Once you realize that getting to the top is painstakingly hard and there is nothing much to be obtained by staying at the bottom or in the middle; you are left with no other option but to quit.

There's a temptation to over-think the whole thing. I've had a Field Of Dreams philosophy to this: If you build it, they will come. I still have no idea.

I don't look at research. I don't look at who's watching, or when they're watching. I've never been interested in any of that. I'm interested in doing what I think is funny.

For the last 13 years, that seems to have worked for me.

If I go to 11:30 and do what I think is funny, and someone comes and tells me it isn't getting enough people in the tent, I'd say, "Well, that's all I can do." If I'm looking at spreadsheets and time-lapse studies of viewing patterns, I think I'm wasting my time.

What I should be worried about the first night I host The Tonight Show is, "How can I make this a funny show?"

The second night, "All right, let's make another funny show doing some different stuff." You do it one show at a time.

And if you're lucky, eight years later, you've alienated a nation.

Whether it is your blog; your open source project or your next big idea; if you have the slightest element of Hollywood-Baby-Dream about the fame and money that is going to come out of all your efforts; chances are that your efforts are going to have take a nose-dive on the path of failure and you are going to quit; whatever-it-is-that-you-are-starting; in the next few days.

On the other hand; if you realize up-front that your blog, open source project or your ideas are not going to make you rich or famous; and decide to do is anyways; for the pleasure of doing it; chances are that you will find it that much more easier to survive as a low maintenance software terror cell and continue doing what you love doing; for a very long time --- consistently.

Remember; why you start something often governs how long you continue doing it.

During the early days of my career as a programmer; I was hired at Multiplitaxion Inc; where; besides doing my job as a programmer; I was given random chores that other 'respectable-programmers' of the organization found too insulting to take up. The chores ranged from formatting documents; cleaning up HTML; uploading build files on production servers; to ordering food for programmers who were going to work late and fixing lose network cables for people.

Chores that laid the foundation for; and helped me understand the importance of becoming a one man army.

Time moved forward; one day at a time and I found myself working on these chores besides honing my programming skills.

Then one fine morning; years later; I found myself leading a team.

This was soon followed by leading multiple teams.

It was on another fine morning; that I was told that I someone who was very 'senior' and then a quite few people at work started listening to me.

Years later; every time I discussed those early painful times; what I learnt from those times and how those times changed Multiplitaxion Inc; forever; with young and bugging engineers; I started getting funny glances from senior-programmers and managers alike.

Some mildly hinted that the young-and-budding-developers working in teams that report to me might start respecting me lesser if they came to know of my humble starting; stupid failures and the deep scars I had received early on in my career.

Others felt it might have an impact on the overall organizational image.

'Why share stories of your or your organization's humble past with someone who is reporting to you?' --- some wondered.

When old timers tell the newbies stories about “the good old days,” or “how it used to be here,” or “the first time we ever did this” what are they so fondly recollecting? Why in the world do they keep talking about past events, often making the retelling far more wonderful sounding than you remember actually living the experience of them?

Is there any value in this memorable nostalgia?

When stories are told in the spirit of retelling your company history, your storytellers are often capturing the memorable parts; what they remember is largely what they want to keep alive because it felt very good to them at one time.

Stories of what had been give us a look back at those things we once believed in, and want to keep believing in. They reveal the values which had bound us together and still do, and why in the aftermath of the story’s events we kept pushing upward and onward.

They often chronicle successes and achievements, and tell of what people feel was a victory, because by nature we want our stories to be good ones; no one likes to recount their failures.

However whether victory, mistake, or outright failure, our stories undoubtedly recount lessons-learned too important to be forgotten. We feel we can keep learning from them, and we tell the story to re-teach the lesson.

Stories from your organizations past and sometimes your professional past can be humbling and painful. When you lead a team and find a few people listening to you; it's easy to put yourself in an ivory tower; shit-can; hide and never talk about all those humbling experiences from the past that taught you so much or made your organization or your team what it is today.

Not sharing these stories ensures that everyone in your team continues to respect you and your organization.

Not sharing these stories allows you to continue depicting yourself as this super-successful-guy-who-never-gets-anything-wrong and your organization as the-place-that-was-always-perfect.

This approach; dear reader; has just one problem however --- it is your first step to becoming a genuine prick who is always busy protecting his and his organization's so-called-always-successful-image.

Accept it or not; every organization has stories --- stories of success; stories of pathetic failures; stories of things done right; stories of things done wrong; stories of victories; stories of failures; stories of shipping crap; stories of not shipping crap and sometimes even stories of colossal fu@#kups or total disasters.

How many of these stories make it to the corridors of your organization and flow through them; letting your builders; learn from your organization's past?

Accept it or not; every manager has stories from his professional life --- stories of doing a few things right; stories of doing a few things wrong; stories of heroism; stories of pathetic failures and even stories of colossal fu@#kups orchestrated by his very own self.

Look around you.

How many of these stories about your organization, your team or your managers are you aware of?

If you answered 'none' you might be working with a bunch of pricks trying to protect their 'so-called-successful-image' by shit-caning their failures.

Jeff Atwood at Coding Horror had a hard time understanding how open source projects work when he found out that the five thousand dollars he donated to ScrewTurn Wiki was lying idle and unused in the bank; while Dario Solera; the product owner couldn't think of one way to spend money in over four months.

Open Source is to Traditional Software as Terror Cells are to Large Standing Armies. if you gave a terrorist group a fighter jet, they wouldn't know what to do with it. Open source teams, and culture, have been developed such that they're almost money-agnostic. Open source projects run on time, not money. So, the way to convert that currency is through bounties and funded internships. Unfortunately, setting those up takes time, and since that's the element that's in short supply, we're back to square one.

What's interesting; however; is the fact that these 'software-terror-cells' are now rapidly becoming a part of everyday life; and that dear reader; is a good thing.

The idea of guerilla warfare isn't something that is now isolated to open source. It is rapidly becoming; and to a large extent; has already become a part of everyday organizational life.

One 37Signals

It amuses me to just count the number of discussions revolving around 'how-does-37-Signals-make money' that I have with folks from multiple organizations around the world. As much as I enjoy these conversations; there are three things that are really amusing about these conversations.

On one hand you have the whole wide world of software development and the organizations in it wondering how 37Signals is making money.

Every 'enterprise' out there; that needs a couple of million each year just to keep it's payroll moving; wants to be the next 37Signals.

What is amusing is that while the rest of the software development business world is busy trying to figure out the business model of 37Signals and how 37Signals makes millions; the guys at 37Signals are; maybe not through a deliberate strategy; engaging in what Joel Spolsky calls Fire and Motion. Joel talks about the basic idea using his experience as a Israeli Paratrooper. He explains:

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can't fire at you. (That's what the soldiers mean when they shout "cover me." It means, "fire at our enemy so he has to duck and can't fire at me while I run across this street, here." It works.) The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you're not moving, the enemy gets to decide what happens, which is not a good thing. If you're not firing, the enemy will fire at you, pinning you down.

Clearly; 37Signals is pretty much electing to be a software-terror-cell by choosing to grow by not growing. If you gave 37Signals a hundred programmers they probably wouldn't know what to do with them. Put simply; 37Signals is a self sustaining team of seriously kick-ass programmers or genuine builders and story-tellers rolled into one; who can organize themselves and function as a software-terror-cell. A software-terror-cell.

A terror cell that continues to confuse the rest of the world in general and their competition in particular by constantly engaging in fire-and-motion.

Six Thousand Microsofts

Early on in my career we did some work at the Microsoft silicon valley campus. During my short stay at Microsoft I learnt something which was later articulated by another Microsoft employee. The statement was profound and left a deep impact on me --- Microsoft isn't one company. It is just a collection of six thousand Microsofts; and a majority of these Microsofts happen to be successful.

How Many Terror Cells Does Your Organization Have?

Once you've gone out there and hired some seriously kick-ass programmers; your job as a CTO; Vice President; Manager or whatever fancy designation you hold; dear reader; is to get out of their way and let them form self-sustaining-terror-cells which can continue to fire-and-motion day after day.

Try to organize your genuine builder in large standing armies and chances are; you lose.

I don't care how big your organization is; how big your team is; or what 'vertical' of enterprise software development your organization deals with - if you aren't letting your builders organize themselves into small; low maintenance software-terror-cells specializing in genuine innovation with constant fire-and-motion; chances are that there is a huge body shop out there somewhere in India which can take your organization and all it's jobs sitting ducks.

Not to mention of-course that every time you try to organize a large standing army; you screw up your chances of building a remarkable work and fun environment; just a little bit more.

Now go hire some seriously genuine builders and story-tellers. Then once you've hired them go form your own software development terror cells and learn how to fire-and-motion.

I wish you good luck.

How many successful self-sustained software-terror-cells does your organization have?

How many large standing armies is your organization feeding?

Are you indulging in fire-and-motion on your competition or are you being taken down by your competition sitting ducks; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Criterias For Hiring Genuine Builders Who Can Create Remarkable Environments If Left Alone.

Recruiting individuals for your team and organization is an art. An art at which I've seen so many different Vice Presidents, Senior Managers, Directors, Team Leaders and Developers suck that you begin to wonder if we are basically an industry of the incompetent recruiting the incompetent.

With this post my intent and attempt; dear reader; is not to teach you how to hire better people for the job. That; is a topic that can cover a book in itself.

What I intend on doing with this post however; is giving you a few qualities you need to look out for in your candidates while you are interviewing them. Keep these qualities in mind and work hard to develop your very own personal litmus tests around these basic qualities. Do this and you should have a good shot at eliminating most programmers-who-cannot-program; whiners and the fake rock-stars before it is too late.

Ready for some qualities you need to look out for in the candidates you interview?

As you talk to candidates try to drive the discussion to a point where they need to talk about a couple of failed projects from their career. How does the candidate talk about failures; is he objective about what went wrong; is he pointing fingers; did he learn something from his colossal failures; does he seem interested in sharing what he learnt or is he just interested in shit-canning his failures and hiding them from you.

Ever been late to an interview? I've been there; you know the typical bad day where you are running late by a few minutes and you start the interview with an apology for being late. I stared in awe as the candidate; with multiple years of development experience; reminded me thrice that I was late and continued to give me a rather intimidating look.

If you cannot be nice to me when I start the interview five minutes late; it is safe for me to assume that you cannot be nice when the project is running late by a couple of weeks.

I'm not saying that you go in five minutes late during every interview; but figure out a litmus test that tells you if a person is just nice; or he is also nice to work with and nice when the sky breaks lose.

Genuine Builder Know Not; And They Know That They Know Not.

Ask difficult questions. See how frequently you hear the words 'I do not know' during the interview. Most candidates find it difficult to even utter these words once during an interview. Others utter these once or twice but start lying and bitching the third time on.

Remember; genuine builders don't know a lot of things and they are rather well aware of their own weaknesses or limitations.

One of their major strength is that they know that they know not.

Body Language

The art of observing candidates using thin-slicing is a technique described in books like Blink. Of-course you don't have to make split second decisions but anyone who he constantly avoiding eye contact; giving you shitty indignant looks when you correct them at their answers or looking at the cell phone screen as you speak to them in an interview is clearly not someone you want on your team.

Agree To Disagree

During every interview I try to make it a point to play the devil's advocate and disagree to the candidate on at-least one technical or design related topic. Disagree; then observe how the candidate handles disagreement.

Does he argue objectively; are there elements of contempt in his expressions as the disagreement continues.

People who can provide constructive criticism are rather rare. Assholes who randomly criticize things without rhyme-or-reason are a dime a dozen. Unfortunately there is a very thin line that differentiates builders who can provide constructive criticism or whiners who specialize in de-motivating and shattering individuals.

Drive the discussion around the candidate's current project. Try to find out what he feels about the implementation. Anyone who feels that they are doing everything correct is a blatant-compulsive-liar. Anyone who provides random criticism without also mentioning what could have been done to avoid or fix what is wrong; is a down right whiner.

I continue to be amazed at just how many companies ignore this. When one of my bosses told me a deep dark secret of figuring out a candidates possible duration in the organization if you were to hire him; the idea sounded absurd. Like all good ideas; it was absurd but true.

"Anyone who has changed a job each year; for the past three years is not going to stay in your organization for more than a year." --- I was told.

As stupid as it sounds; look at most resumes and you'll see patterns around how frequently people leave jobs. How frequently they hop from one project to another. Unless you are a one in a million example; chances are that you are not going to be able to change this track record. So; if you are looking for a candidate who can be seriously committed; anyone who has changed three jobs in last three years; at the rate of a job a year; is out.

Reason For Leaving

This is one thing that says a lot about the person you are interviewing. I continue to be amazed at just how many candidates lie blatantly when it comes to their reasons for leaving their past job. I also continue to be amazed at how easily they get caught.

As they say --- passion is something that cannot be faked. You either have it or you don't. Ask the candidate which technology does he absolutely love working on. Then let him speak about it and hear him speak.

Passion is easy to detect. Having said that; the paradox of detecting passion is simple --- it takes a passionate programmer to detect and understand passion in another programmer.

If you are yourself a pay-check-programmer whose resume is floating in job portals around the year; and you believe in 501 programming spotting passion is going to be very difficult.

Genuinely Interested And Connected

Most programmers don't read books. Having said that; when I come across a programmer who hasn't read a single book on programming in his entire life; do I really want him on my team?

A programmer who doesn't read programming books is much like a movie actor who doesn't like watching movies. Disconnected and Disinterested.

Does your candidate have a favorite author? Does he work for an open source project? Does he read technical books? Does he have an active blog that he updates regularly with meaningful content? Does he answer forums?

If the answer to most of these is no; he's probably not genuinely interested or connected to programming.

How much time has the candidate spent on your corporate website? That tells you something about his interest level in the organization. Even today; I continue to be amazed by the number of people who come down for an interview without even taking a quick glance at the company's website.

Both of these are clear examples of the candidate not being genuinely interested in programming in general and your organization in particular.

Weird But Acceptable

Genuine creativity is un-conventional; sometimes even ugly and down right weird. During my course of interviewing career I've interviewed and hired candidates ranging from folks who could barely speak English to folks who were so disappointed with BDUF approaches to software development they just couldn't stop talking.

My work experience ranges from working with people who talk about drinking "one gigabyte of alcohol" in an office party to poets who are passionately inspired by other poets. I've always embraced weirdness and have considered it a part of the whole creative process.

Of-course; I've seen a couple of managers have their share of one or two isolated bad experiences where they landed with a kleptomaniac; without knowing they were hiring one; but then that doesn't make all forms of make diversity or even weirdness --- bad.

With all these criteria I might have already started sounding like someone who has years of wisdom at the whole recruitment process. But clearly all this wisdom doesn't work all the time. Which is why; when a candidate referred by one of the top-most-builders in my team fails my interview criteria; but the genuine-builder who referred him has worked with him in the past and is willing to vouch for him; here is what I do --- I shut up and recruit him.

Remember the good old saying that they used to teach you in junior school - 'birds of a feather flock together' --- Your hugely underpaid school teachers knew nothing about the importance; what they were teaching you; would have in your professional life.

If there is something that I've learnt about recruitment after being involved in recruitment for years; it is that idiots usually tend work with idiots and idiots to have friends outside work who are also idiots and they tend to refer these idiots for interviews.

Having said that the same lesson also applies to genuine builders. Builders; usually tend to hang out with other genuine builders. When wondering what you should do with a candidate one of your best builder worked with in a previous organization and has recommended --- remember --- chances are that the seriously kick ass builder who recommended him probably enjoyed working with the candidate because the candidate in question was a seriously kick-ass builder too.

You are never going to find out enough about a candidate during an interview.

When your top most performers refer someone and are willing to vouch for them; shut up; and hire them.

I do not claim of this list being an extensive list of 'all' the qualities you need to look out for; but look out for candidates who do not have most of these qualities and you've filtered a huge part of shitty-whiners out which just makes your chance of recruiting genuine builders that much better.

What are things; besides technical competence; that you look for in a candidate before you bring them on to your team?

How many of these criteria were you actively monitoring or trying to access during interviews you conducted in the past?

Which other criteria do you look for in your candidates, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The second prong, that of the ability to recognize true competence, has major ramifications when we conduct interviews. That's what Joel was writing about in Smart and Gets Things Done, you know: conducting technical interviews.

How do you hire someone who's smarter than you? How do you tell if someone's smarter than you?

This is a problem I've thought about, over nearly twenty years of interviewing, and it appears that the answer is: you can't. You just have to get lucky.

So you can go out there; 'formalize' your interview process; conduct five rounds of interviews; check all the past experiences, educational background and take all the IQ tests you want but if interviews are your only means of selection; chances are; that if you are not lucky; you can land up with a hardcore whiner.

Now that you know you cannot pick the most genuine of builders without getting lucky; the best approach; to take; dear reader; is to eliminate as many whiners and the assholes as possible and throw them out of the pool before you get yourself blind-folded and throw the dart.

The more whiners you have been able to weed out before you take your pick; the higher your chances of picking the genuine builders will be.

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call "FizzBuzz Questions" named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

While FizzBuzz questions act as a good litmus test for programming logic; multiple other litmus tests exist which can help you cover areas ranging from design; testing to general work interest and enthusiasm. Here are some examples of litmus test questions that you; dear reader; can use out of the box to access the overall technical competence, approach and attitude of the candidate.

Tell me any three technical questions that you can answer and then answer them.

Is the candidate lost; can he think of three questions he can answer confidently. Does he stick to simplicity or does he pick a complicated set of questions to impress you and then ends up blowing it. Based on the questions candidates pick; probe deeper and you know who not to hire.

Talk about three of your strengths and three of your weaknesses.

Most candidates when asked these questions describe their strengths rather articulately but come up with ridiculously stupid and artificial weaknesses; the I-cannot-lie weakness being the stupidest example. When you cannot talk about your weaknesses openly it just tells me that either you haven't done any soul-searching what so ever in your career; or you are a blame driven asshole who points a finger at others every time the sky starts falling.

Talk about one project where you were hugely successful and one where you failed miserably.

Any candidate who tells you that he hasn't ever failed falls in either one or all of these categories:

He has never taken a chance and has always remained in the realms of mediocrity.

Now you can go out there and create a few of your very own litmus tests. The one thing to remember about Litmus tests is that they are not supposed to help you pick the genuine builders for hiring. All they are supposed to do is weed the whiners out. Put simply; the fizz-buzz question; for example; will not tell you if a candidate is a good programmer; but it'll tell you if he is a bad one.

Go prepare your own set of litmus tests that are based on your selection criteria and weed out as many whiners as you can. Then take a chance and hope that you get lucky.

I wish you good luck.

What do you do to weed out whiners and pick genuine builders who; if left alone will automatically create remarkable work and play environments?

How many times have you been successful in picking genuine builders and how many times have you failed?

What litmus test questions do you use while interviewing candidates, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Recruitment Managers at Multiplitaxion Inc, look at me like I am an alien talking a different language all together. I've interviewed a hundred people; rejected all of them and have proven beyond doubt that there is something wrong with my eyes and scanning abilities.

All hundred of the candidates interviewed cannot be idiots after all.

Or can they?

Sadly enough no one out of those hundred candidates seemed to fit the criteria of people I would love to work with or even closely match people I was already working with.

'If you take this approach we are never going to be able to hire anyone.' --- I am told.

A subtle nudge that is supposed to tell you that it's OK to lower your criteria and pick the best from what you are getting. We would then go out and make a big noise about hiring the best of the employees.

Now, when you get those 200 resumes, and hire the best person from the top 200, does that mean you're hiring the top 0.5%?

"Maybe."

No. You're not. Think about what happens to the other 199 that you didn't hire.

They go look for another job.

That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one.

So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%.

In the same article Joel also introduces you to the notion that genuine builders are not really going to be sending out their resumes and applying for a job:

In fact, one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all. I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives.

On the other hand there are people out there who appear to be applying to every job on Monster.com. I'm not kidding. They spam their resume to hundreds or thousands of employers.

A lot of times I can see this because there are actually hundreds of "job" aliases in the "To:" line of their email. (Some evil part of me wants to "reply-to-all" the rejection note I send them, but I usually overcome the urge).

What Joel is doing is pushing the idea of reaching out to really smart college interns and hiring them before they get a job opportunity anywhere else.

He is also pushing the idea that in case of genuine builder it is often your organization that might have to approach and quite literally beg them to join. Waiting for the resumes to show up in your inbox is not going to work. Neither is looking out for resumes on job sites going to be a very effective technique.

In multiple organizations around the world I've seen selection criteria come down merely by the virtue of the fact that a hundred candidates have been interviewed and none have been selected. When you cross the magical figure of hundred or more; suddenly; panic strikes. This is when organizations go out there and hire the 'best' out of the pool of idiots they interview.

Having your selection criteria crystal clear and not compromising on it is the first step to hiring a team of seriously kick-ass builders. Of-course Recruitment managers; and teams responsible for hiring candidates; are supposed to pressure you to go out and hire from the bucket of mediocre idiots that are being thrown your way. Providing these gentle nudges is a part of their job.

Most recruitment professionals and placement consultants are evaluated by the number of people that they place. It is therefore no surprise that the expert in them want you to lower your criteria. Most organizations out there actually have a whiner recruitment plan so they want you to lower your criteria as well.

I see multiple versions of the whole 'talented guys are limited'; 'we cannot be hiring all rock-stars'; 'we will never be able to hire at this rate'; arguments being thrown by multiple individuals and organization. Any organization that knows anything about software development turns a deaf ear to these arguments. Steve Jobs; for example; explains the process of hiring and how painful it can be rather articulately in his interview at business week:

Yes, it is. We've interviewed people where nine out of ten employees thought the candidate was terrific, one employee really had a problem with the candidate, and therefore we didn't hire him. The process is very hard, very time-consuming, and can lead to real problems if not managed right. But it's a very good way, all in all.

Most Recruitment professionals will frown when they read this. Steve Jobs; on the other hand; also has a reaction to the argument of managers and organizations not having the time to recruit people at this speed; which he describes rather articulately in the same interview with business week. He explains:

I disagree totally. I think it's the most important job. Assume you're by yourself in a startup and you want a partner. You'd take a lot of time finding the partner, right? He would be half of your company.

Why should you take any less time finding a third of your company or a fourth of your company or a fifth of your company? When you're in a startup, the first ten people will determine whether the company succeeds or not. Each is 10 percent of the company.

So why wouldn't you take as much time as necessary to find all the A players? If three were not so great, why would you want a company where 30 percent of your people are not so great? A small company depends on great people much more than a big company does.

Remember; of all the things that you are going to do to build a genuinely awesome work and play environment where builders thrive and flourish; recruitment is the most important.

It is so important I could quite literally do a complete book on it; but the whole point here is rather simple --- recognize the importance of hiring the right people; have a clear criteria for the team and whatever it is that you do; do *not* compromise on the people you hire.

If you can do that; most of the great work and build environment is pretty much going to happen automatically. If you don't you have lost the battle before it even begins.

Taking the simple approach of We-have-to-live-with-what-we-get does not cut it. All this approach does is create an army of whiners; faster than you know it.

What is your interview to ratio of candidates selected to the number of candidates rejected?

How many times have you been pressured or gently nudged; to settle for less when it comes to selecting candidates for your team?

How many times have you given in to the pressure, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

One of the thing that fascinates me is an environment and the vibe that I get from an organization when I walk into it.

As a consultant I've worked at countless client offices around the world. During this period of my life as a consultant I have seen a few environments that are capable of housing genuine builders and giving them room to maneuver; thrive and flourish. I've also seen a few environments that would make a genuine builder uncomfortable to an extent that he runs and never comes back.

The fact of life however; is that most environments fall somewhere in the middle. Smack in the realms of mediocrity which is good enough to get your work-at-hand done but not cross the chasm of innovation and build something that is genuinely remarkable.

This is why most software companies; irrespective of where they are located hardly do anything which makes big or small dents in the universe.

When I talk about your organizational 'environment' I'm not just talking about how your office looks; how big it is; or what your decor looks like.

Environment is more a state-of-mind; a reflection of your organization's personality.

From the very first vibe that you get when you walk into an organization to the feeling that you develop for the organization after working there for a couple of months --- that's what I like to call your work environment.

That is exactly what I've been interested in observing for quite some time.

Observe a wide range of organizations long enough and you can't help but ask a few simple questions:

Why do some environments have the best of the builders; while others struggle to find even decently good candidates?

Why are some organizations able to make really big dents in the universe; while others are unable to make even a tiny dents on their own backyards?

Why do some organizations need teams of just three builders to change the world; while others find it hard to survive even with armies of consultants?

Why do some organizations have builders sticking around year after year; while others struggle to keep their revolving doors from stopping for sometime?

Why do some organizations have style; finance and brand loyalty; while others are just cheap body shops selling cheap brainless bodies?

These are questions; most managers and organizations; have been trying to answer for a very long time. The answers I believe lie in observing some of these teams and organizations very-very closely.

Everything you will be reading in this section of this book comes from an exercise which involves taking three simple steps:

Studying companies that are successful and observing individuals who have been able to made a big dent in the universe.

Observing the organizations that are getting it wrong and trying to figure out why they are going wrong.

Trying to figure out what is so hugely different between these two organizations or should we just say --- trying to figure out what's wrong in the underlying approach of the two organizations.

Google is often regarded as the holy grail of software development world. It is one company that has undoubtedly changed the face of the world and how we interact with the internet.

CEO's; CTOs and Vice Presidents look at these stories, videos or pictures littered all over the place and cringe at the mere thought of spending millions in trying to build environments which can compete with Google environments.

The safe line of defense you hear these folks speaking is --- 'We're not Google'.

Now that is one line I've heard from friends, acquaintances and sometimes even professionals in offices of the clients I have worked with.

If you've said this before; I've got to be completely honest with you dear reader and give you a little secret you can use.

When I say that; I also mean that trying to mimic the typical-factory-floor model of how people do stuff in 'big companies' and 'body shops' is also something you might also have to consider stopping immediately.

What you need to do is think and come up with ideas that will work in your organization.

Creating work environments for builders is easy. Whether you are a CEO; a Vice President; a Manager; a Programmer or just another employee; I am here to tell you; dear reader; that you can make a difference in the overall thought process of the organization and the overall work environment by making small changes at your very own personal end.

What I intend to do in this section of this book; dear reader; is show you how easy it is to create an environment where builders can not just thrive; flourish and grow but also feel proud enough to spread the word and attract other genuine builders to join in.

It goes without saying that as we move along I will be expressing my ideas and proving my points through the act of story-telling.

The intention here is not to try and preach the list of 'N' things they can do to create awesome work environments.

I wish it was that easy as that and I wish I had the list of those 'N' things but I am really sorry; I don't.

When it comes to creating the best of environments I personally believe that there is no one right answer. My intention here is to give you an insight into the builders mind and what makes a builder happy; motivated and productive not just to stick around but to rope in other builders he knows.

At the very grass-roots level; creating an environment of this sort requires three fundamental things:

Time.

Thinking like a true builder and having genuine empathy for your employees.

Common sense.

That's easy Pops --- you say. Well personally I believe that getting your organization to genuinely adapt to these three simple bullet-points is going to be the hardest thing you might every do in your current job.

During the course of this book we'll look at some obvious common sense driven aspects most organizations; managers and HR professionals seem to miss out on completely. We will also talk about a few things everyone sees but no-one cares about; even when some of these things are hugely important.

Before we start with these stories in the posts that follow; lets end this one with three simple questions for you to think about.

Do you look forward to going to office on a Monday morning?

How would you rate your work environment on a scale of one-to-ten?

Is your organization even interested in collecting your rating and then acting on it, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

The moment when the room fades into the grayness and you can clearly see the white differently from the black.

This is when I am hit by an instant flash of lighting.

I know exactly what I want from the candidates I interview to join my team. Besides, technical competence and a truck load of qualities I already talked about in this book; I am going to pick my builders based on three simple additional qualities:

Laziness.

Selfishness.

Does not bitch about ethics.

Of-course; I know you're knitting your brows already. I know I owe an explanation to what I just said. So; let's get on with the explanations.

Get Me Someone Who Is Lazy.

I'm staring in awe at Fred as he demonstrates his sort-able grid view. He spent months building it. He is flexing his engineering mussels. He is one proud hard working builder.

I'm sorry.

I would prefer someone lazier.

Someone who would just go out there and... buy a sort-able grid.

Honestly.

I have no problems with you building stuff; but going out there and building the thousandth sort-able grid isn't my idea of innovation --- unless of course you are in the business of building grid views.

If you're not you might consider not flexing your engineering mussels of heroism and you might consider buying that freaking grid-view out there.

Having said that; genuine builders love the idea of building stuff. At work; when we landed up with an application needing fifty reports we decided to get lazy and build an ad-hoc reporting system which would allow the end-users to do their own reporting.

Genuine innovation doesn't happen by building the same grid view, reports or CRUD application a thousand times over.

It happens by indulging in the act smart laziness.

Get Me Someone Who is Selfish.

At work my every single day revolves around my selfish interest which over a period of time has co-incidentally intertwined really well with my organizational interest.

When that happens and interests intertwine builders stick around.

During my days as a young and budding engineer; I was conducting three trainings a week on topics ranging from .NET to usability. Even today I try my best to conduct regular trainings at work.

Anyone who tells you that he is conducting these trainings or knowledge sharing sessions for the best interest of the organization is giving you a truck load of horse shit in it's rawest form.

I conduct trainings because:

I get to learn new things which I am going to train others on.

I get better at communication.

I get to flex my engineer mussel and show-off how smart I am.

Training; is just an example. I pick it because conducting a knowledge sharing session seems like the most selfless of acts. I am here, dear reader, to tell you that it isn't.

If you're going to be constantly bitching about how much of your time and bandwidth usage is for work and how much of it is for personal reasons like fun and growth; software development isn't for you.

What you need to do is get a job at the car-factory-work-shop or an Indian-call-center.

Now stop hitting that stupid ALT+TAB window and switching from you-tube to the code window every time your manager passes by.

Try not to obsess about what is ethical and what isn't. Instead; consider having a blast and shipping some seriously kick-ass innovation.

Seriously.

At the end of the day it's like this --- those who bitch the most about ethics; have very little of it.

Now; go hire a few selfish programmers who do not constantly bitch about the best interest of the organization or ethical code of conduct. All they focus on is just their very own selfish interest of growth; building stuff and having a good time doing that.

I wish you good luck.

Oh; and one more thing --- if you are reading this from your office don't forget to watch the office space trailer on you-tube using your company bandwidth --- parts of the movie are what I call utterly hilarious.

How many times do you hear big words like, right, wrong, discipline, ethical and unethical in your workplace?

How many times does your organization expect you to work for the best interest of the organization and not give a shit about your own interests?

Does your organization work on factory rules and no trust; or is it an environment where builders are genuinely empowered, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

"All I am trying to do is work for the best interest of the organization."

The next time you hear those words --- run.

As fast as you can.

And whatever it is that you do --- Don't look back.

If you just heard those words from someone you know; with all due respect to this acquaintance of yours; chances are high that he is either of these three:

A certified prick who utterly and thoroughly enjoys being an asshole.

A Hardcore whiner who is also a self proclaimed well wisher of the organization.

A cheap Indian programmer who in all probabilities is working off a cheap Indian outsourcing shop.

"But Pops; you are hyping this up" --- you say.

No I'm not.

I know what I am talking about.

Trust me.

I've heard these words countless number of times and every single time I've heard them; the bearer of these words have fallen in one of these three categories.

Still knitting your brows; are you?

It's time you take you back in the depths of time and dig from ages that have rolled behind a few stories from the war fronts of software development; that shall illustrate my point dear reader.

Flashback time!

I Removed The Reporting Server

Multiplitaxion Inc, is a new client of ours; their product is struggling to cope up with the traffic during afternoons. We have been called in as a consulting organization to figure out how we can speed up the performance of the application.

The programmers are introducing level-2 caching into the system; the DBA is tweaking the stored procedures.

We've spent days analyzing at our end. Our findings are simple --- the afternoon loads are heavy; the system could do with another reporting server having a specialized reporting database.

Here is the creepy part however --- buried deep down in the physical architecture diagram of the system created a couple of years ago; is a box called 'reporting server' which stands proud and tall.

Confused; we decide to interview the entire team including the Database Administrator who is working on tweaking the stored procedures.

'Oh the reporting server --- that was costing us a lot of money. We got rid of it. We can get this to work by tweaking the stored procedures'. --- it is the database administrator speaking.

Silence.

Sounds of crickets chirping.

I turn around to the CTO; suspecting the highest in the pecking order of usually being the asshole in these cases; throw a simple question --- 'Did you ask them to do this?'

The answer is a cold --- 'No'.

More silence.

More crickets chirping.

"What? I still feel we can run without spending money on the reporting server. All we need to do is tweak the stored procedures" --- we are hearing the database administrator speak; but a very few people in the room understand the language he is speaking.

You have to give the guy some credit.

After all; he was indeed working for the best interest of the organization.

We're just trying to make sure we utilize the company bandwidth for official purposes only

I can't seem to figure out how I got here.

I am staring at a snickering system administrator who finds the idea of downloading videos from you-tube using office bandwidth as grossly unethical and amusing at the same time.

There is one little problem however; the video is a hilariously funny and inspirational; I want to share with my team.

"We're just trying to make sure we utilize the company bandwidth for official purposes" --- I am told.

I hail to the self proclaimed well wishers of the organization.

Then I buckle up to take this further with people in the organization who have the enough power and common sense to understand.

Well actually, he didn't mention the third one; but while he was at it; working for the best interest of the organization; he might as well have designed a Frankenstein Employee Cloning system used to clone a few micro-management-zombies like himself.

Self Proclaimed Moral Police

I could go on with the stories for ever. In fact, given my observations I could probably write a dedicate hilarious book on this but it would mostly end up having a Daily-WTF flavor to it.

For the time being however; let's not even go there.

Lets focus on the point here.

Every organization that I've visited, worked for, worked with, built a project for or observed has a few whiners who like to think of themselves as the 'well wishers of the organization'. People who have a 'job' of defending the organization from the scum of other employees.

I like to call them the 'self proclaimed moral police'.

They individuals; will try to protect every single square inch of the organization they can; starting from the internet bandwidth; the disk space on individual hard disk of developers; to printer paper by monitoring the number of printouts each developer is firing on a daily basis.

After observing countless number of these guys; screwing organizational morale; in my career; if there was one thing I learnt; it was how to spot these whiners in an interview; keep them out of your team and keep then out of the organization.

Spotting them is easy.

All you have to do is keep your ears open and look out for the golden words --- "for the best interest of the organization".

And when you hear those words, run.

As fast as you can.

Whatever you do --- Don't look back.

How many Daily-WTF-type examples under the name of the best-interest-of-the-organization have you witnessed?

How many whining self proclaimed moral police have you had a pleasure of working with?

How many of these decisions taken for the best-interest-of-the-organization ultimately ended up fu@#king up the organizational morale and eventually nudging it in the realms of mediocrity where cheap Indian body shops haggling over per-hour-billing-rates reside; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

'Yeah Pops' --- you say --- 'easier said then done. I've got a angry client or a lose tempered vice president to report to and he wants the application done before the road show. What do you propose I do?'

Surprise.

That is supposed to be a question you needed to answer the day you accepted your promotions and became a manager.

That's when your team expected you to know what to do in situations of this sort.

Having said that, the real question here isn't about what you do.

It is about what you 'think'.

Do you 'think' what your client or your vice president expects out of your team is justified or is he just being an asshole?

If he is just being an asshole for the sake of being one; your job is simple. What you hear in these meetings where the vice president or your client decided to throw a truck load to shit on your backyard; should *not* translate into action items or an unrealistic dead-line for your team.

How you do it is your seriously problem.

Look at him in the eye. Talk to him. Breathe. Convince him. Beg. Weave a story. Tell him what the word 'quality' means. Tell him why you are different from a million Indian programmers sitting in funny body shops running out of India. Kidnap his child.

I don't care.

Ok; the kidnap-his-child bit was a joke that wasn't even very funny --- but you get the idea.

Just because you are stuck with a bad boss or a bad client doesn't mean that your team needs to open their IDE and start slamming their keyboards to write some code that will get the application to crash on the day of the big road show.

If you 'think' however that your boss or your client is acting like an asshole but what he expects out of your team is realistic and what he wants will genuinely help the product --- you and your team need to open that development environment.

Long story short, whether your team opens the IDE or not should *cannot* be decided by how big an asshole your manager is.

It has to depend on what you 'think' about the requirements at hand.

Remember; before you go up to your team --- think.

Do you think what he is telling you to do is going to help the product?

Have you decided that you are going to ask your team to open that development environment and write some code?

Wait.

Before you ask them to do that; you've got a few humbling exercises you need to indulge in.

Get Naked.

The --- "we're working weekends because we need to get this done by Monday" --- doesn't cut it.

No, it's not 'all they need to know'.

You need strip naked.

Tell them everything. The story so far; who wants it; why does he want it; who is being the asshole; why you think it will genuinely help the product; how will it save your job; why you want them to work weekends; why you want their help. Everything.

Remember; this is a save-our-souls signal you're sending out and you're the one who is being rescued; so get the perspective correct when you go out to 'request' your team and ask them to work weekends or push seventeen hours a day.

The getting naked part is hard.

As someone who has requested his team to work in pressured situation more than once; for years; and have been lucky to have the best of builders on my team; I can personally tell you how hard it is to get naked the first time you do it.

What I cannot do however; is teach you how you can do this without feeling a little embarrassed.

If you're going to learn how to lead a team of genuine builders; you're going to have to learn this getting-naked part; by doing it yourself.

I can't tell you exactly how to do it; but If there is one thing I can tell you; it is that bossing around and being an asshole does not work.

If We Fail No-one Gets Killed

Say it.

Mean it.

Even when you know that if it doesn't work out; the sky will fall on your head and you will be left to die under a scrap load of shit.

When you're naked your builders can sense the importance and what the stakes are. The whole idea of If-You-Are-Not-Able-To-Do-It-Someone-Is-Going-To-Get-Hurt helps no one.

If you lack insight into your builder's brain I'm going to lead you into another little secret here which is going to be a life changing moment in your profession; particularly if you are managing a team of genuine builders.

Ready?

When your genuine builders walk up to you and start a conversation around how important the task is and ask you if they 'really' have to get it done by the end of that day; they are not looking for an escape route so that they can go home and sleep with their wives. They are just telling you that they are going to pull of a serious productivity stunt here; a magic trick that might fail and if it does; they want you by their side.

They aren't looking for an escape route when they ask you if they could ship on Monday instead of Friday.

All they are looking for is a safety net; and room to maneuver.

On a subtle; subconscious and psychological level they are testing if you are in it with him.

If they fail; and get stuck; are you going to give them cover fire or are you going to turn around and run like a rat.

I've had multiple cases of Can-We-Ship-Monday on a Friday evening. Some of them have been embarrassing. Walking up to a client and apologizing isn't easy. Having said that most of them times when it has happened - I've said "sure" - and meant it.

The result?

We've either shipped on Friday itself or we've shipped something better that the client absolutely loved on Monday.

We've technically failed more than one dead-line so far; sometimes by a day; sometimes by a couple; but here is the funny part --- the sky is still blue; it's still up there and no-one has got killed.

Learn How To Say Sorry Followed By Thank You And Mean It Too.

Somewhere along the line; after spending countless weekends and late nights in office; I ended up telling myself that I would try my best to see to it that my team members 'can' get out of office by six thirty. If they 'want to' stick around and work --- we're good --- but they shouldn't have to.

The reason to take this stand and to try to make it possible for them to get out by six-thirty is simple; every time I get an assignment done by requesting people to stay late, push harder or work weekends, it just means this:

I fuc@#ked up at planning.

I was incompetent at talking to the client or my managers and getting more time.

I expected them to complement my lack on planning and incompetence with my team's added effort.

If you find yourself in this situation as a manager; remember; pushing the idea that the sky is falling and if the team does not push harder, work late-nights or work weekends, everyone will get screwed isn't going to help.

Let's face it dear manager; you fuc#@ked up and unless you work with a team of idiots chances are that they know that it was you who fu@#ked up.

You might as well come out and say it.

Try topping that with a sorry; followed by a thank you.

Then try meaning both the sorry and the thank you.

There are multiple ways of 'meaning' it.

For me; if you usually work a holiday; it is followed by a couple of complementary day offs when you do not have work.

I usually like to top that off with a team lunch or a party that's on me; not on the organization.

It doesn't compensate for my screwing up; but it's my way of saying three things:

I fuc@#ked up.

I am sorry.

Thanks for the rescue and the cover fire when I was stuck.

You might have your very own style of saying sorry followed by thank you; but if you aren't saying it; and then 'meaning it' using concrete actions not just words --- you're just trying to pretend you're this big highly competent manager who is making an incompetent team 'push harder' when all you are doing is being an asshole and not even knowing it.

Not just watching your manager; they were watching you as well; to see how you are going to deal with the shit that your manager threw at you and which is now safely lying out on your backyard.

Unless you have observed organizations and builders at work very closely; let me turn you on to another secret you may not already know --- ready?

They expect the worst.

Your builders; I mean.

Time has taught them to expect the worst. They're prepared; waiting for you to throw the shit in their backyard and get on with your comfortable life.

You can do it right now. Take the truck load of crap --- throw it over the fence straight at their backyard and forget that the problem ever existed. Be rest assured they have both; the competency and the courage to clean up the mess for you.

There is just one tiny little problem with doing that however --- at the first act leaving the shit in their back-yard you've just disassociated yourself from the team of builders; you have just sent out a very subtle, silent It-Is-Not-My-Problem message to your team.

Do it just a couple of times and your team will start perceiving you as a 'manager' followed by an 'outsider' --- not an integral part of the team who is support to play definite role in the larger scheme of the team dynamics.

Do it a little more frequently and you are not even a 'manager' or an 'outsider' any more. You are now just a 'problem' that the team needs to 'deal with' --- just like hundreds of other problems they have to deal with while they indulge in the act of building stuff.

You are no longer a partner in crime.

You are this pompous prick the team needs to 'take care of' or handle.

By indulging in the mere act of passing shit from your manager to your team; you go from a team member --- a friend --- a partner in crime --- to a being a problem that the team needs to deal with; in one simple and easy step.

Of-course; there is no secret builder's meeting where they officially denounce you as a pompous prick and a problem they now need to deal with.

It all happens with silent clicks-and-ticks in the minds of builders as they observe; watch and draw their own conclusions from what they see.

As smart and sleazy as you might try to act; depending on what you might have learnt from your past experiences; be rest assured; a tightly knit team of builders will have tools and mechanisms for finding out if you're a part of the team; a genuine supporter or a random outsider who is going to run at the first sound of trouble.

During my early days at Multiplitaxion Inc, we worked with quite a few of these bull-shit passers.

We had a name for them --- we called them "mail servers"

All they did was take a flame mail from a vice president, change a few words here and there and passed the message on to the rest of the team. We did their shit cleaning for them. When the shit was cleaned up; they took our emails, added a few more words to make the message as vague as possible and passed the message along to the vice president.

During my early days at Multiplitaxion Inc, I've been with a team where we've lost track of the hours or days spent at office; we have also seen an instance where one of the individuals actually ended up having a physical nervous breakdown followed by a hospitalization; because of the amount of shit was thrown on our backyard.

Did we die?

Heck, no.

All that happened was simple --- we got stronger.

Our bonds as a team grew deeper.

As far as my life is concerned; most individuals from those times, including the builders and bullshit passers have gone their own ways.

We meet every now and then; accidently; in a cafe or a restaurant.

As strange as it might sound, even today, the presence of a colleague from an old time who happened to be a bullshit passer, in the same cafeteria or restaurant makes me feel a little uncomfortable.

On the other hand, let the restaurant, have a team member, a builder or a partner in crime and I would have changed my table faster than you can think. Before you can realize, you will see us laughing and talking about the times when we went from "we're screwed" to "we made it" --- together.

In all probabilities; you will; almost invariably see us giving each other offers to join the organizations we currently work for; because working together again; is something we look forward to.

After all, who doesn't like a partner in crime, watching over his back and giving him cover fire on the battle field especially when you are building remarkable and fun products together.

If you're a young and budding manager; who accidently landed with a team of builders; you can take all your shit and pass it over to their backyard. Be rest assured; they will clean it up for you; before you even notice. There is just one tiny consistent backside to doing this however. You will go from a manager; to a problem passer; to being the primary problem of the project in on simple step.

The next time you are having a bad day --- remember --- if your boss is a pompous asshole -- it is not your team's problem.

Letting the shit run downhill; is clearly not a 'management style' that works; specially when you are working with a team of genuine builders.

The day when someone in your team gets up and says --- 'we're fuc@#ked!' --- and everyone connected to the project pretends things are still fine; every single one of them realizing deep down inside; that we are in fact; badly fuc@#ked.

Panic backs a person into a corner and their only means of getting out of that corner is relying on skills that have worked for them in the past. This is how a normally friendly manager can turn into a backstabbing asshole when it comes to a layoff. See, they were an asshole before; you just weren’t there to see it. If you are lucky enough to see this behavior as well as make it through the layoff, well, you learned two things. First, this guy I work for degrades to jerk when the sky falls. Second, he values me enough to keep me around. The question remains: are you going to hang around waiting for him to be a jerk to you?

It is about the shit that was thrown into your manager's backyard, straight over his fence.

It is time to observe him closely; because what he does with the shit; to a large extent defines his character and your working relationship with him.

Given his position in the pecking order; he presumably has the keys to your professional backyard.

Is he going to add his own crap load of shit and leave it in your backyard?

Is he going to clean up his backyard himself?

Is he going to get the shit to the junkyard himself?

Are you even going to notice that he is having a bad day?

Are you going to find out the magnitude of badness of his day?

Is he just going to talk about it; or is he going to try and pass over the badness to you because he can?

If you do find out when he is having a bad day; and you can find out the magnitude of the 'badness' of his day; and you can suddenly see shit being thrown over to your backyard; it is time to rethink your relationship with your manager and your organization.

Nice Guys

Story-Time.

Flashback!

Jane has found a new job.

She seeks my advice on if she should leave the five years of roots she has developed in her tiny amazing startup; behind. She is a little reluctant about moving on to a newer environment. She is a little insecure; and rightly so.

Jane is a friend; I want to give her the best possible genuine advice I can.

"I know him personally. He is a really nice guy." --- Jane explains --- while talking about her new CEO.

I hear her talk for hours and my suggestion to her is simple. It's a suggestion I've given to a couple of other people in the past.

"Nice guy" is different from "Nice to work with" is very different from "Nice to work with the sky is falling".

Jane really needs to find out if her CEO is nice to work with when the sky starts falling; because just "nice guys" with weak spines often morph into dangerous, ugly and sometimes even political monsters when things start getting ugly.

Nice Guys Or Potential Ass-Holes Waiting To Happen.

The problem with "nice guys" is that they are dime a dozen. Another problem with nice guys is that it's easy to be "nice guy". The most critical problem with "nice guys" however, is that most of them morph into serious assholes when the sky starts falling; and when they do turn into pompous assholes none of them realize that they are turning into one.

If you are working with managers or team members who are just "nice guys" capable of morphing into assholes when the sky starts falling --- it is time to consider making a few changes.

If you have other reasons for sticking around --- the overall environment; the team you are working with; a management that understands software-development; other managers you work with; growth; whatever be your reason; it is time to take your CYA arrows out of your quiver and watch your step.

When you suddenly see a truck load of shit coming your way; be prepared to see these so-called-nice-guys on the other side of the fence; throwing the crap in your direction.

You may not see the complete transformation from a nice-guy to an asshole; but a slight glimpse of shrugging their responsibility; not listening; not have consideration for all the effort the team is putting in; not caring what is do-able and what is not etc. are trait-enough to tell you all you need to know.

Nice, Nice To Work Or Nice To Work With When The Sky Starts Falling.

What differentiates a builder with spine and conviction from a gutless whiner is their reaction to fire. Tell a 'nice guy' about a fire on your project and watch him run. Tell any genuine builder worth his salt that there's a fire on your project and he runs too --- only in a slightly different direction.

Isolate a fire incident and observe a genuine builders worth their salt run; straight in direction of the fire to rescues their team out of it.

Staying late --- just happens.

Working weekends --- give them a hint and they will show up on a Saturday morning.

Cancelling personal commitment --- no bitching or whining. It is not even a problem.

Heated arguments with your vice president of marketing --- there is more than one person willing to bell the cat.

Defending the team even if it means taking up the blame --- sure.

Of-course, they are having a bad day; but they are having a bad day as a team --- as partners in crime who are in it --- together.

Throw shit their way and they will blatantly and openly refuse to take it; as a team.

Ask nicely; and they will go a great length to get your project through.

Being a "nice guy" is easy.

Every whiner that I have ever worked with has been a "nice guy".

It's the "nice to work with" that is harder and the "nice to work with when sky is falling" that is the hardest. What you really need to have is a team where people who are nice to work particularly when the sky is falling; that's you know you are working with a team of genuine builders.

Builders don't make dents in the universe and change cultures by being nice guys.

They do it by being nice to work with; and above all they do it by being nice to work with when the sky starts falling.

How many nice guys go you have around you?

How many of them are nice to work with?

How frequently does your organizational sky start falling?

How many of them morph into monsters when the times are bad and the sky starts falling?

How many of them stick around to rescue the team, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

In my previous post we introduced you to Bozos. Bozos are individuals who out of genuine concern or an unstoppable spontaneous funny little itch want you to walk the lines they walk and remain in the realms of 'normality'. The one thing they forget however is that normal is boring. The problem in surrounding yourself with Bozos is that if you let them grind you down, they will.

Given the fact that not listening to the Bozos is such an important characteristics of genuine builders around the world, I thought it might make sense to bring to you, dear reader, a few genuine builders or amazing trouble makers on the web and present to you, their thoughts on how they deal with the Bozos trying to grind them down.

You cannot let the bozos grind you down; because I tell you; the bozos will grind you down; especially if you have something revolutionary.

Now, I wish I could tell you that, if somebody says you'll fail it means you'll succeed. It's not that simple either; but if somebody tells you you'll fail and you listen to them and don't try, for sure you will never know.

If you think something sucks to the extent that it's actively harming the world and you want it to go away, leaving comments to that effect is not the way. I know, because I bear the psychic scars of a million online flame-wars, dating all the way back to 300 baud dialup modems and BBSes. I've been doing this a very long time. I've seen what works, and what doesn't.

One of my favorite books as a child was the Great Brain series, the story of a family in rural Utah, set in the late 1800s. In these books, there was a strange punishment the parents doled out to their children when they seriously misbehaved. For a period of a week, or longer -- depending on the severity of the misbehavior -- nobody in the family would talk to, acknowledge, or address in any way, that particular boy.

It was called "The Silent Treatment".

This didn't seem like much of a punishment to me. In fact, as an introverted kid who loved solitary activities like computers and reading more than anything, it seemed kind of like a .. reward. I couldn't reconcile this feeling with the semi-biographical reality depicted in the books. To the Fitzgerald boys, the silent treatment was the worst possible punishment, far worse than a physical beating. They would go to incredible lengths to avoid getting the silent treatment. As punishments go, it must have been a doozy, though I couldn't quite wrap my geeky, socially maladjusted young head around exactly why.

The silent treatment was a punishment I didn't fully understand until years later in life. That's how you change the world. Not by arguing with people. Certainly not by screaming at them. You do it by ignoring them.

And if you feel strongly enough about me and what I do here, you can begin by ignoring this.

Seth Godin, a renowned marketer and author, explains the phenomenon of ignoring the Bozos and not letting them grind you down much more articulately in his post where talks about why you should ignore your critics. He explains:

If you find 100 comments on a blog post or 100 reviews of a new book or 100 tweets about you...

and two of them are negative, while 98 are positive...

which ones are you going to read first?

If you're a human being and you're telling the truth, the answer is pretty obvious: you want to know which misguided losers had nasty things to say and you want to know what they said. In fact, if we're being totally truthful, it's likely you're going to take what the critics had to say to heart.

That's a shame. The critics are never going to be happy with you, that's why they're critics. You might bore them by doing what they say... but that won't turn them into fans, it will merely encourage them to go criticize someone else.

It doesn't matter what Groucho or Elvis or Britney or any other one-name performer does or did... the critics won't be placated. Changing your act to make them happy is a fool's game.

Scott Hanselman, a veteran builder and story teller rolled into one; describes his take on Bozos trying to grind him down in one hilarious tweet that made me roll over laughing as I read it.

The tweet: --- "@shanselman I learned that some people don't like my sense of humor. Poop on those people. #standup"

Jokes aside; consider anyone out there who has shipped anything to the world --- an open source product, a paid product, a blog post, an article, an opinion --- anything. If you have or are shipping anything what-so-ever that is worth noticing, it's usually easy to Google yourself or what-ever-it-is-that-you-are-shipping and see some flames being thrown your way by random Bozos or critics out there.

Even with this little blog that is visited by just three people, my mom, me and you dear reader, I have had my share of grinding from random criticisms here and there from both; well-wishers and random commenters.

Every once in a while, a couple of individuals; ranging from a well wisher to an anonymous commenter; will have a general passing remark; starting from an email or a remark on the lines of your-blog-is-becoming-boring going all the way to leaving a comment on the lines of I-am-not-going-to-read-your blog-starting-today.

To be honest, this is not about maintaining a live inventory of flames being thrown my way and linking to them.

Neither is it about how boring, stupid, odd, wearied or evil I am.

This post, dear reader, is about builders.

If there is one thing I've learnt by observing genuine builders for years; it is this --- The bozos out there are supposed to grind you down and nudge you to the safe boundaries of 'mediocrity'. Listen to them and you are going to practice safety by 'doing nothing'. After all, it's easy being a leach, shutting up and contributing nothing --- the problem with that however; is that it's boring.

This is serious stuff; you can go from a contributor trying to share his ideas, perspectives, products or stories to a non-existent non-participant just by listening a couple of Bozos.

Most genuine builders that I have observed in my very own personal life; and the ones I've observed through their work and web presence follow three simple steps when it comes to dealing with Bozos trying to grind them down. The three steps are really simple:

Ignore.

Move on.

Do it anyways.

Once you've done step three and have decided to do whatever-it-is-that-you-were-doing anyways --- push a little harder than you did last time; get louder and do it in ways that are bolder than the ones you have used ever before.

"But She is going to Fail." --- for the last hour; Fred has been on the other side of my cell phone; convincing me; wanting, expecting and demanding me to interfere and pursue Jane to use technologies out there rather than the self-made component she is planning on using for the project.

He wants to hold her hand and guide her to a safe and successful completion of the project. Jane on the other hand doesn't seem to care about safety. She doesn't seem to need any hand holding either. Offer her your hand or some safety and she shrugs.

She seems to know what she is doing.

Like a genuine builder, she is walking without a safety net of lame excuses. She is taking her own decisions; sometimes succeeding; sometimes failing; and most of the times recovering gracefully out of her failures. She has been doing a great job in the last couple of months since she was promoted.

If you are reading this; chances are that you have been through this moment of clarity in your project; your work or your life where you knew what you had to keep doing irrespective of what others told you to do.

They come up to me now all worried and they say, “Aren’t you afraid? Aren’t you afraid you are never going to be able to top that? Aren’t you afraid that you are going to keep writing for your whole life and you are never again going to create a book that anybody in the world cares about at all? Ever; again?"

So, that’s reassuring, you know.

But it be worse except for that, I happen to remember that over twenty years ago when I first started telling people; when I was a teenager; that I wanted to be a writer; I was met with the same kind of; sort of fear based reaction and people would say, “Aren’t you afraid that you’re never going to have any success? Aren’t you afraid the humiliation of rejection will kill you? Aren’t you afraid that you are going to work your whole life at this craft and nothing is ever going to come of it and you are going to die on a scrap heap of broken dreams with your mouth full of bitter ash of failure?”

Long story short, Bozos want you to be 'normal', 'good' and 'safe'; just like everyone else. If you think about it Bozoism-Through-Genuine-Concern-Of-Well-Wishers dates back to pre-historic days when Little-Jack-The-Cave-Kid was living on trees with Uncle-Freddy-The-Cave-Man. That was when it was Uncle-Freddy's responsibility that Little-Jack does not do something stupid; like get down of the trees and get himself killed.

That is when Little-Jack's mistake would have ended up costing him his life and Uncle-Freddy was supposed to teach Little-Jack the 'normal' route to survival; which was to stay up on the trees.

But then a weird thing happened. Someone got down off the trees; no-body was killed and then the entire human race followed.

Today, we live in a world where all a mistake will usually cost you is a minor slap on your self esteem and a little bit of humiliation.

In today's world your professional mistakes will usually not kill you. They will just make you stronger.

Here is the sad part however --- The Uncle-Freddy-Attitude still exists amongst the Bozos who walk your planet; in the form of distant relatives, colleagues, acquaintances, bosses, organizations, client and followers.

Long story short; just in case you didn't look and notice already; the Bozos are all around you.

Bozos In Action - Gentle Nudges Towards Mediocrity.

Experiment One:

Go and announce to your personal friend circle that you are quitting your job and are going to be an independent consultant. Tell them that it means a lot to you and that you really want to do it.

Observe.

The Bozos will kick in trying their best to nudge you back to the safe and established territory of your job life.

Experiment Two:

Suggest a radically new and different corporate website for your organization.

Observe.

The Bozos will kick in trying their best to nudge your back to the safe and know path of a simple, safe looking corporate website.

Experiment Three:

Have a slightly different hair style or follow a slightly different dress-code to office.

Observe.

The Bozos will kick in trying their best to nudge your back to the safe and know territory of the 'old you'.

Do you understand exactly what it is that is happening here? If you don't --- understanding the Bozos around you might help.

Understanding Bozos

Bozos aren't bad people. They aren't whiners. Just 'normal' people living a 'normal' life and having 'normal' fears of failures along with a lot of preconceived notions.

What they feel; is a subtle and indescribable fear of change. If there is one property that describes their behavior the best it is - Homeostasis.

Bozos usually have a 'fear' that you or your organization might make a fool out of yourself.

To be fair to them; some of them might be your genuine well wishers.

In a few cases the fear may be a result of 'genuine concern' for the organization or for you as a colleague.

There is just one tiny little problem in listening to them however.

Listen to them and you will remain safe in the realms of mediocrity for the rest of your life. A realm which builders leave as quickly as they can in search of remarkable outputs and results.

Every single genuine builder that I have seen has thrived, not by confronting or trying to convince the Bozos but by turning a deaf ear to them.

If there is one secret, builders know as a part of their very nature or as a lesson acquired from a difficult experience it is that what ever you do, if you want to build something that makes a big or tiny dent in the universe, you do not let the Bozos grind you down.

He is going around with the right guys in the culture chart, he seems to like lying low, seems to be working abnormal hours and occasionally hides in the meeting rooms and conference rooms in search of silence.

But then we’ve been working on firefighting multiple issues and I don’t have a lot of time to check on Jack. He could be underutilized; we could be wasting his talents or he could be genuinely up to something interesting; but I have bigger problems at hand.

The code generator that Multiplitaxion Inc, is planning on buying; for example; is a big problem needing immediate attention.

I spend a few weeks evaluating various products in the market. Nothing seems to fit our requirement. Soon I am struggling with every single commercial code generator out there. I’m working hard and staying late.

That's when I realize that Jack and I are the only two ones usually in office past midnight.

Since then every time I witness a “builder-hibernation” in an organization, I feel sorry for the organization.

When your builders hibernate, they don't lose their consistency; neither do they stop building stuff. That is their very nature. The behavior is hardcoded in their geans. They can’t help but build stuff.

When they hibernate, they just stop building stuff ‘for you’.

Why? --- Because they think you don’t care one way or the other.

The next time a junior programmer tells you he has ideas do not ask him to focus on his assignments.

Do not tell him to ‘do his job’.

Shut up. Stop. Listen.

The next time you are stuck between doing something that needs your 'immediate attention'; for example; evaluation of a commercial code generator; or having a conversation to someone who seems like a genuine builder in hibernation, remember; the conversation is much more important.

Do not tell yourself you have other important things to address.

Chances are that the solution to the other important things that you are trying to address is lurching in your very own organization and you aren’t even aware of it.

Have you ever seen a builder being told what he cannot do?

Have you seen him go ahead and do it anyways?

What other stories of relentless stubbornness have you seen from your genuine builders, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Jane is doing an amazing job at shipping some serious backend code. She isn't doing it under the temporary fit of impressing her manager. She has been consistently shipping for the past couple of years and yet you see her working away late nights; supporting issues when things break and getting things done by silently attacking one problem at a time without breaking down.

She is passionate; she is consistent and as she runs forward she is taking the team along with her.

Then you realize that when she politely requests other builders to do things, things get done. Just like that.

She isn't just shipping or building stuff. She is leading. She is leading without whining or bitching. She is doing it at a time when your organizations needs builders who can lead.

Desperately.

You weave an amazing and remarkable story around her capabilities. The story of the quite builder being a hero spreads amongst the corridors of your organization. She can now be 'officially' promoted. More power can be vested in hands of someone who is not desperately seeking power.

Life is good.

"I prefer to do my job rather than leading a team. I like to code. Anyways, thanks so much for asking." --- she tells you.

You are hearing words all right but you can hardly understand them.

That's right --- what she is telling you, is that she does not want a promotion.

Yes; builders say that kind of things and here is the really creepy part - sometimes they mean it too.

The entire pecking order of your organization doesn't know what is going on here. Even Jane herself is clueless. But she is telling you something she cannot put in words. She is saying it through her refusal to accept the promotion and she is giving you her reasons very articulately, maybe not through her words, but through her actions.

If you care; I'm going to help you understand what she is telling you.

Her unspoken message has both good news and bad news.

Good news is that she still loves the work she is doing in her team. Her talents are not yet getting utterly wasted in your organization. Jane, as an engineer is highly effective in your organization; and that dear reader is a good thing.

Ready for the bad news?

She knows how promotions and leaderships work in your workplace.

She is developing a disconnect with the way promotions and leaderships work in your organization.

All those whiners that were leading your team and were getting away with promotions and pats on their backs --- she was observing when that was happening.

Now she feels threatened at the idea of being promoted to her level of incompetence.

She associates leadership in your organization with whining and she in her own unique way; has figured out how she can continue to add genuine value rather than turning herself into a whiner.

What she is doing, is simple:

First, she is writing amazing code.

Second, she is avoiding anything that brings her in the limelight.

Put simply, she is lying low.

Unlike fire and motion; a technique well known the world of army; she is using a technique I like to call 'fire and duck'.

What she is telling you is that she has no political skills to match the skills being demonstrated by the whiners leading teams in your organization. She prefers to ship, then duck and hide --- like she does not even exist.

She wants to lie low and keep shipping.

This form of disconnection in builders is so common; and yet most organizations hardly understand it.

The purpose of this post, however is twofold.

First, is to germinate the idea that most builders survive hostile environments by 'fire and duck' or by lying low. When you see whiners talking about how your 'developers' are not good at communication or how your builders need to be managed; more often than not your builders are actually spending extra effort making sure that you think that they do not exist. They might be leading your teams already; they just don't want you to find it out and make it 'official'.

It's a technique which allows them to lead teams without indulging themselves in bureaucracy.

They are indulging in fire and duck; because they don't trust your organization and leadership to come out in the open and take charge. They are afraid you'll promote them to their level of incompetence and that they will rot in meeting-hell.

The second purpose of this post; is to bring to your notice; dear reader; that the disconnect that your builders have with the promotion and leadership; has probably transformed into disconnect for the entire organization. If not, it will; soon; especially if you leave it unattended.

It is important that the next time you talk to Jane you get her to accept that promotion you are trying to give her.

Getting her to accept that promotion is important; because by doing that you are sending out a very clear and honest message to your builders. You are telling your genuine leaders that it's OK to get noticed. You're telling them that it is OK to lead and that it is OK to drive the organization; because if they don't; your whiners will.

What examples of builders indulging in fire and duck or lying low have you seen?

Have you ever seen genuine builders in your organization refuse leadership roles and promotions?

Why do you think they refused the leadership roles when they did, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

When Fred, the young and budding manager disappears, and when you have spent your first few days trying to replace Fred fully and undo the crap he littered all over the place, you realize that it is already too late. The 'builder hibernation' has already begun.

If your builders are in hibernation they don't care enough to gate crash into your office with a big fat red light in their hand to have a fight with you to save the project, the team or the organization from absolute stupidity.

They've had it.

It basically means, you've been cut off from the sound-non-whining-genuine-feedback-loop of your organization or team.

Two, most builders are still going to give in reasonable effort to try and fix things even after they have moved into hibernation; the only difference here is that their opinions are going to be very soft whispers; not the loud shouts that they once used to be.

Why?

Because they have lost their 'attachment' with the organization, team or project.

There's a lot to be said about attachment; but the bottom-line is simple --- If you can't get them to feel the attachment again, you are going to lose your builders.

The third fact is most interesting however --- If you genuinely want them to feel attached to the project, the team or the organization again, they will.

Hibernation is Jack's way of telling you that you need to stop and listen.

When I say stop and listen I do not mean Lets-Have-A-Project-Status-Meeting approach to stopping and listening.

I mean Lets-Go-Out-For-A-Cup-Of-Coffee-And-Talk-Openly approach to listening.

If you are facing a hibernation and your organization, team or project is struggling through problems; chances are that every single problem that your organization, team and project is facing right now, has been solved.

There is a fully-working solution, or an individual fully capable of providing you one, lurching somewhere in your corridors. Solutions to the so called huge organizational problems your senior management is so worried about right now; have long been found and are being discussed in your cafeteria.

The questions you need to ask yourself are simple:

One, are you listening?

Two, do you have the power and the intention to do anything, even if a genuine builder was to tell you the solution?

The two questions are important; because here is the tragic part --- in most cases only one of the answers is a 'yes'.

That is what screws up most projects, teams and organizations out there.

Scott Berkun describes this inability to 'listen' in his classic post on fighting management incompetence. He explains:

The big incompetence crime committed by VPs is leaving incompetent managers in place for too long. My theory: by the time the CEO knows a VP stinks, the whole org has known about it for months. The smart people have been making plans to leave or are working to cover their assses. By the time the CEO gets around to taking action, it’s way too late. And often the action taken is whitewashed: no mention is made of how the VP or middle manager utterly failed (e.g. “Fred has decided it’s time for something new.”) The denial lives on, the lie propagates, making it easier for more denials and lies the next time around

If you genuinely want to do something about your organization, team or project, learn to talk a walk down the corridors and when people look like they want to have a talk with you, strike a conversation; and listen.

Then either gather enough power to do something about it; or you weave a remarkable story of how important it is to fix the situation and convince the big bosses in your organization to help.

Listening is the first thing you can do to de-hibernate your builder.

Ready for the second thing?

The Second Thing To Do --- Act.

“Dude, we have seriously cramped cubicals around here in the new office.” - Jack tells you.

“Half the time Fred doesn't know what he is talking about.” - Jane describes her current manager.

You're sorry you even asked for then genuine authentic blatantly honest feedback.

This is a serious nightmare.

Why?

Because you know you're not going to be able to do anything. You're going to try your best to fix things. You're going to take it up with your Office Administration department and your senior management. Then you're going to die in the meeting hell.

You know deep down inside, that neither are the cubical going to change, nor is Fred going to be replaced.

Peopleware by Tom DeMarco and Timothy Lister describes this so much more articulately. The book explains this through a real life incident:

A California company that I consult for is very much concerned about being responsive to its people. Last year, the company's management conducted a survey in which all programmers (more than a thousand) were asked to list the best and the worst aspects of their jobs. The manager who ran the survey was very excited about the changes the company had undertaken.

He told me that the number two problem was poor communication with upper management. Having learned that from the survey, the company set up quality circles, gripe sessions, and other communication programs.

I listened politely as he described them in detail. When he was done, I asked what the number one problem was. "The environment," he replied. "People were upset about the noise." I asked what steps the company had taken to remedy that problem. "Oh, we couldn't do anything about that," he said. "That's outside our control,"

Which is why when you have organizational meetings to discuss the direction and the vision statement of the organization, no genuine builder ever has a question or a feedback. Which is why when you do a meeting to talk about a project that's failing you hear the absolute silence.

The next time no-one emails you their feedback after a meeting, the next time no-one has a question after a presentation, the next time no-one in your team files in their feedback on the corporate intranet, the next time you hear the sound of the chirping crickets and “something” doesn't seem right, you know what's happening.

Your genuine builders are hibernating and you are either not listening or you don't care enough to act.

Here's the story so far: The team you are being asked to lead was being led by a a certain Fred. Half way through the project Fred decides that the project is officially screwed. Then one fine sunny morning when the sky was clear Fred decides to disappear and does. He doesn't disappear completely though. He leaves some part of his culture behind.

You are called in.

"He was making stupid mistakes" – you tell yourself - You can do better.

Then when you spend a couple of days at the client's office you realize something else.

He was the last one to leave.

Before he left he had ego tussles and power struggles with any genuine builder who could have fixed anything. Most of them left before he did. Others have been rubbed the wrong way and have gone into what I call the builder's-hibernation.

Or when Jane, who was working on your other branch office, stops giving you the direct-to-the-point brief calls when she feels something isn't going right.

Genuine builders will usually take a lot of abuse and continue to work silently. Incompetent managers, loud work environments, unreal schedules --- genuine builder tend to notice this details rather well but they are too busy to react to take any of this seriously.

Then the stupidity keeps piling up.

Slowly.

To a point where something happens and the thin thread snaps.

To be honest, beyond a certain point; where a lot of organizations and so-called-managers go; a lot of things can make the thread snap.

For example, this young and budding manager you hired last month rubs a few of your genuine builders in the wrong way; or says something that is intimidating and down right insulting.

Snap.

The thread breaks.

And then there is silence.

Followed by chirping of crickets.

You continue to get the long-winded status reports; that say nothing; by your so-called-managers. But you suddenly stop seeing Jack; your core engineer.

Jack is the guy who used to gate crash your cabin with one single sentence - “we need more time to ship quality; we are delaying the sprint by a week; can talk later if you want or I can give you more details in an email if you need that but we can't ship crap.” - and then he used to leave without wasting a whole lot of your time.

When Jack does not gate-crash anymore and you have to turn to that status report to see what the team is up to; it might be an indication of Jack moving to a hibernation.

The builders slowly switch to a mode where they do exactly what they are told to do. They cover their ass and become disinterested to even care or give a rat's ass about the project or the organization that they once felt so very passionately about.

They start 'doing their job'.

Put simply, they go into a full fledged 'hibernation'. The feedback loop snaps and all you are left with is cries from whining employees.

“Do you want the system to remember the last time the user logged in” - specific questions of this sort, by Jack and Jane; as they build; stop.

Suddenly Fred is telling your clients and stake-owner what the problem is - “The requirements of the login use-case aren't yet clear and they are constantly changing; we need to have a meeting to freeze the requirement because if we don't it's going to be really hard to start construction”.

When that happens, you know you've lost it.

When that happens, Dot-com companies wind up.

Your job as a builder, story teller, manager, vice president, director, chief executive officer, board manager, entrepreneur or whatever it is that you are, is to avoid this hibernation from a ten mile radius.

If you don't understand how lethal it is you should.

It's lethal for three reasons.

First, the chances of any builder quitting and joining another company are huge during his hibernation period when compared to his chances of leaving when he is genuinely connected to the pond, feeling the ripples and taking corrective action. Genuine builders usually do not quit for factors like a small hike in salary; but make them feel disconnected and you've just multiplied their chances of quitting.

Second, it contagious. Builders usually work in closely knit team. The young and budding manager may have rubbed one genuine builder the wrong way; but chances are high that others that work closely with him are going to disconnect and hibernate sooner or later.

When you start losing touch with Jack or Jane and when they stop showing up, it's time to react like the life of your project, team and organization depends on it --- because to a large extent, it genuinely does.

When was the first time you witnessed a genuine builder or a team of builders go into hibernation?

What caused the hibernation?

Did they come back and feel connected again or did you just lose them?

What brought them back?

Have you ever disconnected or hibernated, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

A time when any organization is vulnerable to someone like me, who is trying to study it and get loads of information about the organization, the people who work there and the culture chart that prevails in the organization.

Seriously.

"But Pops, why is Nine AM so important?" --- you ask.

OK, do this --- walk into any organization you want to examine at nine AM sharp and observe.

Watch everything that goes on; closely.

Chances are; here's what you see --- tons of people dressed in formals, getting in, grabbing coffee and settling down to work. If you are in a larger organization and have a good imagination you'll be able to draw your very own personal parallels.

Now, here's the secret --- rare exceptions apart, that crowd that you are watching as it gets in to work, dressed in all formals, is exactly that --- 'a crowd'.

Remember the Pereto Principal they taught you in management schools when you were a young and budding student?

It was the little lesson where they taught you how only twenty percent of the people do eighty percent of the job in any organization.

Remember that?

This 'crowd' rushing in to office at Nine AM with ironed shirts, ties and suits; is that other eighty percent of the people the Pereto Principal did not explicitly mention just for the sake of being nice to them.

A very few exceptions apart, they are the boring mediocrity and potential-current-or-future-whiners.

The Nine AM observation is one quick and easy way to spot whiners.

On the other hand, here's how you spot potential genuine builders:

Drop in to office at five in the morning and you'll see a couple of heads popped up in the vacant cubical farm; deeply immersed in serious work. You have a few genuine builders who are showing up early to get some real work done.

Drop in to office at eight evening and you'll see a couple of heads popped up in the vacant cubical farm; deeply immersed in serious work. You have a few genuine builders who are staying back late to get some real work done.

Of the Nine-AM-Crowd, try to spot the slightly strange guys; the strangeness can manifest itself in subtle ways - for example, some of these guys might be coming in with slippers, others with undone hair; some might be wearing jeans; some T-Shirts or some even shorts. You would find clear violations of organizational rules conducted with absentmindedness and humility. These guys will not even realize they are violating your organizational policies and rules.

If you can't find any of the above three in your organization, it's bad news.

Seriously.

My point?

Real builders are not just ugly; they are often slightly weird and lack respect for rules.

Of all the things that describe genuine builders 'normal' is one word which does not even come close to describing what genuine builders are or what they do.

Here is the ironic part, however --- Most organizations out there seem to have a serious passion for hiring 'normal' people who do 'normal' things, including following 'normal' office timings, adhering to 'normal' office dress code and organizing 'normal' meetings for having 'normal' discussions.

We love the simple idea that only a beautiful person, or a beautiful team, can make something beautiful. As if Picasso wasn't a misogynistic sociopath, van Gogh wasn't manic-depressive, or Jackson Pollock (and dozens of other well-known creative and legendary athletes) didn't abuse alcohol or other drugs. Beauty is overrated, as many of their works weren't considered beautiful until long after they were made, or their creators were dead (if the work didn't change, what did?). Most of us suffer from a warped, artificial, and oversimplified aesthetic, where beauty is good and ugly is bad, without ever exploring the alternatives.

Scott takes the concept of our leaning towards the safe and beautiful and attacks it heads on:

Pop quiz: given the choice between two job candidates, one a prodigy with a perfect 4.0 GPA and the other a possibly brilliant but "selectively motivated" 2.7 GPA candidate (two As and four Cs), who would you hire?

All other considerations being equal, we'd all pick the "beautiful," perfect candidate.

No one gets fired for hiring the beautiful candidate. What could be better, or more beautiful, than perfect scores? If we go beneath the superficial, perfect grades often mean the perfect following of someone else's rules.

They are not good indicators of passionate, free-thinking, risk-taking minds. More important is that a team comprising only 4.0 GPA prodigies will never get ugly. They will never take big risks, never make big mistakes, and therefore never pull one another out of a fire. Without risks, mistakes, and mutual rescue, the chemical bonds of deep personal trust cannot grow.

For a team to make something beautiful there must be some ugliness along the way. The tragedy of a team of perfect people is that they will all be so desperate to maintain their sense of perfection, their 4.0 in life, that when faced with the pressure of an important project their selfish drives will tear the team apart. Beautiful people are afraid of scars: they don't have the imagination to see how beautiful scars can be.

Amongst all the other things they are ugly, shameless, loud and weird; they have beautiful scars which they carry with elegance and humility. They take risks, bend the rules, fail and continue consistently even after being told countless times they should consider stopping or changing their path.

Fred; gets in by Nine AM sharp; he's out at six; always adheres to the official dress code; always fills his timesheet on time; never has a fight with his manager; never goes around the official company policies; never breaks rules; never fails and is one hundred percent professional. Even your HR department loves Fred. You should not be having Fred in your team and if you can influence the decision, you should not be hiring Fred in your organization.

"But Pops, the guy is just following the rules. What is the problem here?" --- you ask.

He is yet another boring employee and a whiner; at least a potential one.

While your organization might be busy looking at time registers to see who is coming early or late; if you are looking for genuine builders in your organization; all you need to do is be careful of is the Nine AM employees; who wear a tie to office and get everything right.

They are your whiners.

A few others troublemakers that remain contains all your builders.

If you want to genuinely monitor how well your organization is doing, how many whiners and how many genuine builders you have --- observe your organization at Nine AM.

What is the number of Nine AM Employees compared to the early comers and late goers in your organization?

How many individuals can you think of who break your organizational rules like timing and dress code without even realizing they are breaking rules?

If you really want to understand builders and what makes them survive, tick and thrive; observe what they do.

During my professional life, this is one thing I've spent hours doing whether it is observing a young and budding engineer I might have hired for the organization I work for or observing the famous online-success-stories through their blogs and through what they ship.

Grabbing my attention is easy. All you have to do is mention a genuine builder and if I can observe him personally, through his work or through his blog; I will.

As it turns out, builders come in all shapes and sizes. They have different ways of working. Some of them prefer to lie low and ship while others thrive by selling the achievements of their team to their organizations. Some prefer talking to the compiler and shipping amazing stuff, while others weave remarkable stories and make small dents in the universe with their very own unique perspectives.

After working with multiple genuine builders and observing countless others online, if there is one conclusion that I've arrived at, it is that each builder is different from another. Yet the fundamentals that make these individuals builders generally the same.

One of my objectives of writing this book was to turn this personal observing exercise into a coherent stream of thoughts that allow me to not just observe builders; but actually dissect their actions and arrive at my very own conclusions regarding the people who build organizations, teams or bring amazing products and services into our life.

What follows are common traits I've seen in every single genuine builder I've observed or worked with in my life.

Consistency.

It's not that whiners don't have amazing ideas or cannot do great stuff. It's easy to write off whiners as people who whine, bitch and waste everyone's time but that is clearly not the case. Some of the whiners that I've observed are fairly intelligent and smart people; yet they are unable to deliver anything that makes any considerable impact on the organization, the team or the project that they work on.

So, what is going on with the whiners?

Why can't whiners get to ship something that has any impact on anything or anyone's life?

The answer to this question lay in my interactions with Fred and Jane.

After a few days of observing Fred, I realized that Fred was not a bad guy after all.

Slightly political --- definitely.

Naughty --- sure.

Stupid --- not really.

Fred often did have his share of amazing ideas which were genuinely all right.

Fred however, had a problem.

You couldn't get Fred to work on a single project for more than a couple of months. Fred was a classic parasite, that overwhelmed the project team with the list of cutting-edge technologies they aught to use and when he had made it amply clear to people sitting high up in the pecking order of the organization that he had contributed sufficiently by providing 'thought leadership' or by doing a dozen 'proof of concepts' he would jump over to another project.

Fred was what I called the 'Idea monkey' back then.

You could allocate Fred to the most comfortable of all the projects and be rest assured things would start going wrong. You would start having communication issues, issues with timelines and issues with shipping.

Jane on the other hand, happened to be a quite builder who was slightly reserved and liked doing her work quietly in a corner cubical. You hardly ever saw her laughing or hanging out with people; not even with her own team. She was a quite, intellectual who liked to be alone and write code.

If you had a project that was stumbling or failing all you had to do was to put Jane in the project and then slowly things would start falling in the right place.

It wouldn't happen overnight though.

It would take weeks, sometimes even a few months before a late project would come back on time or a project littered with bugs and broken windows would suddenly start meeting the quality standards.

By that time Jane would have developed really strong hold on the project and would have settled down with one track focus of shipping, sprint after sprint. Ask her if she wanted to move to a different project and she would look at you with eyes which would made you feel sorry you asked.

Here is the spooky part however --- if you were to compare the years of experience, educational qualifications, designation or even genuine technical competence and talent of Fred and Jane, Fred would beat Jane hands down. Yet, Fred, somehow managed to screw up project after project when Jane led even the most screwed up ones to a successful end.

What was happening here?

It took me a couple of months to figure this one out. On the surface Both of these talented individuals were awesome guys and equally fun to interact with.

On close observation for a couple of months however, you would notice that there was one thing that separated the two however. While Fred, was seriously interested in 'proving' his abilities and chasing one successful project after another; Jane was interested in getting into a project, understanding the issues, developing firm roots on the project and then working on solving one problem after another --- consistently.

Project after project, If there is one thing I've learnt, it is that consistency is one quality which differentiates genuine builders from whiners. Not talent, competency, caliber or anything else. Irrespective how much much talent, intelligence, competence, smartness or IQ you have if you are not consistent, chances are that you either are a whiner or will turn into one pretty soon.

Seth Godin for example, differentiates performers from ones who forever remain the realms of mediocrity using the concept of Dip. He uses the following diagram to illustrate Dip:

Seth explains:

Almost everything in Life worth doing is controlled by the Dip,

At the beginning, when you first start something, it's fun. You could be taking up golf or acupuncture or piloting a plane or doing chemistry-doesn't matter; it's interesting, and you get plenty of good feedback from the people around you.

Over the next few days and weeks, the rapid learning you experience keeps you going. Whatever your new thing is, it's easy to stay engaged in it.

And then the Dip happens.

The Dip is the long slog between starting and mastery. A long slog that's actually a shortcut, because it gets you where you want to go faster than any other path.

The Dip is the combination of bureaucracy and busywork you must deal with in order to get certified in scuba diving.

The Dip is the difference between the easy "beginner" technique and the mare useful "ex-pert" approach in skiing or fashion design. The Dip is the long stretch between beginner's luck and real accomplishment. The Dip is the set of artificial screens set up to keep people like you out.

The Dip, according to Seth is the point where excitement of doing something new dies down. If you are a blogger, Dip is the point where you realize that no-one cares about your blog and that your blog with three entries about your cat will not make you the most popular blogger on planet earth. If you are a software developer writing an open source application, Dip is the point where you realize that you are just not getting more than ten downloads a month.

If you are a young and budding entrepreneur trying to build a business around an idea which you once thought will change the world, Dip is the point when just ten unique visitors show up on your website on the launch day and no-one is willing to buy your universe changing product for just ten dollars.

Long story short, Dip is the point where the excitement of starting something new dies down and the realization that you are not going to change the world with whatever it is that you are doing, as easily as you had expected you would, sets in.

That's when most whiners jump on to something else.

That's when a whining blogger starts a new blog; a whining entrepreneur thinks of a new idea; and a whining programmer hops over to a new project or a new job. Genuine builders however, ask themselves if they genuinely love and believe what they are doing.

If we think about it this way it starts to change everything. You know, this is how I've started to think and this is certainly how I've been thinking about in the last few months, as I have been working on the book that will soon be published as the dangerously, frightenly, over anticipated follow up to my freakish success and what I have to sort-of keep telling myself when I get really psyched out about that is "don't be afraid", "don't be daunted", just do your job.

Continue to show up for your piece of it; whatever that might be.

If your job is to dance, do your dance.

If the divine cockied genius assigned to your case decides to let some sort of wonderment be glimpsed for just one moment through your effort, then Ole! And If not, do your dance anyhow and ole to you none the less. I believe this and I feel that we must teach it. Ole to you none the less just for having the sheer human love and stubbornness to keep showing up.

When people ask me for advice on blogging, I always respond with yet another form of the same advice: pick a schedule you can live with, and stick to it.

Until you do that, none of the other advice I could give you will matter. I don't care if you suck at writing. I don't care if nobody reads your blog. I don't care if you have nothing interesting to say. If you can demonstrate a willingness to write, and a desire to keep continually improving your writing, you will eventually be successful.

But success takes time --- a lot of time. I'd say a year at minimum. That's the element that weeds out so many impatient people. I wrote this blog for a year in utter obscurity, but I kept at it because I enjoyed it. I made a commitment to myself, under the banner of personal development, and I planned to meet that goal. My schedule was six posts per week, and I kept jabbing, kept shipping, kept firing. Not every post was that great, but I invested a reasonable effort in each one. Every time I wrote, I got a little better at writing. Every time I wrote, I learned a little more about the topic, how to research topics effectively, where the best sources of information were. Every time I wrote, I was slightly more plugged in to the rich software development community all around me. Every time I wrote, I'd get a morsel of feedback or comments that I kept rolling up into future posts. Every time I wrote, I tried to write something just the tiniest bit better than I did last time.

If there is one thing that connects every single genuine builder that I have studied, observed, looked up to, seen or worked with, it is relentless consistency to keep showing up.

Unless of-course you have a something remarkable in it for them which makes them care.

To add to that, neither of these are reason enough not to ship on your own self picked schedule.

If you haven't picked one thing that you absolutely love doing, and are not giving it your consistent focused attention day-after-day relentlessly; for years; you probably are just wasting your time, whining away to glory.

If you are going to stop reading this book, right now, right here, remember this before you do - builders ship; consistently.

Oh and that product that your organization might be shipping out successfully --- it is *not* shipping because your young and budding managers who are awesome at organizing meetings and talking big are going on a white-board or brainstorming about cutting-edge ideas.

Chances are, that it is shipping because, a few builders in your organization, who you may not even know have been slogging away, quietly; for years; without looking for a new opportunity, a new project to jump on to or something new and exiting to hop on to. It's shipping because of tremendous amount of commitment, hard work and the will to 'show up' day-after-day which is often characteristic of genuine builders.

That's consistency.

Of all the traits of genuine builders, this is one that all genuine builders I have seen so far; demonstrate; consistently.

For the sake of story telling; we're going to strike a deal; you and me dear reader. The deal is simple --- from this point on unless I say otherwise every time I refer to 'builders' I mean 'builders' of stuff and people who 'build' remarkable stories.

You; are going to humor me; and I; drear reader am going to try and convince you that people who build and ship; irrespective of whether they build stuff or stories pretty much use the same techniques for survival, growth and getting things done at work.

Everyone else whines.

During my software development career if there is one thing I've studied rather closely it is the mind of all three kinds. Builders of stuff and genuine story tellers have striking similarities in the way they work, think, behave and connect to one another. From this point on, because of these similarities I'm going to put them in the bucket with a label 'builders'.

Whiners get their very own special bucket though.

Long story short, builders equals builders of stuff and stories; whiners are whiners. You are supposed to remember this for the rest of the book as you read along.

Deal?

Good.

Let's get on with the post.

The Whiner Recruitment Plan

The point I intent to make with this post is rather creepy. I, dear reader, with this post, am going to suggest that your organization has a concrete 'recruitment plan'; but this is not the conventional recruitment plan that you were taught to write up in management school. This is a special recruitment plan where your organization works really hard to maintain the constant ratio of whiners in your organization.

I like to call this the 'whiner recruitment plan' and the best way to explain this is through a story.

Ready?

Flashback.

I'm a young and budding engineer at Multiplitaxion Inc, learning my first lessons of software development.

Unless you got lucky somewhere and were suddenly born in programmer heaven, each one of you reading this; may have learnt this lesson the hard way.

I am sure you have your very own interesting stories surrounding this but this is probably the one thing that you learnt after your first six months into your first job --- most organizations out there have way too many assholes.

The number is much larger than what you anticipated when you walked into the office on the very first day of your first job.

Of course your school had its share of stupid teachers, and your college was swamped with professors some of whom some were hardcore idiots but nothing beats your first six months in a typical software development shop.

The first week usually begins well. You develop a decent amount of respect for your managers as they introduce you to the organization and paint a picture the HR wants them to paint. Then you see them work; take stupid decisions and do funny things.

Unless your managers are genuine builders or story tellers; three weeks down the line the question starts to take shape.

You still can't state the question articulately though.

It takes about three months for the questions to take concrete existence in your brain when you suddenly realize that you can now express the questions rather articulately in your mind. Then all of a sudden; you find yourself asking these questions in the deep corners of your mind --- How did these idiots get here? Who hired them?

For all those of you who are in this incubation period, it takes you about a year to come to an answer. Before I continue with the story, I'll do my good deed for the day and make your life easy by giving you the answer.

Ready for the answer?

Other whiners who preceded them hired them.

The whiners who hired them have been now hired by other whiners in other organizations and they have moved on; because that's what they do; they hop jobs. Most organizations out there pretty much replace all their whiners with fresh new whiners every three years. Only a few of these whiners who are very high up in the pecking order manage to stick around.

Only a few of these organizations manage to reduce the number of whiners while replacing them with new ones. Most others pretty much maintain a steady ratio of whiners is to builders --- it is almost like there is a 'whiner recruitment plan' at the organizational level. Seriously. Study a standard software development shop out there for three years and you realize that ratio of whiners to builders pretty much remains the same; year after year.

Do you know what makes the 'whiner recruitment plan' tick at an organizational level?

In my very first job, in a company I shall call Multiplitaxion Inc, we had meetings every-time a couple of 'big' projects failed. Lots of ugly finger pointing happened --- back then the blame game was played under the name of 'root cause analysis'.

Then we picked a couple of whiners who could be let go.

Six months down the line, the whiner count would be the same.

For almost two years, this little ten person startup was under a constant layoff mode.

But Pops, that was just a small startup; you say.

Guess what, it usually takes you another five years to figure the real answer --- the 'whiner recruitment plan' works pretty much the same way even in the biggest of the organizations that you'll see.

What makes it tick is simple.

The board. The Investors. The Vice Presidents. The Directors. The Senior Managers.

Any one of these guys can make it tick.

In order for the 'whiner recruitment plan' to work all you need is a couple of very senior individuals who often wake up after two years of hibernation and realize - 'We are fu@#ked. Nothing is getting done. If we don't do something about nothing getting done we are screwed.'

Then a master 'clean up plan' is devised; things are made difficult for the whiners and whiners hop. If they don't ugly layoffs occur. Usually they do. Automatically. Most whiners are surprisingly good at the art.

The new environment, changes and development suddenly starts making other whiners who are high up in the pecking order really uncomfortable and they go out and start recruiting fresh whiners for their teams.

They do this relentlessly of course; till the exact same 'homely' cozy environment of mediocrity returns.

The 'whiner recruitment plan' isn't an excel file.

You will not find it attached to any mails that blaze through your mail server; but it doesn't matter where you work; I am here, dear reader to tell you, that your organization has an implicit, sub-conscious 'whiner recruitment plan' which has targets for the numbers of whiners your recruiters need to find and the number of whiners your interviewers will be letting through.

It's a flawless piece of machinery; requiring no lengthy meetings; no discussions; no mail trails --- it doesn't even require management approvals.

Watch closely. If you are recruiting, the 'whiner recruitment plan' is at work; in your very own organization; right under your eyes.

The numbers are different, the specifics might be different, but the machinery is at work --- with the silent precision of an unspoken agile process which never fails to achieve it's objective, which in this case is to keep the ratio of whiners and builders constant across time.

Of-course, if your projects followed the flawless perfection with which the 'whiner recruitment plan' works, you organization would be the perfect programmer hangout place --- but then successful projects mean more work, more change and things which makes organizations nervous. The 'whiner recruitment plan' on the other hand; offers no such threat. It's one of the riskiest safe things most organizations out there indulge in.

Do you find your organization changing policies every year?

Do you feel that a few things "will never change" in your organization?

Do you find your organization hiring a lot of 'senior managers' or 'top level leadership' every year?

If you have an organization or work for one; you are going to a have few whiners who slip in through the cracks of your recruitment process.

"I don't know about that one Pops. He seemed to have some skills but I am not sure if he will be able to deliver. Overall he is really smart; good communication; good educational background. I think we should go ahead." --- Fred who has conducted a smart whiner's first round of interview, tells you. Fred as it turns out, has a huge collection of stupid puzzles and math questions which forms his selection criteria of excellence.

The same set of funny puzzles and questions constitutes Fred's criteria of who you should hire in your organization.

That is how it begins --- you listen to Fred and hire your first whiner.

Then before you know it you have an army of whiners being interviewed and getting in your organization.

I've seen dozens of whiners getting recruited in dozens of organizations around the world and there is one conclusion I have personally come to. It is the darkest secret most organizations do not have the spine or the audacity to admit. Whiners know this secret. All of them do. As a matter of fact, whiners en-cash on this dirty little secret every time they interview. It's insanely weird but true.

I'm going to do my good deed for the day and break this dirty little secret to you.

Ready?

Organizations are looking for whiners.

Believe it or your, your organization might be spending a whole deal of time, effort and money looking for whiners.

In fact, most organizations out there love whiners.

That's right. You heard me.

Organizations want whiners so badly that they go out of their way to recruit them.

Of course you are knitting your brows.

"Pops; why would anyone want whiners?" --- you ask.

Simple. Because whining is safe. It's easy; and it's also fun.

Seriously.

Try it.

Go to your friend across your cabin and talk about how overworked and underpaid you are. Go talk about what an asshole your boss is. It is fun. Do it a couple of times and you'll realize it's actually more fun than slogging away at a piece of code or writing your own blog post. Actually, it's not just more fun; but it is also much more easier than doing anything else.

Here is how it works --- 'everyone loves whining' --- you do; your boss does; his boss does; the whole pecking order in your organization does.

Builders and story tellers realize the perils of whining and make a conscious effort to stay away from it; but what about the good old Fred who just cannot seem to connect to the team of builders and who has just been promoted to the designation of a manager? What about your Vice President of Marketing who is a road warrior and on the move for most of the month?

Whining employees give these individuals an opportunity to catch up with events that happen in the corridors of the organizations. It lets them figure out what the builders are working on or what they are up to. It allows them to know about every insignificant ripple that takes form in the organizational pond.

Do me a favor; read this:

Three developers go in a meeting room; they argue; they fight; they kill each other and they come up with an amicable solution which is best for the product.

I'm sure at-least one young and budding manager yawned somewhere as he read this.

Now read this:

An official meeting request went out. Joe couldn't make it to the meeting because he had another meeting. A long meeting was organized. Wilma and Smith completely disagreed on the various approaches discussed in the meeting.

Two approaches were selected during the meeting out of which one would be finalized. A mail thread followed the meeting. Senior members across the organization were copied on the mail trail. Some of them responded expressing their concerns around both the approaches.

Three of these senior members proposed their ideas and each one of them thought the other two ideas would not work.

The mail thread continued for two weeks.

Now we're talking!

You now have all the interest of the young and budding manager you just hired to 'manage' the project and the team. He is not yawing any more.

See what is happening here? Your boss, his boss and the whole pecking order of your organization is feeling the pulse of the pseudo-work. They are getting involved.

Now they suddenly feel that the young and budding manager they hired last month to 'manage the project' is doing an amazing job. He is helping your developers who were incapable of communicating.

Very soon your organization realizes that it needs more young and budding managers who can initiate discussions; put simply your organization feels a strong need for whiners.

See the point?

Most organizations out there want more whiners; and they want them desperately.

'Some discussions are important' - you are told - really important. Planning, Organizing, Architecture, Scalability and Brainstorming are words words which are often used to disguise the time that is getting wasted in pseudo work where nothing is getting done. Most organizations love wasting time behind these words because it gives them a warm and cozy feeling inside.

It makes them feel safe.

It makes them feel like they are in control.

Whiners know this fully well.

They are aware of the power of whining fully well.

They also know the dark little secret that everyone wants to whine.

Maybe this is why most employees in any organization get away with 'discussions'; 'giving ideas' that die in the walls of a meeting room; or make it their profession to come in the way of genuine builders; while only a small number indulge in the act of doing some real work and shipping stuff or remarkable stories.

Unless you are one lucky son of a gun who happened to find the rare breed of organizations that understand innovation inside out, chances are high that your organization is looking for whiners. Even now as you read this whiners are getting interviewed; and they are getting selected.

Whiners with years of whining experience behind them. Whiners with solid educational background. Whiners who can solve virtually any puzzle or funny math question out there; and yet the fact remains that they are whiners --- incapable on building stuff, weaving stories or shipping anything consistently.

What questions do interviewers in your organization ask the candidates?

Do you depend on Math puzzles and IQ tests for selecting candidates?

How much time are you encouraged to do real work and ship?

How much time does your organization and your managers expect you to be talking and updating them with the status?

Are you being giving reasons to indulge in the acts of bitching and whining even if you do not want to?

Is the overall environment of your organization in general and your team in particular giving you reasons to become a builder or a whiner?

Is your organization actually looking for more whiners right now as you read this dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Storytellers build remarkable stories about awesome products built by genuine builders. Stories which change the world. Stories which build tribes. Stories which add a soul to a product; stories which add a purpose to the team's effort and meaning to an 'organization'.

They are mavens, leaders of tribes and masters at the art of remarkable story telling.

Much like builders realize that their every existence depends on the awesomeness of products that they build; story tellers realize their their very existence depends on their stories being built on the foundations of genuine truth. Strong foundations of honest stories is what storytellers often stand on.

This of course; means that an amazing storytellers usually ends up doing three things:

First - they weave remarkable stories with strong foundations.

Second - they work hard to turn those stories into realities.

Third - they build even more remarkable stories based on strong foundations of their older stories.

It's the second item that makes story-tellers the official trouble makers of the organization and a pain in the ass for the more traditional departments in the organization.

Here's how it works.

Your vice president addresses the entire organization in an 'all staff' meeting. Here he gives a rather motivational speech --- he goes ahead and says that yours is a company with a difference. It is an organization which trusts people to take calculated decisions and judgment calls rather than relying on stringent policies.

He goes ahead and says rather clearly that each one of you is a talented mind who is better than the best available out there. You are not just a 'resource' --- but an innovator. The organization believes in you.

Now if you've ever been to one of these meetings --- here is what happens --- people listen, people wonder how all this impacts them. People yawn. People doze off with open eyes wondering when the speech will end.

But the story tellers in your organization are listening. Listening to every words. Once the meeting ends they get down to the work of weaving remarkable stories around each word. Stories which can add cause and meaning to your organization. Stories that your team genuinely 'wants' to listen and care about. Stories that they themselves genuinely believe in.

Then something remarkable happens. Something that very few organizations understand.

What started with a boring all employee meeting; turns into small yet remarkable stories. Then these stories that are told by story tellers start spreading within the corridors of the organization. People genuinely start making small judgment calls and start taking decisions pertaining to their projects.

A small tribe of proud employees is formed. Employees who genuinely want to believe that they work for an organization with a difference --- an organization that trusts individuals to make decisions and judgment calls for the best interest of the organization.

What started off as a boring speech, turns into a way of life.

The story tellers aren't lying. They aren't cheating your team. All they are doing is adding purpose, meaning and passion to a story that was told in the speech. That and they are working on turning the story into reality.

This is where you start seeing issues though.

Before you know it, there is someone who is talking to the office administration staff about making office timings flexible or buying a few X-Box consoles and the guys at administration department are freaking out. They are looking at him like he has a third eye.

That's when the new-flash happens.

Of course the Vice President said those things and of-course he meant it. But he didn't "absolutely-mean-it-mean-it". He didn't want you to 'act' on it. He didn't intend to start a tribe of employees who are 'proud to belong' --- it was just a speech.

Then the bunch of whiners flow in with ideas about discipline, threat to the corporate culture, employees not being mature enough and what started as a remarkable vision from your chief executing office or vice president turns into dirty war of 'everyone trying to do their job' and a joke where everyone pretends to be working for the 'best interest of the organization'.

If change is something organizations in general and whiners in particular are scared of, remarkable visions or stories with concrete actions to turn them into reality are much like nightmares to organizations.

These are exactly the moments that a small number of really smart organizations often grab. They hold on to these moments. They give the story tellers every tool to turn the vice president's speech into a reality that is exciting and a culture that is full of fun. These are organizations that give story tellers every tool they need to weave genuine and remarkable stories. These are organizations that give their builders every reason to belong.

After all it is easy to organize a meeting with inspirational speeches. As long as the general mediocrity of the organizations aren't threatened with concrete change no-one will have a problem with it. Storytellers are trouble makers because they weave remarkable stories and then work on making them real. They threaten the comfortable mediocrity most organizations are so used to.

Which remarkable stories have you heard in your organization?

Which one of them were killed by whiners who claimed that they were trying to work for the "best interest of the organization"?

Does your organization have flexible timings, work from home and x-box consoles?

Do you have tribes of employees who feel proud to belong?

Do you have whiners in your organization who believe that your employees aren't mature enough to be trusted with work hours and video games in offce?

How many times do you hear the words 'maturity' and 'discipline' at work, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

When builders indulge in the act of building stuff what they are actually doing is building foundations of the organizations in which they work.

Given the fact, that remarkable products and services are the very basis of a successful organization you would think that most organizations out there would be going out of their way to hire the best builders that they can get hold of much like tea pickers pick the best tea leaves they can find.

Most organizations however, are not looking for the best of the builders.

The "not" in the above sentence is intentional. It is not a typo.

It is a rather important fact. A fact that you must know and understand fully well --- particularly if you are a builder, someone responsible for hiring others or an entrepreneur starting your own organization.

As a part of my professional and personal life, I talk to countless engineers and managers around the world. Strike a conversation around their recruitment drive and any budding manager will tell you that his organization is on the lookout for the 'best talent' that is available out there. Put simply, he will tell you that his organization is looking for some seriously talented, kickass builders.

This post is about shattering the dreams of that young and budding manager.

Irrespective of what your organization announces in those weekly newsletters --- Your organization is *not* looking for seriously kickass builders.

Knitting your brows already?

Ok, story-time!

Ready?

Let's have a quick flashback.

As young and budding builder at heart when I am asked to lead a team it seems like a simple task.

Leadership, I tell myself, means that you work harder; you take up bigger problems and if people are stuck they come to you for help. If they are not stuck; they go about doing their work and you go about doing yours. If you're leading a team of seriously kick ass developers; every once in a while, your team also expects you to build something which inspires them. That's pretty much it --- leading smart engineers is simple --- all you need to do is help and inspire.

At-least that is what I tell myself.

Two weeks down the line I find myself looking back and reflecting on just how wrong my definition of leadership had been.

As it turns out, organizational definition of leadership, is different. Very different.

In the real world where 'shit happens' --- leadership; has a completely different meaning than the meaning it has in your very own personal world.

Your being promoted to a leadership role means you will now be sending weekly documents called 'reports' to people who have no direct involvement in the project and are often referred to with fancy names like 'senior management' or 'stake holders'. People who can do nothing other than making things worse when your project starts failing.

In my case, leadership came with it's baggage of 'weekly status reports' which I was expected to send to my immediate manager who happened to be a part of the 'senior management'.

Week 1 --- I am excited about this whole leadership thing. I send out a neatly formatted, status report which takes me more than a couple of hours to write.

Week 3 --- The status reporting thing starts sounding boring. Downright boring. I find other important things to do; like helping team members who are stuck and making sure that a fully functional build gets uploaded to a test environment so that everyone in the organization can try it out.

A day later I get an email from the 'Senior management' telling me that I had missed sending out my status report and that it was unacceptable for someone as senior as me to just miss sending out reports.

Week 5 --- I am stuck by a realization; a question and a curiosity all rolled into one. A couple of subtle questions are gnawing away at the back of my head. 'Do they really read this crap?' --- 'what do they understand about the project health by reading this crap?' --- Then a personal tiny little experiment is devised.

Before I describe the experiment may I suggest that you do not try this at your workplace. It is clearly an experiment which can get you fired if it fails. Ok, ready for the experiment? Here's what the experiment I decide to try out after five weeks of boring status reporting.

On the fifth week I take a copy of the report I had sent the week before that. I attach it to the email; cross my fingers; and hit the send button.

The next day is fairly interesting. I look at my mail box, only to find out that life is good. No-one complains. No-one even realizes that it is the exact same file as the week before. No-one, is reading those status reports.

Week 6- The same document that was sent for the last to weeks is taken; the file name is changed; the file is sent. No complains.

Week 7 - Status reporting is now suddenly becomes really easy for me.

Sending a weekly status report from then on is easier than most young and budding managers can think. For as long as the project lasts, I send the exact same status report and no-one even notices.

Then the project ends. We ship the build, everyone loves it; the project is a success --- and the reports?

Question: Do you think this manager of mine wanted me to send the reports because he was going to read those reports or do anything with them?

End of flashback.

Let's snap back to life.

A simple dissection of the story and picking up the nuggets of lessons learnt of it will help. After all, if we don't do that, we are just as guilty of whining as professional whiners.

If there was one thing I learnt from the event; it was that most of the people from the so-called 'senior management' are often afraid of change. Change that threatens their existence. A team of three young and budding developers self sufficient at shipping is every whiners nightmare. It is in fact every organization's nightmare.

Why?

The reasons are two fold.

Firstly, because the pecking order has been genuinely made to believe that whiners have a specific function in defining the existence of the organization; that 'developers are not very good at communication' --- that builders need to be 'managed'. When a couple of genuine builders show up and challenge the conventional beliefs not by empty meetings and discussions but by consistently shipping concrete deliverable results; it is natural for whiners to feel threatened.

This highly respected project manager of mine for example, liked to believe that the project was on track because the team was aware of the fact that he 'might' be tracking the project through the status reports. He genuinely believed that the status reports were keeping us on track when in reality all these status reports were doing was wasting a lot of my time.

His role and function in the project was redundant. Removing him from the project would have helped us ship faster; and yet this dear manager of ours believed that he has a definite function and a concrete role in the project. He was the self proclaimed, 'project policeman'.

Secondly, organizations like to believe that the whole 'organizational' arrangement of things is what causes projects to 'tick'. 'Always think of the team first' - 'you can hardly do anything alone' - 'team achievement is much more important than individual contribution' - 'we need to document stuff so that people are replaceable; after all someone might fall sick; decide to leave or might get his by a bus' --- ever heard these statements in management meetings?

Organizations like to believe that it is the organizational structure that is hugely responsible for innovation; not individuals that they hire; while in reality the reverse is often true. We like to refer to our most remarkable builders as 'resources' and then we like to go out and prepare 'project plans' and 'resource management reports'. We like to naively believe that it is these reports and processes that make the organization tick.

A couple of builders, shipping successfully without any organizational intervention feels scary to organizations which do not believe in the idea of individual contribution. Most organizations and managers alike; find it difficult to leave a team of builders alone.

This; dear reader; is why most organizations and even the so-called-managers out there are *not* looking for genuine builders who can build remarkable stuff silently; this is why most organizations out there are looking for professionals who can be programmed to follow processes and believe that they are just a tiny drop in the larger 'organizational' scheme of things.

If you work in one of these organizations; irrespective of what your Human Resource department tells you, chances are high that your organization is not looking for genuine builders. In fact, in all probabilities, your organization is shit scared of builders or anything that brings about any form of change. Chances are high that you organization is in fact, looking forward to hiring whiners and maintaining the whiner recruitment plan.

How many genuinely deserving candidates have you seen getting rejected in the interview process?

Why did these candidates get rejected? What reasons were sited by the whiners who rejected them?

How many genuine builders or story tellers are leading teams in your organization?

How many whiners that have been promoted to their level of incompetence?

Is your organization letting the builders take the back-bench and letting the whiners drive the organization, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

If you are neither a builder; nor a story teller --- you are a whiner.

It is really that simple.

You can defend yourself with a piece of paper called your business card and claim that you 'manage projects'; that you are good at 'client interaction'; that you are a 'people person' and that you have fifteen years of experience in building enterprise applications but none of that changes the fact that you are a whiner.

Maybe a very powerful whiner sitting high up on the pecking order of your organization. So high up that you will never be reminded of the fact that you are a whiner and you might have blissfully forgotten it; but you are a whiner none the less.

In the world of software development, there are pretty much only three things you can be doing and I'm going to tell them to you. Ready?

Whiners are interesting individuals though. They are what can be referred to as thermometers in an organization. Seth Godin in his book, the Tribes describes the difference between a thermometer and a thermostat. According to Seth while thermometers; tell you what is wrong; they are use-less primarily because they are incapable of changing things. Thermostats on the other hand, change things, silently --- and almost automatically.

Whiners feel they are in control. They often have 'revolutionary' ideas to change the organization. They indulge in a lot of meetings to that effect. They get very excited when you invite them to meetings and ask them their opinions. Whiners neither connect to story tellers nor do they connect to builders and you will often here them pass remarks on the lines of - 'developers are not very good at communication'.

Whiners love sophisticated tools and systems. Tell them of an organizational problem and they will start talking in terms of systems you are going to need.

Whiners are also hugely insecure about their jobs and will hardly ever take independent decisions or judgment calls. Whiners are notoriously famous for organizing meetings and inviting huge audiences in them; to take everyone's opinion. Having said that you will see no decisions emerging out of those meetings.

If you have heard yourself or someone complain about the lack of process, lack of documentation or lack of discipline in your organization, the individual; in all probabilities, is indulging in the act of --- whining.

As we move on through the book you will meet a few whiners and learn techniques of avoiding them. Having said that, this is not their book --- so let's keep their introduction as short as possible. Let's just wrap up for the time being by stating a general fact.

Builders make organizations, whiners break them.

How many whiners do you see around you?

Are there interesting, funny stories about whiners that you know of, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Chances are that you will find them in all walks of software development. Some of the best story tellers I have seen have played absurd roles --- project managers, team leaders, catalysts and even evangelists.

Honest, genuine, good story telling, done even at simple levels can make or break projects.

Flashback time --- here is one example.

At Multiplitaxion Inc., two projects are over budget with similar variances from the initially budgeted timelines.

Fred, after flexing all his management mussels, his state of art 'resource management' techniques and his proven 'processes' is not being able to keep the project from falling apart.

Weeks into the project the team has lost faith and has started shipping crap.

Months later the management looses faith and pulls the plug.

"Funding" --- we are told. We run out of funding.

Project Rocket Science is officially dead.

Project 'B' on the other hand has similar issues of bad estimations.

The project however had more than one story tellers involved and connected with the project.

Project B's team does not embark on a project. They embark on a story which they have been told. A story built on truth with larger than life elements to it.

As the ramp up for the project is happening, every single member of Project 'B' is hand picked. They are told in clear teams that they are being picked because the project is special and that they are the best. They are told that they have been picked, to create meaning; to shape the future of an organization. To build a remarkable product that will change not just an organization but an entire industry.

It takes time, but the story is told remarkably; from one story teller to another; until it spreads through the corridors of the warfront where the development is done. Everyone; including the story tellers themselves; believe the story.

When we slip deadlines we are told that we were making history; we could not ship crap. We're told not to lose patience. Not to panic.

Half way down the project we are convinced that there is no reason to panic.

Then as the project proceeds; something creepy happens --- the story slowly and steadily starts to turn into reality.

We start shipping stuff that was genuinely remarkable. Stuff that very slowly and steadily starts making it's slight dents in the overall industry.

Flashback over.

Ok, here's the million dollar question --- where did we go right with Project 'B'.

First thing where we went right was of-course the fact that we had amazing builders. To add to that, what we had was an amazing story. A cause. A meaning. A purpose. The project wasn't something we shipped to get our job done or to get our salaries. We connected to the project. We connected to the story around the project.

The outcome?

No-one stopped the project.

We shipped a product which was not just profitable; but remarkable in it's own way.

True, we were as over budget just like Project Rocket Science; but if there is one thing that you can take from this story; it is this:

No-one; I repeat --- No-one cares about the budget.

Neither your team, nor your management, nor your client.

One way to look at your budget and deadlines, is to see these as commandments you absolutely must follow.

But, in the long run, that does not get you anywhere.

If that is your line of thought, you will continue to build mediocre products that can be otherwise defined as 'successful failures'.

Story tellers have a slightly different way to look at budgets and deadlines. They see them as mundane numbers; nothing but boring facts. Story tellers know that people who sign the paychecks and the clients; look at these boring numbers 'only' when they have nothing more interesting to look at.

In the case of Project 'B'; the 'story' was larger than the boring facts. It was much more interesting, exciting, evolving, fun filled and remarkable.

The outcome of the story, the product itself, was even more remarkable.

Obviously, no-one looked at the boring facts.

We shipped. We made a dent in the universe; in our very own small way.

We were successful.

Story tellers, as it turns know that a lot of their story telling depends on stuff the builders ship. This is why genuine story tellers show a lot of honest respect for builders. They use their art of story telling to get the crap out of the teams way. They use their art to glamorize projects; products and even team members who deserve to be glamorized. They use their stories as bullshit busters; and to change stuff; for the better.

Story tellers, besides respecting builders and hanging out with them connect to them; genuinely; and naturally. They stick their neck out for people who build stuff. This is because genuine story tellers know fully well that without remarkable products and remarkable stuff there can be no remarkable stories which are built on foundations of honesty.

Without amazing builders, the role of an amazing story teller does not exist.

Good story tellers know this fact and aren't ashamed to admit it. Openly.

Story telling is hard.

What is in-fact not hard, is wearing the badge of a pseudo-storyteller.

Now, that's easy.

To do this you go around building a lot of political relationships with people high up the pecking order in your organization. Then you play the nice guy with your team and when hell breaks lose or when you get pecked on by the peckers high up in the pecking order you peck on your team.

Here's another way to pseudo-storytelling.

Go to a client meeting --- when the client questions you about a feature you don't have and they are wondering if you can build it by the trade show which is going to happen next month; nod your head and say yes to everything; hoping your development team will build it by 'staying back a little late' or by 'pushing harder'.

Remarkable Story Telling as it turns out, is much harder than being a pseudo-story teller or a whiner.

Are you a manager --- Weave a remarkable story around your teams; get a few genuine builders promoted and a few whiners removed from the project. Weave a remarkable story to calm down a panic stricken client, director or vice-president.

Are you a Vice President --- Weave a story to add meaning to a product or an entire organization.

Marketer --- Get just a hundred mavens who are genuinely interested and will spread the word to sign up for an awesome service your builders have built.

Writer --- Try to get a thousand unique returning visitors per day on your blog.

Indulge and aim at either of these and you will learn first hand how hard story telling really is.

It's hard.

Really hard.

It is in fact as hard building stuff; because when you weave a story, you are in fact, indulging in the act of 'building'; even if it is not 'stuff' that you are building.

If you are a pseudo-story-teller you are just another whiner.

If you are a genuine story teller; you are important. We need you.

Are you a story teller?

What are some examples of story tellers you have worked with dear reader?

How have storytellers improved your work-life, dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Of all the people I've worked with in my software development career; every single one of them; in terms of what they do; can be grouped into one or more of these three categories:

Irrespective of where you work, what you do, what your business card reads, what your designation is or what your role is --- you fall in one of these three categories: builders, story tellers, whiners.

After years of analyzing people; especially people who work in software development; that is the conclusion I have arrived at.

Everyone is one of these three.

It is that simple.

You may have traits of one or more of the three but overall you are one of the three. If you are going to read through this book, it is important that you understand these three personalities well; really well.

Learning from builders and story tellers is what this book is all about; so it makes sense to introduce you builders first.

Ready?

Read on.

Builders.

Builders build stuff. Amazing stuff. They ship.

They are the ones who might be making your life interesting with remarkable and innovative products or services and you may not even know it.

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue.

Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

That is exactly what builders do to organizations.

They build stuff; which invariably ends up building organizations.

They change crappy organizations into productive ones.

Silently. Innocently. Sometimes, even unknowingly.

If you've ever stumbled upon a team of genuine builders and you are a smart individual, there are a few things about builders you tend to learn rather quickly.

Most builders as it turns out, are quiet; very quiet --- at-least that's what most 'managers' will tell you. The notion of the introverted programmer who is so busy talking to the compiler that he loses touch with reality and stops talking to human beings is the stupidest stereotype painted by classical managers who for reasons more than one cannot seem to connect to builders. You will of-course find builders to be incredibly quiet; but only till the time you connect to them.

If you've ever stumbled upon a team of genuine builders and have connected to them you probably know rather well that there are exactly two ways of connecting to builders.

The first one is so simple; it almost sounds stupid to write it down; and yet it is so important that I am going to indulge in the act of stupidity and write it down.

To connect to builders, you need to be a builder yourself.

That is correct. Builders, as it turns out, can smell stuff getting built from a ten mile radius. If the stuff that's getting built is genuinely remarkable they can sense it from a different planet or even a whole different universe. Your best chance of connecting to a team of builders in your organization, while you work with them, is to indulge yourself in the act of building and work with them; hand in hand.

Put simply, roll your sleeves and do some real work if you can.

The second way to connect to builders, is easier and harder that the first approach. Easier because you can walk into office tomorrow morning and do it; just like that. No special technical training required; no classes required; no special sixteen hours a day of slogging required. Harder because you won't do it. It is in fact so darn simple, I can spell it out in two small sentence for you; which is exactly what I'm going to do.

Ready?

Get out of their way.

Then when you have learnt how to do that get the bullshit out of their way and let them build stuff; even if it gets you fired.

Doing both of these things is hard and they don't even teach you how to do these in management schools.

Actually, it is as hard as being a builder. It involves putting yourself in the line and taking all the crap that is redirected to them with one isolated focus - that the builders in your organization do not lose their focus. If you can genuinely and honestly do this, and can continue to exist in your organization, without actually getting fired; the builders will connect to you.

Once you connect to genuine builders in your organization though; either by the virtue of the fact that you are yourself a builder or by the virtue of the fact that you are a bullshit buster there are things you will learn about building stuff; about innovation; about how a builder's mind works and about how things get done.

Things most organizations and individuals do not care to know about. Things that are often not published by the articles that tend to talk about the labor and toiling of builders as a glamorous overnight success stories. Besides trying to study builders at work, this book will attempt to describe, as articulately as it can, some of these things, that I and others were able to learn by connecting to genuine builders and watching them in action.

Are you a builder?

Do you work with a team of builders?

What have you learnt by connecting to and working closely with a team of builders; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

I threw the casual question at an acquaintance working in a large IT department of an organization. From then on, he took over the conversation holding me hostage to his story as he described his recent tour to Australia; his recent promotion; how he now had seven people reporting to him and a truck load of crap which was supposed to make me look at him in awe as I heard him speak.

If you ask me honestly though, he was boring.

If I could have yawned without insulting him, I would.

The same question led to a very different answer from a passionate developer whose organization had just removed him from a project that he had started a year ago and had asked him to work on another project which, according to his organization, was much more critical.

He held me hostage too. He talked about how his management didn't understand software development, how is boss was an ass-hole and how nothing ever worked out as well as expected in his organization.

Frankly, he was equally boring.

If I could have yawned without insulting him, I would.

The same question asked to a distant relative also working at a software development shop; resulted in boring stories of his a vacation with his wife and his friends. He held me hostage as he gave me a boring account of how he and his wife did a lot of shipping during this vacation and how they managed to land up with the best prices.

Yawn.

That same day, around a thousands of individuals answered the same question on my RSS aggregator; without even being asked to answer it.

Some of them talked about a nugget of wisdom they picked up in their management life; some of them shared their neat code; some published a tool; some talked about an open source framework they were releasing; some talked about a neat idea which would make their build and deployment process better; a couple of them had read a book and were recommending it with a warning about specific parts which they found slightly boring.

None of them bragged about their promotion; their position in the official pecking order of their mediocre organization; their salary and how they saved a few dollars during a boring vacation.

Even when they indulged in rants, they did it in an uncanny classy style brimming with passion, cause and described the lessons learnt along the way; rather elaborately. They took their rants, made them interesting, packaged them with humor and shipped them with an intent of passing on what was learnt from a rather ugly or painful experience.

There were no boring monologues.

I did not know any of these individuals personally.

Honestly, I wasn't interviewing them. They were not answering my question.

They were building stuff; remarkable stuff; software, stories, experiences and communities. They were creating remarkable tools; building applications that would change the world; tweeting nuggets of wisdom; writing articles, doing blog posts and then when they are done; they were pushing whatever it is that they were building live.

They were building stuff; and shipping it. Without whining; without excuses; without cribbing, bitching or moaning.

Some of them worked at prestigious names like Microsoft and Google; some were independent consultants; some were working in insignificant companies that you wouldn't be able to locate on the map if you tried to; some were leading teams; some were managers; some merely college students and a couple of them were even single moms; but none of that mattered.

What mattered was that they were building stuff in ways more than one.

What mattered even more; was that they were having fun.

They were having a party and anyone who cared to join in --- was invited.

These were not whiners; talkers or boring employees who do what they are told to do.

These were relentless workers, story tellers, rule benders and people who make small and big dents in a really large universe of 'normal' human beings that is generally hostile towards the idea of things changing. They were what I like to refer to as --- builders; and they were at work.

Look around you; and if you are lucky; you might have a few of these amazing builders sitting around you.

Think of people you work with; and you might know a few of these guys yourself.

This dear reader; is their book.

If you are one of them, dear reader, then this, is a book about you.

These are the gripping stories from the strangest corners of organizations where remarkable things get built by builders who indulge in the process of 'building' for two reasons in particular --- because they love building things --- and because they 'can' build things which are genuinely remarkable.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.