Three guys building what they love and being profitable at it is a story; five thousand bodies building yet another enterprise software is a factory.

One guy selling a million copies of a one dollar iPhone application is a story; an enterprise bidding for yet another million dollar contract, is just a marketing gimmick.

One funny two minute video on YouTube is a hilarious story; one hour of regular television sitcom is grunt work in the life of a production house.

We don't want to hear about you rambling about yet another enterprise, yet another deal or yet another production house.

We don't want to hear about the big guys again. We know how BIG works.

Big is starting to get really boring.

A small blog post with a brand new thought, a tiny code snippet that makes you a better developer, a small open source utility that simplifies your life, a small you tube video inspires you, teaches you or makes you smile... these are all small stories you can weave.

I am too busy to work on it. I am not big enough to do it. I am not smart enough to do it.

BULLSHIT! Lame. Excuses.

None of these excuses work when it comes to these small stories.

They don't take a lot of effort. They don't take millions of dollars. They don't even demand that you quit your day job. Just a little bit of consistency.

We know you can weave them. Everyone can.

The only real question left for you to answer is, will you?

Go start something really small and celebrate your doneness.

I dare you.

When we landed in her organization as external consultants responsible for reviewing a project, Jane had a business card said that she was responsible for all IT purchases in her organization.Vendor evaluation, comparison and negotiations for every piece of hardware, laptop, server, cable or wiring that her organization purchased.

Buying a book that someone in her team needs, was a completely different thing though.

There was a systematic approval process involved which she had to go through.

The fairly convoluted process involved in taking her team on a quick lunch is even worse than buying a book that they need. Every time her purchase request for a book was rejected her organization silently signaled to her that they did not trust her judgments.

This was not a typical Fred mucking around with code. Someone who wants and needs to be monitored and questioned on every step.

This was not a typical robot.

This was a person with a job role that demanded that she took judgment calls and yet we sat in meetings where her own managers rejected some of her best judgment calls for all the stupid reasons.

The outcome? Detachment.

She had been given two promotions in the last two years. Clearly they knew what she was capable of delivering. And yet there was continuous reluctance in yielding just enough freedom that would let her do her job remarkably.

A promotion is the act of telling someone you trust their judgment with bigger stuff.

Getting out of their way is the act of actually trusting their judgments.

Most kickass builders, story tellers or movers will not judge you by what you tell them, they will judge you by what you actually do.

Trusting someone's judgment calls and getting out of their way so that they can take independent decisions, succeed, fail, learn and grow is one of the best gifts you can give someone.

Are you giving this gift to your team by trusting their judgments?

Just a little something to think about.

How does the data of a project that is hugely successful differ from the data of a failed project? Actually, it is not very different. Most projects are slightly late. Most projects are slightly over budget. Most projects have variances. What sets a successful project apart from a failing one is the story that surrounds these projects.

Even though I did not know how to name it back then, one of the most valuable lessons I learnt as a young and budding developer, was that we become the stories we tell ourselves. That and there was a breed of people who really kicked ass at the art of story-telling.

Besides builders who build stuff, the people who weave remarkable stories are hugely important to the success of any software (or for that matter any) project. In this chapter of the book I introduce you to the special breed of people I call story tellers.

You can get the chapter from here.

The guy who used to score A+ at all his exams in high school bumps into you at a shopping mall and wants to "catch up" with you. He wants to know where you are working. You answer.  You tell him that It is a small startup based out of the valley. He wants to know how many employees your organization employs and cringes at any number less than a thousand. It does not come as a surprise to you though.

You already knew that you had just bumped into a lousy moron who was going to judge your success based on your organizations success and your organizations success based on it's head body count. You knew it the moment you saw this gentleman and your mind raced back to gather recollections of your high school days and your interactions with him.

The mentality is mostly a reminiscent of the individuals upbringing. You instantly dive into a flashback. This fine man in front of me is a classic example of a family and a school that succeeded in turning a perfectly smart child into a lousy moron.

When we (me and my brother) were young, grades and marks were not a huge deal in the family. Of course we were expected to fair well, but our parents did not lower their perception of our intelligence or treat us any differently if we scored a "B" instead of an A+.

Life for this acquaintance of mine, was hugely different though. He had a family which evaluated his intelligence based on his grade. The guy had fierce pressure of topping each test, merely to leave his interactions with his family and their perception of his intelligence un-tempered.

As much as I could never connect to him, I did feel sorry for the guy back then.

He was a classic example of someone who "fits it" and expects everyone in the classroom "fit in". Someone who has all the answers but does not learn how to question what the book says. Someone who never lands in trouble to save a classmate from a prank they pulled together.

When you use lousy numbers with no real correlation to success, to measure and judge not just yourself but everyone you meet, you develop a narrowed vision of reality. You become this acquaintance of mine.

You start hiring employees based on their scores in their IQ test. You start taking certifications  seriously, you let designations define your own net worth in your every own eyes and worst of all you start turning your own kids, who are awesome at the art of exploring, failing and learning into idiots who know how to cheat the system and score even higher numbers than you did.

If you are a programmer my advice to you is seek the most innovative organization that you can find out there, even if it has just three people working for it.

If you are a responsible for hiring my advice is stop recruiting people based on their IQ tests and most importantly, if you are a parent, my serious advice to you is, stop evaluating your child by his grades and stop judging him. Stop it. Now.

Observe what your child loves doing and nudge him to do more of it. If all goes well, you might have kid who grows up to be someone who is happy doing what he does not go around comparing his grades, number of employees in his organization or other random numbers with numbers of other random people that he bumps into at shopping malls, to feed his insecurity. Seriously.

One of my favorite Ted Dziuba post is the one where he advices everyone in the software business and managers in particular to stop using the word "we" and other enterprise words when talking about tasks and responsibilities.

In his classic, loud and highly opinionated way, Ted explains:

Yesterday, I spearheaded a new movement at the office. I stopped using the word "we", and started to say what I really meant to say.  For example, instead of "We should fix that bug", I say, "You should fix that bug", and good God is it satisfying.

There are a couple of motivations for this. Firstly, one of the key things I've learned being a for-pay writer is to show some conviction. Secondly, the passive discussions about defects and delegation and responsibility really started to irritate me. Why not just tell it like it is?

When I worked at Google, I picked up on a really annoying trend in the software industry (or maybe just in Silicon Valley) that I call "fuck-you with a smile".  You never want to outright blame somebody or something, rather, it's best to state the existence of an issue and then ask "the team" to fix it.  We should really move that icon ten pixels to the left. We definitely need to fix that concurrency bug. We should probably have that all done before lunch.

Well then, Mr. Manager, you had better get cracking, because I've got some YouTube videos to watch.

I can see a whole breed of managers knitting their eye brows at the whole approach, but if there is one thing I can tell you after working at countless client offices and observing countless other organizations, it is that it is often the organizations that focus on individuals, the virtues of selfishness and create win-win situations, that are the most fun to work at.

These are also typically the environments which create the best of the teams which are closely bound because every individual understands clearly that their best interest is in complementing the efforts of others, flocking well without bumping into others and giving in their best, because their best earns them the best of appreciation.

An environment where every single achievement of yours is masked under the banner of "the team" often tells the story of an insecure manager spending all his time making sure no particular individual gets more than a certain share of credit.

Every time you plan on using the word "we", the least you can do is make sure that you at-least pick a considerable part of the task you are delegating and actually do it YOURSELF. The "Lets work on this" approach works wonders if you genuinely mean it but if you cannot take up a sizable part of the work, shut up and use "you" or "you guys" instead of "we" because YOU Mr. Manager, are not going to do any real work on this assignment.

The whole idea of only using the word "we" when I am actively contributing in solving a problem is something I may not have always adhered to in the past but it is also something that every single one of us I need to be careful about, specially while working with a team of kick-ass developers.

You want the best to give in their best and add the most value, not assign every task to the mediocre larger "we" or the black hole called "The Team" where everyone is responsible for talking about it but no one responsible for actually doing it.

Stop hiding behind the collective curtain of "we".

Pick up a sizable chunk of the work in the overall task and then by all means use the word "WE", but don't use "WE" to make yourself "somehow" involved in the work that you have not done. If you want credit and involvement, earn it. Go take up a sizable task now and ship.

If you cannot do that, consider shutting up and letting those who are  driving, get the due credit for their work. If you need "them" to work on something, while you wait for them to complete and play online poker or attend meetings in the meantime, the least you can do is be honest about it and say it with conviction. Seriously.

Builders and Story tellers have their own set of problems.

One of the biggest ones is that if you are an amazing builder or an amazing story teller, chances are that you are an artist.

You get ideas in the shower that are so strong that they hold you by your collar and do not let you go till you put them within the curly braces of code functions or on the light grey pages of a notebook or a word document.

You get fragments of inspiration.

You get headaches with multiple threads of ideas running in your brain at night as you try to sleep.

You thrive at creativity but your problem is that you cannot fill your tax forms without mistakes.

Your problem is that you can get an entire system built but sometimes you blank out and forget what it is that Jack in your team is supposed to be working on.

Dam! You said you will put that down in that excel sheet. You said you were going to get better at tracking.

Newsflash: You are just wasting your time trying to become someone you are not. You are a builder. Not a mover. There is a difference between the two.

Every project requires builders.

Every project requires story tellers.

What every project also requires are movers.

A mover is an otherwise quite tester who walks up to the developers desk and casually reminds him what he needs to work on for today without brining a truck load of process in the middle. His business card or title does not entitle him to remind developers what they need to work on.

But he does it anyway, because creating movement is a part of his nature.

Strangely enough, Instead of resisting or saying no, the builder, listens to him because he knows the mover is not bossing around. He is just helping by being himself.

A mover is an otherwise silent document formatter, who points out the critical features the team has been missing for the last three sprints and that you, the project manager have completely forgotten about.

When Jack says he is done and is about to sign off, the mover jumps out of nowhere and reminds him with a smile that there was a bug that he had said he would close but never did.

A mover notices the slightest of broken windows.

A mover is not in your face. A mover is not irritating. A mover is NOT a manager. A mover does not go around with Gantt Charts and detailed project plans. Yet, a mover is ten times more efficient than a dozen managers running around with their Gantt charts.

Being a mover, means that you "have to" be moving. You have to be in a team that is moving. You sense movement. If your team is slowing down you are the first one to sense it. If your team is moving at a dangerous velocity you notice that too.  But you don't freak out. You don't whine asking others to speed up or slow down. You silently and quietly create an environment where more thrust is applied or thrust is reduced.

I don't consider myself to be a very good mover. I am nowhere closed to being organized. I don't remember stuff. But every time I work in a project that has a team size of more than one, there is always a mover involved. My current project at work for example has multiple movers.

Almost every given day I am nudged by a mover or two reminding me about the stuff that I had promised I would do and I did not do. The movers understand that my bosses called and wanted me to work on an urgent document during the weekend.

But then the movers are relentless. The movers will also be at my desk Monday morning, just casually chatting about what they did during the weekend and then just as they are leaving, reminding me that if I am free I can take up that bug that I said I would fix before the urgent document came up.

If you give me the slightest of hints about taking the movers out of my project and I will fight fiercely to keep them in my project, because while the builders are building stuff and the story tellers are weaving stories, the movers are watching the speedometer, the broken windows and the loose ends, rushing to remind you with a smile that you missed that final stroke of brush in your painting.

Have you identified at least one mover in your project? If you haven't, chances are that your project is fumbling right now as you read this, even if you have both, builders and storytellers working on your project. Go find a mover. Then give him the liberty of being himself and let him build some movement with a gentle nudge every time he sees your speedometer fall, your window break or your painting finish without that final touch up.

I wish you good luck.

He bitches a lot. The whiner in your team, I mean. The classic whiner feeds on gossip. He feeds on creating confusion through communication. A whiner usually whines because whining and bitching is easier to do than shipping something.

The classical management folks and people from HR will give you intelligent sounding advice. Talk to him, they will say. Counsel him. Have a discussion with him.

BULLSHIT.

Then there is other breed that will panic at the whining and bitching. Fire him NOW, this bunch of managers will tell you.

More BULLSHIT.

Unless the whiner is a political scumbag, there in a whiner in all of us. The whiner whines because he is lazy. Because whining is easy. He whines because YOUR culture tells him that he can get away without shipping if he whines.

If you want to genuinely help a whiner and your organization, here is the golden advice:

Get him to ship something. Anything.

I don't care how small it is. I don't care how insignificant it is. I don't care if he ships crap. Make him ship. Consistently.

The same advice works for almost anything in life. Small incremental steps. If you have never run before, running just hundred meters will find you panting like a wild dog. They key is to do it. The key is to keep doing it. Then do it more.

Shipping is hard. Shipping means growing out of your comfort zone. Shipping means you take your ass off that couch, stop bitching and actually add value. Shipping, is also addictive. Shipping adds to a sense of well being and once you start becoming good at it shipping is fun.

Get your whiner to work. Get them to ship something. Anything. Leave no room for lame excuses, moaning or bitching. Make it clear to your whiner that you mean business. Chances are that they will either get so uncomfortable that they will leave or they will slowly and steadily become effective at what they do and have much less time for whining.

Repeat the process.

Do it till the whiner has either quit or till you have a fully productive employee who does not have time to whine any more.

Of course, there is a little bit of a whiner rooted deep down in all of us and if you have not been steadly shipping for some time now, the same recipe works for fixing that whiner within yourself too. Try it.

I wish you good luck.

The internet is littered with articles and blog posts by project managers on how they spoke the truth about their project timelines slipping, how their clients loved them for it and how they lived happily ever after.

I have had my share of those stories and I would love to share them with you, but that would be BORING.

I could tell you that honesty is the best policy, but that would be way too CONVENTIONAL.

The reason why you should choose to be honest in your communication and deals is not because honesty always leads to a happy short-term ending. Honesty is not a commodity that you try to market when hell breaks lose and expect to sell it every time. If you think of honesty as a commodity, chances are that you will find it really hard to market.

Honesty is not a last resort escape route.

Its a way of life.

Its your attitude.

Its who you are.

Honesty begins by being honest towards your work. If you have given your hundred percent, being honest when disaster strikes is not a very difficult decision. It's the gnawing guilt of not giving in your best that makes honest communication so much more difficult when the hell breaks loose.

Your honesty test began when you were doing your job when the sky was blue and when the birds were chirping, not when the sky started falling.

What were you doing when the storm of panic had not started? Working to the best of your abilities? Honestly?

Honest communication is not usually very hard if you were. If you know you were not, then honesty becomes that much more harder. You find yourself playing with excuses, jargons and your fingers by pointing them at others.

I have played the blame game before.

Writing about it and admitting it, even years after it happened, was much more difficult than most people think it is but the whole point of writing about it was that it was a lifestyle change. A transition that happened over a period of years, is still happening and hopefully will continue to happen throughout the lifetime.

The good thing about some of these experiences though, is once you have been through just one of them and burnt yourself, the decision of being honest towards your work becomes a hardcoded part of your lifestyle; and once that happens, the decision of being honest in your communication, even when the sky is falling is a no brainer.

If you were a programmer did you write the best of the code you could? Fought to the best of your abilities to avoid crappy decisions?

If you were leading a team, did you do the best leading, keeping an eye on the project without getting in the way and the best mentoring that you possibly could?

If you were a marketer were you honest to your client when telling him about your product features?

Go on. The next time the devil knocks on your shoulders nudging you to take that shortcut in your daily work life, give him a cold shoulder. Being brutally honest, when the hell breaks lose will be that much more easier if you know deep down inside that you were honest all through and that you did the best you could.

I wish you good luck.