One of my first teams kicked some serious butt. We shouted at each other, we used the F-word rather generously and when that did not work, we raised our volumes to a level that would blow the office roof sky high.

Then when the fight was over and the best solution had won, we would go out and have lunch together with no hard feelings.

That was my understanding of strong opinions and disagreement.

These were two very useful tools to reach the best of solutions. During my times at Multiplitaxion Inc, I often tended to respect guys who had strong opinions weekly held and had  the conviction or the spine to disagree with me.

Disagreement was loud.

Disagreement was a good idea-validation-check.

Disagreement was good.

It was only during the later part of my career that I bumped into a different form of disagreement that confused me and left me totally dumbfounded.

Ladies and gentleman, if you haven't met 'Silent Disagreement' you are one lucky son of a gun.

If you have, you know exactly what I am talking about.

This is a form of disagreement where someone sits smack across the table to you in a meeting, nods his head in agreement to everything you have to say and then goes out and does just the opposite.

Consider an arbitrary example for instance. Assume that everyone in  your organization, starting from the lowest programmer fresh out of college, all the way up to the chief-executive-officer agree on having a free open internet access policy.

You call the group who is responsible for maintaining the restrictions on firewall in a meeting where you tell them to drop all restrictions from non-work related sites like Facebook or You-Tube. You are going to trust your employees work ethics more than a firewall, you tell them.

Everyone nods in agreement.

You wait for the firewall policies to change and Facebook to get unblocked. Nothing happens. Days later someone higher up in the management sends a flame mail, asking that all sites be unblocked immediately, and everything gets unblocked, only to get re-blocked a couple of days later.

You call another meeting to discuss what went wrong here. Did we disagree on something? Did we not collectively decide that we were going to have an open internet policy? Did we not agree on that? Didn't we waste an entire day discussing the pros and cons on having free internet and trusting your employees versus blocking non-work-related sites?

Strangely enough, even in this meeting, everyone agrees to the idea of an open internet policy.

Strangely enough, non-work related site still remain locked down.

It is then that you realize, that you are not dealing with rational, thinking, objective individuals who believe in strong opinions weakly held. You are up against folks who take every argument personally, folks who indulge in strong flavors of mitigated speech and folks who do not express their disagreement in words but instead choose to disagree, silently.

During my career as a software developer I have seen countless examples of silent disagreements. I have seen examples of folks who think that they should say 'no' to their managers but who lack the spine to say 'no' to their managers on their face, so they resort to silent disagreement. I have also seen folks who think that they are working for the 'best interest of the organization' and use silent disagreement to avoid all arguments or discussions.

Assuming that you can bring about change in your organization, if there is just one thing that you can change, I suggest you put an instant stop to silent disagreement within your organization. This is another one of those issues that you are way better of confronting rather than avoiding.

Go on, confront the folks who tend to disagree silently, and demand an open objective argument or total agreement through not just words, but action.

I wish you good luck.

I'm heading to office. The phone rings. Someone, somewhere wants a stupid signature on his release letter. I tell him I'll be there in about thirty minutes. My DVD company just shipped the next DVD on my queue to my office and I'll get it the next day. My manager is calling to catch up on how things are going. My phone is losing charge already and so am I.

I am juggling with an iPod, a phone, a book and the bus playing a stupid radio channel - when all I should be focusing on is enjoying the long roads that pass me by. Or I should be reading the amazing book I grabbed last evening. I am doing, twenty other things.

Then I walk into office, hoping to get to the bug I spent my entire last night thinking about. I woke up with my mind still chirping at the problem and I found the answer when I was in the shower. It feels like first day at work. Knowing that I have the answer and experiencing the pleasure of putting the fix in place.

That's when I open my mailbox.

A dozen other funny problems await me. Someone is not being able to make it office because of a headache. Someone has a broken laptop and is whining about it in a mail trail. The support guy responsible for fixing his laptop is yelling back and using the caps lock key rather generously both in his written emails and verbal communications. Yet another client is raising stupid, irrelevant red flags.

My miserable little dreams of focusing on one thing that is important and blurring everything else out seem to be getting shattered like a house of cards. That's when the headphones come out.

If you read this blog, you probably know my preference of silence over any form of music when I am consumed in work, but headphones serve another important purpose. Ted Dziuba explains this behavior of using headphones rather articulately in his post titled - Break my concentration and I break your kneecaps. He explains:

I own a good set of headphones that fully enclose my ears. I am not an audiophile, I just don't like to hear other people talk at me.  When I am staring at my Emacs windows with headphones on, it generally isn't a physical cue that I am looking for conversation.

In fact, when I am that deep into thinking out a problem and I get interrupted, I think about the anti-workplace-violence clause in the employee handbook, and how a poorly lit parking lot probably doesn't qualify as "company property".

Interrupting a thinking programmer is a sucker punch to productivity's kidney. Of course it's still important to keep open communication channels, especially in a small team. I don't mind answering questions and helping out, so long as it's not an immediate context switch for me, i.e. I'll help you if I don't have to speak.

On any given day, there are a dozen tasks that I ignore. There are probably dozens of emails that I ignore as well. The underlying assumption is simple. If it's truly  important, someone, somewhere will remind me or someone somewhere will talk about it. If no-one reminds me that it is important, it probably isn't important. I can go back to putting my headphones on and working on things that I believe will eventually matter in the long term.

Then there are things which are pseudo-important, the false urgency alarms, the trivia of broken laptops, egoistic arguments, meetings and the discussions on the status of how things are going. Being a programmer isn't just about programming and chances are that on any given day, you are going to be bombarded by things which seem important but at the end of the day, your ability to ignore them is going to be much more important than your ability to get them done.

Slow down. Take a pause every now and then. Think about, what matters the most to you and spend most of your time on things that matter the most, because most other things that seem really important, hardly matter. Most things that you do on any given day are just random distractions.

Go, reflect on what is really important to you and then spend most of your day, doing those things.

I wish you good luck.

During my days as a young and budding programmer, I was bubbling with confidence. Never in the wildest of dreams did I imagine that a software project or a task given to me could just not get done.

I mean, sure I might have to throw in a few extra public variables, not have enough time to give a shit about the quality of the code I was writing or throw in a couple of hundred band-aids on the codebase, but I would still get the job done.

Put simply, I knew if I worked fourteen hours a day I could stick it up together to deliver to a client. I also knew, if I acted smartly, I would not get my ass kicked or busted. To add to that, if I used enough jargon I could blame it all on requirements, use-cases or some abstract shitty artifact that was always responsible for the failure of the project.

Young engineers learn the shit that they see their seniors do and they learn it fast.

Then it happened. My first successful failure where we were building a piece of software that was sofa king (to be read really fast repeatedly) complex that the thought occurred to me a month before the delivery date - what if, we don't make it - the voice said deep down within as I tried desperately to write a function that would increase the power of the device my code was supposed to control.

This was a project where we were integrating with random devices around the world and some of them had serious issues with their hardware, which is what we were working around. This was not a typical - 'what if we don't make it in time' or 'what if we are a week late' question. Those, you can answer by pointing your finger at a random artifact. This was a case of 'what if we just cannot build this project'.

We did not have shit to show to the client.

What we had, did not work.

What if another one month passed and we were not able to crack the show-stopping problems we were facing?

What if we just did not get anything done?

The question was scary. The realization that I as a software programmer with just a couple of years of experience behind me, had limitations which were as real as gravity was scary. The realization that I could not overcome these limitations with trickery, big talk, smart ass ideas or stupid band-aids was even scarier. All the tricks that my so-called seniors had taught me were failing me. Blatantly.

The project ended without anyone getting killed. We threw tons of band-aids in there. Got a few things done. Then, I struggled for hours and days to set it right before we handed over the project to the client and moved on. Multiplitaxion Inc announced it a grand success. I called it the first (and hopefully the only) successful failure of my life.  

I don't want to live that part of my life again. It was terrible. It was scary. It felt like shit. What felt worst after the project however, was not the fact that I was overworked, stressed out, about to quit had it lasted sometime longer or any of that. What felt worst after the project was the feeling of being used - almost like a mindless human bomb who goes and blows himself up for a cause which is totally insane and downright stupid.

This was the part of the project, that helped me grow in ways I would have never otherwise grown in my entire life.

One of the most important things that the project taught me was the art of caring and putting in my one hundred percent into the work that I do, without giving a f@#ck about what my team, my managers or my clients classify as 'success'. After all, I had just been a part of a project that my team, my managers and even my clients classified as a huge success when the reality of it is that it felt like a one big colossal f@#k-ups of my professional-work-life.

Since then I have come across countless examples and incidents where a client somewhere wants me to believe that my tiniest of non-confirmations to their processes, their dates or their deadlines, equates to a humongous failure. The idea is simple - convince the programmer psychologically that shipping the software on a specific date with a specific list of features is so hugely critical that his entire career depends on it and then he will ship.

I have been through so many of these situations in my life, that I almost find them hilariously funny every time I encounter them now.

Every time I come across situations where I am being told how critical it is to ship on a given date or just how critical fixing a spelling mistake of a label is, I smile inwardly, argue outwardly and somewhere deep down inside, there is a calm, quite, silent voice telling me:

'You have been through this before Pops. You know what to do. Give it your best shot, be honest to yourself and then don't give a rat's ass about the so-called-success.'.

Years ago, after my first successful failure, I learnt that you are way more efficient if you leave your fears of failure behind and replace them with passion. If fear and pressure move you, that is all you will get your entire life.

On the other hand, if you are moved by your own passion to do amazing work, questions like - what if we do not ship on time or what if we fail - will just start sounding seriously stupid to you. You will eventually stop worrying about them and start giving your best shot irrespective of whether these questions are asked or not.

When the sky starts falling, don't panic. Prioritize. Think pragmatically. Give practical options to your clients. Do all you can to turn your project into a win-win situation for everyone connected with it. If you keep getting bull-shit in return, continue helping them, continue shipping, continue putting in your best but just stop giving a rat's ass about what anyone on the project says about the success of failure of your project.

It's time to wear a thicker skin.

I wish you good luck.

I'm sitting smack across the table as Jane, a very talented young and budding programmer, tells me her side of the story. For the last three months she has been a part of the product team and she has been fixing bugs which involve changing the captions of labels on screen.

I cringe.

There are more than one things in this discussion that worry me. The first is that her talents and her abilities are getting utterly wasted in the organization. Secondly, it also means that more sooner than later she would be sick of working and she would start looking for a change. All of this worries me as I listen to her, but what worries me the most is the thought that her team lead is an Alpha-Geek who is refusing to breed more Alpha-Geeks.

And he is violating the pact.

Yes, that pact.

He is solving the most complicated, challenging and some of the most interesting problems himself.

He is not, 'teaching the young'.

Every once in a while, I come across super-alpha-geeks, sometimes even good ones, who prefer to solve the hardest of the problems themselves, instead of letting others in their team solve it and helping them with the problems. Strike a conversation with them and most of them will offer you arguments on the lines of:

1. It's easier to do things myself than to explain and delegate things to someone else.
2. Most programmers in my team are not good enough.
3. I took it up myself because it was critical for the success of the project.

Hidden behind the layers of excuses, lie the bitter facts. The real reason why most alpha-geeks who like to control the most-critical items in the project and do these themselves, can be one or more of the following:

1. The Alpha-Geek has serious insecurity issues and feels threatened by people in his team.
2. The Alpha-Geek thinks of his team as a bunch of incompetent, inefficient idiots who are either not talented enough, fast enough or both.
3. The Alpha-Geek is a control freak and wants total control over the project.

The next time you see the scrum back-log and you start picking up the most complicated items, question yourself, if you are just acting like a selfish insecure jerk or are you helping other programmers transform themselves into alpha-geeks and become critical members in the team.

Give them the most complicated, difficult and challenging items, help them expand their zone of comfort slowly and help them turn into true alpha-geeks over time, because that is what true alpha-geeks do. They breed more alpha-geeks.

I wish you good luck.

At one of our clients office, who for the purposes of this post shall be called Multiplitaxion Inc we have what I call a decision-execution-crisis.

You know, those meetings where really smart people who have done really big things in life and have achieved really serious sounding designations on their business cards carefully position their asses on really soft chair and talk about really sensitive topics like the future of the organization, the future of the product, the official-name of the product, the official editions of the product and the features the free edition of the product would contain.

Did you notice the use of the word 'talk about' and the absence of the term 'decide' or 'act' in the above paragraph. The use of the word 'talk' was intentional, because while a lot of talking happens in these meetings there is often very little decision that ultimately gets taken and even lesser real work happens on those decisions.

It's not about what your manager says in these meetings that matters. It is how he acts after a couple of these meetings that matters the most. Does he get stuff done or does he act all tied and helpless.

Michael Lopp describes his practice rather articulately in his book Managing Humans. He explains:   

When the new VP showed up for his first day at the startup, he was wearing a Members Only jacket. Sky blue. I didn’t know they still made these throwbacks to the '80s. A jacket that lived under the tagline, “When you put it on, something happens.”

I’d given the VP a thumbs up during the button-up and tie phase of the interview, so I gave him the benefit of the doubt.

Three months in, we had a problem. Members Only was doing a phenomenal job of discussing and dissecting the problems facing engineering. We’d leave meetings fresh with new ideas and promises of improvements, but then nothing would happen. OK, so follow-up meeting. WOW! He gets it. I’m fired up again. Let’s roll. Umm, two more weeks and nothing is happening here.

Michael in the same book also describes the problem with most managers who conduct these meetings and love the idea of talking strategy, ultimately getting nothing done. He adds:

The act of delegation is a slippery slope for managers. Yes, you want to figure out how not to be a bottleneck in your organization and, yes, you want to figure out how to scale, but you also want to continue to get your hands dirty.

Members Only's problem was he believed his job was purely strategic. Think big thoughts; delegate the results of those thoughts to the minions. He was a pure delegator and he’d forgotten how to do real work.

Pure delegators are slowly becoming irrelevant to their organizations. The folks who work for pure delegators don’t rely on them for their work because they know they can’t depend on them for action.

This slowly pushes your manager out of the loop and, consequently, his information about what is going on in his organization becomes stale. Then, the CEO walks into your boss’s office and asks, “How’s it going?” The third time your boss gives the same generic answer, the CEO goes to you and asks the same question. When you respond with, “Well, we’re fucked,” the CEO has an entire other conversation with your manager.

Real work is visible action managers take to support their particular vision for their organization. The question you need to answer for your manager is simple: does he do what he says he’s going to do? Does he make something happen?

And its not just about strategic changes or the steering the organization or the product through its future path. I am talking simple decisions here.

How long does it take your organization to get you a whiteboard in a meeting room when you tell them that you guys desperately need one. How long does it take your organization to fix network patch chords in your meeting rooms. How long does it take for your organization to reduce your meeting count when you tell them you are sick of attending them and want to focus on work for sometime.

Measure your manager's and your organization's ability to take decisions and then act on those decisions. If they are able to take decisions and act on them, you will be just fine, even if those decisions aren't correct or even if they are failing and learning at each step.

On the other hand, if nothing ever gets decided and nothing ever gets done at your organization, maybe its time to get your act together, figure out why your organization cannot act and do something about it. Procrastinating with your organization will not get you anywhere in the long run.

As they say, You can Change Your Organization or Change Your Organization.

Either ways, I wish you good luck.

I find myself seated smack across the table with Fred looking at me like I just performed the gravest of offence in his professional life. I tell him the awesome news of his promotion and a handsome thirty-percent hike. He eyes me like a criminal.

Turns out, he was expecting more.

He tells me that he was aiming for a higher hike.

Ok. Breathe. I tell myself.

I thought this was good news. I thought his face would light up. I thought... I am confused by the time the discussion ends.

I feel shitty. Really shitty. Really, really shitty.

During my career of breaking appraisal results to folks and telling them how their year was I have worked with three kinds of programmers, or should I say, human beings.

The first is the kind of have very little expectations and if they get what they deserve you can see their faces light up. These guys are happy-human-beings. They know their net-worth, they know the perils of over-pricing themselves and they have no desire to take home more than what they really know they deserve.

The second kind is the group of folks who just don't give a shit. Ok, maybe that's not a very good way to describe this group. Maybe they do give a shit. Just a little bit. But these are folks who are motivated by the process of building stuff and for them an appraisal meeting by itself is an awkward moment.

They would rather you just print their letters and send them their revised salary letters by post so that they can ignore the letters like their telephone bills and find out their new figure when the amount lands up in their bank account. Maybe they would like to just glance at their appraisal letters and if they are not utterly insulting or disappointing they would just keep them aside and move on with their lives.

Put simply, For this kind of people, appraisal discussions are not a life changing moment.

This is the kind that usually draws the highest raises in the organization. Raises, power and promotions are funny things. They tend to usually go to he people who have very little or no craving for them.

Even though the first two kinds are insanely interesting to study this post is not about the first two kind. This is a post about Fred. The third kind. One which lives in the constant state of craving and discomfort. This breed will tend to bitch, whine and moan about their salaries, what the organization gives them, what they give to the organization and what the organization aught to give them.

If you are leading them they will remind you a dozen times a year that they are grossly underpaid and they will decide to stick with the organization anyhow.

This is the group that typically hops organization for a ten-percent hike every time they get a better opportunity. The group that powers the infinite loop of failure.

We start getting into an awkward dance here. Fred and I. Fred tells me he is underpaid, I show him industry wide pay scales of people with similar experience and expertise. He refuses to believe the research data. Fred, as it turns out, loves to nurture the idea that he is grossly underpaid and he seems to love continuing  to work for the organization in a mode of utter discontent.

If you are dealing with Fred, here is a word of advice that comes after coming across quite a few Freds in my career: you cannot make them happy. So don't even try. As an organization, get them a fair deal and everything that they deserve and move on.

You can attend a dozen management classes on how to keep your employees happy, but the sorry fact of life is that you are always going to hire a couple of people who you cannot please irrespective of what you do for them.

Do what you think is fair and then draw a line. Stop feeling bad. Stop getting confused and stop spending hours wondering how you can please Fred, because it is pointless. And assuming that even if you were able to please Fred, chances are you would get his resignation the day he gets a ten percent hike. You are way better off sticking to the age old saying, you cannot please everyone. Focus on the other two kinds instead and do all you can to keep them happy.

That way, you can at least have a team where most folks are happy and productive.

I wish you good luck.

We are here for you Twenty-Four-Seven.

Today, lets dive into the depths of time and bring from days that have rolled behind, a classic tale of support done the Indian-way. Before you read any further and start sending me flame mails about the generalization of the word 'Indian' here, trust me, I know exceptions do exist.

I also know that generalizing anything by a country is just about the biggest stereotype of the software development world that you should avoid at all cost, but humor me. I have a point to make and the point is not to ridicule or insult Indians in any way. I happen to be an Indian and I am actually fairly proud to be one. But then, having said that, India as a country and Indians as a group are often totally capable of doing seriously shitty things.

So, as I was saying, lets dive into the depths of time and bring back from the days that have rolled behind, a classic tale of support done the Indian way.

In one of my last work trips somewhere between New York and Chicago, after making us wait inside the plane for about an hour because they lost the stair-case that was supposed to get us down, making me miss my connecting flight and making me quite literally run for the next flight United Airlines manages to put a cherry on the cake of surprises by loosing my luggage.

After a few frustrating experiences with the ground staff who tell me that the bags would show up a day later at my hotel, I decide to make a move, get to the hotel and get on with my life. Three days later, however, I find myself trying to look up my luggage using the baggage tag on the United website which tells me that my luggage cannot be located.

Then, smack out of nowhere, I find myself doing something that I have a love hate relationship with --- I am calling the Support Line. Now, as I already said, I have a love hate relationship with support lines. Love because support lines often tend to be sofa king (to be read really fast, repeatedly) funny that they give me food for thought and posts like this one. Hate because they are so funny, that after a while they stop being funny.

As far as the United support line is concerned this is how it goes. The system routes me through series of automated questions. Then after routing me through a hugely long automated process which also confirms that my luggage 'cannot be located' it lets me talk to a customer care executive. Seven minutes of wait follows after which someone answers the call.

Voice On The Support Line: Good Evening Sir, This is United Airlines. My name is Fred (I could have used the real name, but then Fred sounds so much more fun in this situation), How can I assist you today?

The voice is Indian. Clearly. Plainly. Indian. And the fact that this gentle-man uses an American name to identify himself, tells me exactly what to expect next.

Me: My luggage seems to have gone missing at the O'Hare airport. The ground staff told me that they would ship it to my hotel in about the day and It's been three days since then. I am just calling to find out if you guys know when I would be getting my baggage shipped to my hotel because I am leaving this place and moving on to a new location in the next couple of days.

Fred: I am sorry for the inconvenience sir but we are here to help you Twenty-Four-Seven.

Long silence. Awkward moment.

Me: Do you need my baggage tag number?

Fred: Yes sir. Can you please provide your baggage tag number?

I give out the number. Another long pause follows. After which he tells me that he is going to put me on hold and I sit there listening to music for about three minutes. Then the voice cracks back.

Fred: I am sorry for making you wait Sir. I am also sorry for the inconvenience sir but the system is showing that your luggage cannot be located at this time.

Me: I know that. I saw that on the website and heard that on the automated system and both of them said I should talk to a customer care executive.

Fred: Sure sir. We will have updated information on your baggage soon. I apologize for the inconvenience but we are here to help you twenty-four-seven. You can call us anytime.

Me: How soon would you have updated information on my luggage?

By now I am having a seriously hard time hearing anything other than, Fred is really sorry for the inconvenience caused and that he is here to help me twenty-four-seven. But then, I don't want him to be there twenty-four-seven. All I want is my baggage back. I don't give a rat's ass if they work for three hours a day or twenty four.

We do this insane dance for long time where he assures me that he is really sorry about the inconvenience caused, that he is going to get me a hundred dollar discount on my next flight and that I can call the support center anytime. He then reminds me for, I don't know how many'th time, that they are there twenty-four-by-seven and that I can call them anytime.

Three days later the baggage arrives at my hotel and United conveniently just forgets the promise of the hundred dollar discount on my next flight. I receive no emails, as Fred had promised, no discount coupons. Nothing.

It's like the episode never happened.

We Cannot Help You Unless You Pay More.

Life moves on. I get back to work and this incident of Fred and his Indian support center being online twenty-four-by-seven for me is long forgotten. Till the time I see another example of support done in a slightly different way.

Recently, one of my posts hits the top five post related to programming on Reddit and I get a throng of people visiting this website. The new unique-visitor-count hits almost about fifty-one-users-a-minute, with old users continuing to read and click links on this blog.

This is when the website starts crumbling down under the load of heavy unexpected traffic. After about five hours of non-stop-traffic growing at an uncontrolled rate people start complaining about getting service unavailable errors. I decide to call the support line of my service provider.

Now, before I describe how the call goes, here is a little bit of history of how these guys transformed their support department. These are guys who were once notoriously famous for bad customer support and then one fine day, magic happened. They changed.

They were now, suddenly, providing support that started positively surprising me and the rest of their customers in all the right ways. No-one could really figure out what they had done but something had changed for better.

There were no solid announcements per-say but I suddenly started getting great responses in my support emails and my problems were getting resolved at the blink of an eye. I never had to call them so far, but with this issue it was better to call, than to email and wait for a response.

So, as I was saying, I decide to call up the customer support.

With literally two choices on the automated system, one that asks what I am calling for and other that asks me to press a number to talk to a customer support executive, in less than three minutes I am talking to a real human being,  who by the way, helps me locate the customer ID that he needs and then tells me, that I am facing service-unavailable issue on my website, without me having to describe the issue in detail to him.

Then he wants to know if this traffic was expected. He puts me on hold for less than a minute and comes back informing me that even though I am just using one percent of my bandwidth I have crossed my concurrent connection limit and that I would have to pay a little bit more to fix this issue. He then adds confidently that without upgrading the plan there is nothing he can do to fix the issue. Unless I chose to pay more, he cannot help me.

He is direct. Confident. Focused on my problem and is providing me the one single solution he has with a choice: take it or leave it.

I take it.

He initiates the payment right away and the service unavailable issue is sort-of-gone in less than about half hour.

While I should been utterly annoyed with my service provider and the fact that they never documented the number of concurrent connections my site was allowed to have anywhere, I actually end up liking the way the guy at the support handled the situation.

He is not nice to me, he is not sorry for the inconvenience cause, he makes me pay more.

But then, he understands my problem and fixes it while my dear Fred at United, who is there for me twenty-four-by-seven does not get shit done.

And The Point Of This Long Tirade Is...

That support is an art which requires people who know what they are doing. That hiring random Indian students, paying them their pocket money and giving them a bunch of carefully scripted cue-cards or a stupid set of Frequently Asked Questions does not equal good support.

Sometimes, we really do not give a shit if you are there twenty-four-by-seven.

All we give a shit about is our problem and how quickly you can help us fix it.

So the next time you think of publishing your support email, see if you can get the best of your folks in that mailing list and allow them to answer support emails if they want to. The next time you think of building a support department, see to it that you hire the guys who are just as good as your developers or the rest of your organization.

Support is not something you outsource and forget.

Because if you do, people will eventually just stop calling.

And then, they just might move on to companies who understand their problems and do not hire a bunch of random college students to tell you how sorry they are about the inconvenience caused.

Support, is serious business. Give it the time, money and attention it deserves.

I wish you good luck.

David Heinemeier Hansson in his talk at Startup School describes the typical product cycle and the day dream of making billions and getting bought over by venture capitalist that most young and budding entrepreneurs have using a simple slide:

During the presentation, David's point is focused on a single topic. One way to make money is to hope for a lot of magic in step two and expect that a venture capitalist or a Google will buy you out. David describes the other, more practical, sane and logical way using a simple slide:

If you have not clicked the link to the video yet, you should.

David explains the idea of pricing your product or charging for your online service using simple, direct and wise advice for young and budding entrepreneurs. He explains:  

The really cool thing about all of this is that you don't need to be a fu@#king genius to make it work. Its not rocket surgery. It really is a simple three step idea.

You have a great application. You ask money for it. If people like it, they will pay and you profit.

But here is a kicker. Just because you slap a price on something does not mean you will have a successful business

37Signals has their own offering of free products for the end consumer but the focus of this video, is on their paid versions and how they make money online. As someone who has observed a truck load of software products getting priced, if there is one thing that I have learnt about pricing it is that pricing is just like any other phase of building great software.

Like any other aspect of software development, when it comes to pricing your product, you will fail too. The earlier and more often you fail the better off you are, as long as you do not keep making the same mistakes all over again.

Should you give out your product for free and seek additional business models to make money? Should you use free as a means to keep in touch with potential customers and convert them to paid customers over time? Is free your way to wipe your competition out of market? Are your products too highly priced? Are they priced too low?

You will never find out until you go out there and experiment with pricing. Lose a few customers because you are too highly priced. Get a few customers at a very low price. Give parts of your application for free. Explore other models of making money by giving your entire product out for free.

The beauty of online products and services is that you are always free to come back and fix your mistakes. Long story short, making mistakes is much better than procrastination and analysis paralysis.

Seriously, you really don't have to be a fu@#king genius to make it work.

Now go out there, make a few real product pricing mistakes and then learn from them.

I wish you good luck.