Pitfalls of Guaranteed Success pt. 2

Written by on May 13 2008

Two weeks ago Allan wrote a post about Pitfalls of Guaranteed Success. Today “James” added a comment that made me think that maybe other people could benefit from elaborating on a few points.

James said about #1: ignoring server scaling leads to disaster, just as ignoring UI leads to disaster. (this should not be taken to mean that I think all resources should go into server scaling.)

My opinion: Most people worry about server scaling long, long before they really need to. Who cares if your site can’t survive getting Digged? Planning to get Digged before you’ve done anything good is a waste of energy. This is an example of people trying to solve problems before they are problems. You do not need to worry about scaling servers until you have a server scaling problem. It is exactly this mentality we see all the time: A client wants to make sure their brand new website can survive being Digged. We appreciate the excitement, but it happens so rarely that it is not an issue. People think the problem is real because when someone goes through it a lot of people find out about it, usually through Digg. I promise you that 99.999999% of people will not have this problem. Until you have a server load problem, exactly ZERO percent of your resources should go into server scalability. And once you have that load problem you should start by looking to your code, not your server. Planning a server infrastructure to survive being Digged is like driving an 18-wheeler ever day because one day you might move. The real difference is that you will almost certainly move one day.

James said about #2: depending on the type of business, people may be much more likely to hire too many people out of fear of not getting the work done successfully during an up-blip in business than they are because they are thinking success is guaranteed. the result is similar but the motive isn’t the same. Hiring the right people is always key, of course.

My opinion: 2. Those two motives are actually the same. Most people don’t see an “up-blip,” they see the beginnings of success. It is a rare person who sees the pragmatic reality that this might just be a blip. People tend to think that they can finally start to hire people, buy better computers, buy a boat or a new house. It’s much better to just wait and see what happens. But hiring people can be disaster. Hiring someone just to fill a seat hurts more than just the additional payroll costs. It hurts because the person hired is probably not the “right” person. Their lack of productivity, passion, dedication, excellence will spread like a virus. One of the best things I heard at the Y-Combinator Startup School was that “Eventually the quality of your managers/employees falls to the level of the worst manager/employee.” This happens because it is human nature to say, during the hiring or promoting process, “well this guy is bad, but he’s no worse than ____.” The hiring process must be about fighting entropy. I think only Google has managed to overcome this. They pass up a lot of really good talent because of it though.

James said about #5: gut is not reliable. if yours has been you have been lucky. you said it in number 4. trust your gut to start but plan to iterate.

My opinion: I’m sorry your gut is not reliable. If it wasn’t so arrogant, I would recommend trying to improve the reliability of your gut feelings. Allan’s point here is about trusting yourself. If the majority of people think your idea is great, it probably isn’t. Do you think most people would have told Microsoft that they had the killerest idea and that they would be huge? What about Google? Most people would have said “why compete with Yahoo, they have the search market locked up.” Worrying about what other people will say will make your product mediocre. Be bold. Trust yourself. Follow your gut.

I don’t know James, and I certainly don’t mean to pick on him (I hope no one takes this post that way). He brought up some great points that are worth clarifying. Thanks James!

Meet
Steven

Hi I'm Steven,

I wrote the article you're reading... I lead the developers, write music, used to race motorcycles, and help clients find the right features to build on their product.

Get Blog Updates