Your Organization Is (Not) Hiring Builders.

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 2 --- More formatting, more words, lesser real work; yet another status report goes out. 

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 4 --- I'm back to boring status reports again. The status report ships on time.

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.

@BuildersAtWorkBookNotice

Ok, soul searching time.

Are you a builder?

Are you a story-teller?

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?

One, you could be helping build stuff, through your skills of a programming language; through your testing skills; creative skills or whatever 'concrete' skills you have. Two, you could be helping people who build stuff in the first place by building remarkable stories.

Three --- you could be whining.

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.

Builders don't bitch. They fix things. Sometimes they do it so silently, it's creepy.  

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.

@BuildersAtWorkBookNotice

Builders are guys who build stuff.

Software. Bridges. Cars. Roads --- Stuff.

For the early part of my engineering career this is the only kind I respected.

Then I met the other kind who are just as good at building and shipping. These individuals however, do not ship 'stuff'.

Storytellers, build, ship and spread --- stories.

Remarkable stories.

Stories built on strong honest foundations of truth.

'But Pops, you're talking about marketers' --- you say.

No I am not.

If you are working for a software development shop; look around.

Observe. 

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 is leading Project 'A' - a few of us in innocent fun; decide to name it Project Rocket Science.

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. 

@BuildersAtWorkBookNotice

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.

Christopher Baus learnt the importance of being a doer while making a career choice. He explains:

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.

@BuildersAtWorkBookNotice

"What are you up to these days?"

Throw this question to people you meet and observe.

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.

A huge number of these discussions were remarkable. 

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.

@BuildersAtWorkBookNotice

In my earlier post, I talked about one reason why you should write an e-book. In the same post, I talked about how blogging is more like bathroom singing and writing a book is more like performing in a live concert.

For the past few days I've been stuck with this idea that will not let me rest in peace till I work my ass off on letting the it gain a form and an independent existence. I've written a couple of posts on the idea, but somehow like an ignored child, the idea seems to demand more of my attention; which I plan on giving it for the next couple of months; and I plan on doing this by writing a dedicated e-book based on the idea.

I love blogging.

I love everything about blogging; There is nothing more rewarding than seeing a meaningful idea that I really believe in, taking a shaping of its own and coming into existence. There is nothing more delightful than pushing the publish button on a post that is about something I genuinely believe in.

The only thing that tops that delight is your involvement, dear reader, through comments, when you go out and post some of these on other sites, when you blog about them, cite them or send emails to me about a post that was written with hours of thought and effort.

This blog, dear reader, is my third place and I am more 'me' here than I am myself in most places including places where I work.

Because the idea of undertaking the e-book has everything to do with fun; done in my free time; it therefore makes common sense to publish the e-book content out on my third place. The e-book therefore, dear reader, will be published out to you; as it takes shape and form.

Going forward I will be publishing posts that I write for the e-book under the category - My books. Because it is going to be mostly unorganized bathroom singing; the posts that will be published will be in no particular sequence. I am hoping that as we move forward the idea will come out in the open; make itself crystal clear and will resonate with you; dear reader.

As always, I would love feedback, criticism and participation from you dear reader. In the weeks to come I will publishing the book here, post by post as it starts taking shape. You reactions; I assume will be on the following lines:

1. Hate the posts.
2. Love the posts.
3. Want to suggest something else I should be covering.
4. Want to point out typos and stuff that should be edited out.
5. Want to contribute and help the discussion grow.
6. Have similar experiences.

The thing to do in all these cases is simple --- drop a comment; blog about it; drop me an email and express your opinions.

Remember, anything that is published here can still change in the book when it is finally published.

Put simply --- participate and contribute.

If blogging is like bathroom singing and writing an e-book is like singing in a live concert; I am going to get up on the stage of a live concert and do some bathroom singing.

This is your chance; dear reader; to boo a bathroom singer in a live concert.

You're not going to miss it; are you?

Looking forward to your participation and contributions.

Oh and before I forget --- wish me luck.

If you have ever been held hostage by an idea which will not set you free till you work on bringing it into a concrete form of existence, you probably know why the act of blogging is serious painful work and at the same time an addictive; highly rewarding and fun filled exercise.

Having said that, for me, writing blog posts is pretty much like free form dancing or bathroom singing.

You don't have to worry about every single idea resonating with your readers. If one doesn't work, they will show up; again; the next day for a completely new idea; a completely new perspective; this time, they may agree to agree and absolutely love your post.   

Writing your own book however, is different.

For a book to succeed; or for you to even attempt to write a book; you need to be hit by a a single insanely strong idea and then work your ass off at it. You need to put the idea on a test of its limit as you probe deeper with a coherent yet remarkable stream of thought.

If your idea is flawed; or not remarkable; you are basically screwed; big time.

You end up making a fool of yourself; after days of writing, editing; re-editing; proof-checking and toiling.

Put simply, if writing a blog is like bathroom singing; writing a book is performing for a live concert.

True it has its glamour associated with it; but along with the glamour; it involves a lot of work; risk of making a complete fool out of yourself and above all, some serious commitment.

Google the topic of writing your own e-book and you'll get a gazillion articles; describing the glamour associated with writing your own e-book and how you can be an overnight success and an instant millionaire by writing your own e-books. Only a minuscule number of these articles talk about the hours of hard work the usually go into this sort of an initiative before anything you write is read by more than an audience of one called you.

Amongst the hundreds of boring self article which are not even worthy of being linked of plugged from this post;  I happened to bounce on one that resonated with me or moved me positively. It was a post by Seth Godin and his advice on writing your own e-book.

Writing; is much like singing or exercising your mussels. The harder you work at it, the better you become. That dear reader, is the only true reason why, if you write for your blog and if you have an idea which you believe is worth sharing, you should try your hand at writing a book. You should do it because it gives you an opportunity to do more writing; which is what you love doing.

That, dear reader, is why you need to write a book.

Not because of the five figure income or that celebrity status the millions of readers who go gaga over your book are going to bring you.

You should write a book because you have an idea that will not let you rest in peace till you work on bringing it into existence and the idea or story demands more than just an isolated blog post in order to conveyed articulately.

Writing an e-book is easy. Writing a good one is hard. It's like climbing a mountain. You should try writing an e-book because it lets you see if you 'can' climb the mountain; and once you know you can; you should do more of it.

Why?

Because you can.    

It is really that simple dear reader; it's that simple.

No, you are not going to have a million users drooling over your book.  No you are not going to be a best selling author with a five figure income.

Wake up time. I hate to break the news to you but, that overnight success you might be looking for through your book doesn't exist.

To be honest, you'll be lucky if you don't end up making a fool of yourself with zero downloads.

If you've never done it before chances are high that you'll get sick or tired of it and quit in the middle.

Remember, there are only two reasons why you should write your own e-books; because you really want to; and because you can.

Now; do you want to write your own e-book?

If you said yes, you probably know what it is that you are getting into.

If you said yes, chances are high that I am going to enjoy your reading your book after it is done.

If you said yes, you should write an e-book.

I wish you good luck.

If you've ever been involved in a sales chase for a million dollar project you probably know that folks who market consulting services and software products will go quite far to sell their products or  services to you and close the deal. The whole act of lying about quality of people working for the organization, timelines and above all features that the product being sold has, is an age old Adam's apple folks in the business of marketing software have been tempted to bite for years.  

After all software marketers are experts and their interests revolve around selling you their services. If you have a problem and they have a hammer; they are notoriously famous for making your problems seem like a nail.

Seth Godin in his book titled All Marketers Are Liars describes how all marketers are supposed to indulge in the act of story telling:

Seth in his book describes how marketers make consumers and even veteran wine tasters believe that the same wine actually tastes better when tasted in a better glass. The book has other examples including that of a real estate marketer who takes customers around the neighborhood and talks about the various other houses including the lives of people living in those houses.

Seth describes how the individual selling the house is not selling the property he is supposed to sell. He is selling a story.

The book is all about successful story telling.

Story telling that can genuinely create win-win situations both for the marketers and the consumers.

Then there are times when the story telling isn't authentic. The foundations, framework and the very core of the story is built around a lie. That is when Seth warns that the consumer ends up paying the price.

With software however; there is one more group of individuals who end up paying the price of lousy story telling built on utter lies ----- the development team.

My first successful failure was a classic example of the marketing team promising too much with little or no respect for the iron triangle under the influence of wishful thinking and the we-have-a-great-team-that-can-do-it story.

Apart from a few folks, like 37signals, Google and a handful of others who have a great story to tell; almost all other software marketers; especially the ones selling consultancy services; are down right lousy story tellers who don't have anything new to say. Most stories revolve around the same old rather lame ideas:

1. We can meet your deadlines.
2. We can build something really cheap (by outsourcing most of the project).
3. We can deliver quality.

Of course if you pay us more we can do all three and vaporize the iron triangle into thin air; just for you.

If software marketing, for you or your organization, is just about one of these three lame old stories or their combination, your marketing efforts; just like your product website and descriptions; might be downright impotent.  

Pawel Brodzinski describes his rather honest and candid approach to software marketing:

Marketers are supposed to be story tellers. If you are in the business of selling; you need learn the art of story telling and weave stories that are completely new, remarkable and built of a strong foundation of facts; not the same old lousy stories woven around disrespect of the iron triangle. Software marketing guys have been telling these same old stories for years and honestly we're all a little sick and tired of these.

Even if you not a master story teller and can't tell a win-win story which is completely new; you still have a trump-card up your sleeve --- move over to plain old honesty; because honesty in the world of software marketing; as it turns out; is sofa king --- [to be read loudly and very fast] --- extinct that the mere act of being honest will make you a remarkable purple cow and help you not just close your deals or win customers; but have long lasting business relationships.

I wish you good luck.