Myth: Builders Are Not Good At Communicating With People.

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.

Michael Lopp in his nerd handbook describes this exact same phenomenon:

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.

Philosophies ranging from how to build better stuff; to how you should live a meaningful life and why you should do what you love doing or why you should give in a little bit extra. It is a gold mine of information; but the rules of getting in are simple --- you have to either be a genuine builder or at-least speak the language your genuine builders speak.

Every brain in your organization that belongs to a genuine builder is ticking and trying to communicate ---- constantly.

The real question is --- can you; communicate with 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.

Three Rooms

Of all the organizations that I have seen, worked for or worked at; very few live up to the programmers bill of rights by Jeff Atwood.

Yet I continue to see a few genuine builders; with their thick skins and deep passions; not just survive; but thrive and flourish even in the most hostile of all environments.

In one of my blog posts I tried to study the cubical-farm-culture most organizations out there promote and figure out what is wrong with them. If you are stuck in a cubical farm; chances are that you are stuck in an organization; that does is not really looking to build an environment where genuine builders can thrive and flourish. An organization that is happy in the realms of safe-mediocrity.

In this case; if you are looking at your organization to help you come in flow and be productive; chances are; that you are not going to get all the support you need up-front. To be honest; there is a decent chance that your journey is going to be a slow and painful one; where you find yourself rotting in meeting hell every now and then.

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.

The first step into the room gave out a general vibe which made it fairly clear that you got into the room if you wanted to brainstorm an idea; throw it out to people; fight over it ruthlessly or get some seriously honest and candid feedback on your ideas or projects.

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.

Even with our highly traditional ideas of 'fun' and how much an organization should spend or budget for it; the impact of this small 'fun-room' with cheap indoor games was hugely positive.

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.

The rules for this room should be simple --- you shut up and work.

No talking. No discussion. Period.

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.

Words Of Wisdom From A Story Teller.

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.

This little-extra is what is usually required to cross the dip. It is what results in overnight-success-after-years-of-effort. It is what separates a blu from being yet-another-twitter client; a tortoise-svn-client from being yet another SVN-client and a project-path from being a yet another task-list cum project management tool.

Now; here is a task for you dear reader. Go review your products and try to do an honest self assessment on them.

Are you absolutely loving the act of building these products?

Are you having fun every day at work?

Are you just building me-too products?

Or are you leaving the mark of a genuine builder on your product by putting in a little-bit-extra into it?

Which one of the two approaches does your organization or work environment expect and encourage you to take; 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.

Why You Cannot Please Everyone.

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.

Multiplitaxion Inc was about to take a new form; shape and a completely new makeover.

In the days to come:

1. We moved from Rational Unified Process to Scrum.
2. We moved from doing ad-hoc random consultancy to developing products which made small dents in niche markets.
3. We moved from 'control' and 'rules' to 'maturity'.
4. We moved from 'ties' to T-shirts.
5. 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.

Turns out; Jack actually liked the notion of wearing ties to office and genuinely believed in deadline driven development.

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

1. 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.
2. 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.
3. 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.

While Jeff Atwood at Coding-horror proposes the love-it-or-leave-it idea for programming in general; the same idea; dear reader; also holds true within your organization.

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.

The primary rule of blogging or building anything interesting is that you listen to constructive criticism; you discuss things candidly and openly; but when it comes to Bozos throwing random flames on you or your project; you turn a deaf ear and you continue with whatever-it-is that you are doing. If they feel so strongly against what you are doing; they are free to punish you by ignoring you and leaving you alone.

The same rule; dear reader; holds true for work environments.

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.

Logo-wear And Its Importance.

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.

Logo-Wear Reflects Your Organization's Personality.

Remember the famous 'Ninety Hours A Week And Loving It' T-shirt worn by the Macintosh team? All the controversy around that T-shirt apart; the T-shirt was a reflection of Steve Jobs passion towards build amazing software.

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:

1. Most developers do not like their current organizations and are either tagging along as a 501 programmer or looping in the infinite loop of failure.
2. The ones who genuinely love their organization would rather talk about the work that they are doing in their organization.
3. 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.

The Stupidity Called 'Working Together'

At Multiplitaxion Inc, every time I was close to getting in the flow a monkey would pop his head out of somewhere or a bunch of jokers would giggle over a stupidly funny conversation.

Because of the classical cubical-farm design of the office; I jumped from meeting room to meeting room trying to focus and getting stuff done.

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

1. Located next to every meeting room are other meeting rooms.
2. 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'.
3. 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.

It All Begins With A Demo Or A Road Show

'We have an application that does not do much and we have a marketing road show lined up next month. We need to build a few new features quickly.' --- The Vice President of marketing at a fairly famous multi-functional scanner company; which for the purposes of this post shall be called Multiplitaxion Inc; tells us.

When the messages reaches me; my ears perk up.

I can clearly hear and sense the direction of our project changing abruptly and suddenly because someone from marketing pointed in a different direction for the fifth time.

I suddenly become attentive --- in a meeting where I would have otherwise dozed off.

The Negotiation.

You have mastered the art of saying no. With your amazing story-telling and articulate explanations you convince the vice-president that all your team can build till the road-show; is a prototype.

What you mean; when you say all your team can build is a 'prototype'; is that your team needs is a license to build crap that they will neither have to build-on-top-of; nor support in future.

Something that gets thrown away after the demo.

What your vice-president-of-marketing means; when he says you can build a 'prototype'; is that he needs a version-1 of a fully functional product which he can show to potential customers.

Something that gets sold after the demo.

Marketing demos or road-shows alter and change your product backlogs all the time.

Marketing demos or road-shows change priorities all the time.

Marketing demos or road-shows result in creation or 'prototypes' that will be 'thrown after later' all the time.

And there is nothing wrong with that --- till the time you, your team and your organization does not start indulging in what I like to call --- 'Demo Driven Development'.

Demo Driven Development

Every time you are about to do on a product demo or a road show and flaunt your product you will be faced with strong temptations to add new features that might woo your potential customers in the next demo or product road show.

When your vice president of marketing tells you that you have a demo or a road-show coming and that you need to build something really 'quickly' what he is tell you can translate into one or more of the following:

1. We are now going to move to deadline-driven-development.
2. Sky is going to start falling and things are going to get ugly.
3. The famous negotiations between marketing and development teams are going to now begin.

Usually; dear reader; it translates into all three.

The next time your vice president of marketing comes up a set of features that you absolutely must have during the demo; exercise your very own personal judgment and ask yourself if the feature is worth building before you try to 'squeeze-it' into the product backlog.

When you say 'yes' to building something; you accept the responsibility of supporting it for a very long time. We have all seen requests to add features or requests to change things on a prototype that was built to prove a point in a demo and was supposed to be thrown away later.

We have all seen these prototypes snowball into version-1 products and then a three year project needing a lot of fire-fighting.

Remember; you do not 'have to' have every single feature your competition is going to demonstrate in a road-show. There is nothing wrong with going to a demo or a road-show with product that is crappy and incomplete.

If your product is built on a strong idea; if it is genuinely remarkable and if your story-telling is genuinely good; your customers will connect to your organization and flock to product; even if your product has elements of crapiness or incompleteness attached to it.

Don't let 'Demo Driven Development' become the development methodology for your next product; dear reader.

I wish you good luck.

The Lame Whiners Programming Universe

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'.

Putting Fred on a research project doesn't make him happy.

The very words --- 'on the bench' makes him feel insure.

Working on an awesome product and giving long term commitment to it makes him feel nervous.

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?

Have you ever wondered why Fred doesn't leave and go find a better organization?

How many unhappy whiners surround you; 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.

Builders Lead By Building. Not Managing.

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.

James ends his post with an interesting note:

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.

If you want to lead a team of builder; you'll have to stand of the front lines of the battle march.

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.